Библиотека Интернет Индустрии I2R.ru

Многие годы лаборатории Real-World журнала Network Computing были связаны друг с другом линиями T1. На этих линиях в качестве протокола канального уровня мы использовали Frame Relay. Однако ежемесячная плата за них была довольно высока, и к тому же мы платили за доступ в Интернет. Надеяться на то, что цены упадут, мы не могли, поэтому решили перейти с Frame Relay на технологию VPN (Virtual Private Network). Конечно, мы руководствовались и другими, абсолютно нематериальными выгодами - доверием читателей. В своих статьях мы советовали вам передавать весь ваш трафик по VPN-каналам, используя Интернет в качестве главной магистрали, в то время как сами продолжали упорно держаться за Frame Relay.

В конце концов мы решили покончить с этим лицемерием.

У нас был заключен контракт с Интернет-провайдером, а цена за каналы Frame Relay продолжала расти и поднялась до такой отметки, что купить собственное оборудование и перейти на более дешевые каналы DSL уже имело смысл, поэтому мы решили передавать наш трафик между лабораториями по VPN-соединениям. Сеть, с которой мы работаем, не относится к категории "критически важных", однако мы используем ее каждый день, и потеря связи чревата для нас простоем. Наши лаборатории Real-World расположены в нескольких городах, и динамическая интеграция каналов Frame Relay представляет собой непростую задачу. Кроме того, нам хотелось бы иметь больший контроль над нашей сетью, а также обеспечить некоторую защиту ее периметра. И наконец, нам необходимо поддерживать связь с теми нашими редакторами, которые работают дома или находятся в командировке.

Работу над нашим проектом мы начали в июле 2000 г., рассчитывая, что все займет несколько месяцев. Как и многие ИТ-проекты, наш занял намного больше времени, чем мы рассчитывали, - в первую очередь изза организационных, а не технических проблем.

В среде, к которой мы привыкли (рис. 1), трафик между лабораториями передавался по каналам Frame Relay, что по большей части нас устраивало. Однако, когда мы начинали передавать файлы с данными, производительность сети снижалась. Мы также сталкивались с некоторыми проблемами поддержки, особенно когда необходимо было переконфигурировать маршрутизаторы, принадлежащие Интернет-провайдеру. Некоторые простейшие изменения в конфигурации могли иметь следствием потерю связи с одной или несколькими лабораториями на срок от нескольких часов до нескольких дней. Короче, нам необходим был больший контроль над сетью.

Мы запланировали перевести на местные широкополосные линии связи все наши площадки, за исключением лабораторий, находящихся в Сиракузском университете и Университете штата Висконсин - обе они использовали имеющиеся в университетах соединения с Интернет. Далее, лаборатории в Сиракузском университете, в Университете штата Висконсин и в Вашингтоне (округ Колумбия) оснащались VPN-каналами. Таким образом, все лаборатории доступ к корпоративным ресурсам осуществляли через Интернет. К сожалению, однажды в процессе перевода две наши лаборатории оказались отрезанными от сети Интернет, когда прекратили существование их DSL-операторы, и мы были вынуждены срочно искать им замену.

Сейчас Web-узел журнала Network Computing располагается в компании Cerf.net. Редакторы в наших корпоративных офисах используют ПО Lotus Notes. Но в целом редакционный коллектив рассредоточен по стране, и многие из сотрудников не пользуются Notes. Поэтому мы решили сконцентрировать внимание именно на них. Наши производственные серверы, такие, как SMTP, DNS и серверы для хранения файлов, располагаются в Сиракузах; резервные же серверы находятся в вашингтонской лаборатории.

Мы решили, что наш сценарий перехода на местные широкополосные линии связи, по которому местные провайдеры должны обеспечивать необходимую полосу пропускания, а мы берем на себя заботу о безопасности, разместив межсетевые экраны (МЭ) по всему периметру корпоративной сети, будучи реализованным, существенно улучшит наши возможности по эксплуатации нашей собственной инфраструктуры. Мы решили использовать МЭ фирмы Nokia и ПО VPN-1 фирмы Check Point Software Technologies, поскольку эти продукты относительно легко устанавливаются.

Наша цель была проста: с помощью МЭ защитить наши лаборатории от вторжения извне и связать их через Интернет, используя технологию IPsec VPN. Но, как бывает в подобных случаях, у нас появились и специфические нужды. Это, например, необходимость иметь возможность легко удалять и добавлять в виртуальную частную сеть (ВЧС) новые лаборатории. И, как уже было упомянуто, нам нужно поддерживать связь с работающими на дому и находящимися в разъездах редакторами. Наши широкополосные соединения относятся к категории "бизнес-класса", что означает, что мы имеем некое количество статических IP-адресов. Однако нам от этого, как говорится, ни жарко ни холодно, поскольку ни один сервис-провайдер не хочет объявлять в сети Интернет IP-адреса наших подсетей класса С. Помня об этом, мы разработали архитектуру, которая соответствует нашим потребностям и имеет возможности для будущего развития.

Связь между лабораториями

Реализовать наше решение мы планируем в ближайшем будущем, а пока хотим поделиться с вами некоторыми деталями тех конкретных проблем, с которыми нам пришлось столкнуться, и с их решением (рис. 2).

Одна из проблем, первой вставшая на нашем пути, была IP-адресация. Лаборатории в Сиракузском университете и в Университете штата Висконсин имели полноценные адреса класса С. В других лабораториях наличествовала горстка адресов. И после того как "испарились" наши DSL-операторы, мы выяснили, что эти адреса очень скоро могут измениться. В процессе перехода мы хотим сделать три вещи:

1. Перенести весь трафик между лабораториями внутрь ВЧС.

2. Обеспечить некоторую переносимость адресов в случае, если провайдер "откроет" в Интернет наше адресное пространство.

3. Поддерживать доступ в Интернет через провайдера.

Нет нужды говорить о том, что все эти наши желания взаимосвязаны.

Заключить весь трафик между лабораториями в VPN-каналы относительно просто. Мы хотим создать сеть с ячеистой структурой, где каждая лаборатория могла бы напрямую связываться с другой. Использование сети со звездообразной топологией усложнило бы дело и породило бы проблемы с производительностью. Самой трудной частью в создании ячеистой сетевой структуры является организация маршрутизации на каждом МЭ и ее поддержка. В нашем случае это означает, что по меньшей мере шесть записей на каждом МЭ придется поддерживать вручную. В зависимости от ситуации с телекомьютингом мы сможем использовать протокол RIP или OSPF, чтобы по возможности упростить управление маршрутизацией.

Что касается поддержки переносимости адресов, то здесь можно сказать следующее: изменение IP-адресов - это сложная и утомительная задача, к тому же к IP-адресам "привязано" невероятное количество лицензий на сетевые приложения. Мы предпочли бы иметь статические адреса в каждой лаборатории. Однако наши подсети первоначально предназначались только для внутреннего использования - ясно, что мы должны тщательно следить за тем, чтобы чужой трафик не маршрутизировался через наши Интернет-соединения.

Поскольку мы не хотим использовать топологию "звезда", мы будем вынуждены маршрутизировать весь Интернет-трафик через локальные соединения. Наши подсети мы не можем объявлять в сети Интернет через местных провайдеров, поэтому придется использовать трансляцию сетевых адресов (Network Address Translation - NAT) для всех исходящих подключений к Сети. Вместе с тем не для всех наших соединений между лабораториями потребуется использование NAT.

Мы надеемся, что в большинстве случаев NAT не создаст каких-либо проблем. Однако в редких случаях, когда возникнет необходимость разрешить некоторый доступ к лабораторному оборудованию извне, мы будем вынуждены установить статические правила NAT отдельно для каждого конкретного случая.

Связь с телекомьютерами

Поддержка телекомьютеров порождает особые проблемы, поскольку приходится решать широкий круг вопросов, включая IP-адресацию, поддержку клиентских настольных систем, аутентификацию и протоколирование. Большинство наших удаленно работающих редакторов имеют широкополосные соединения и используют маршрутизаторы с трансляцией сетевых адресов для поддержки домашних сетей.

Это порождает, однако, проблемы с IPsec VPN, потому что во многих случаях трафик IPsec не может проходить через устройства NAT. В итоге нам ничего не остается, как:

1) купить либо маршрутизаторы с поддержкой NAT, которые будут пропускать трафик IPsec, либо МЭ с функциями VPN класса SOHO;

2) использовать протокол PPTP для подключения к сети Network Computing через VPN-канал;

3) использовать клиентское ПО, способное "обходить" NAT-маршрутизаторы посредством UDP-инкапсуляции.

Мы хотим использовать комбинацию из этих трех возможностей. В идеальном варианте наши сотрудники станут напрямую связываться по VPN-соединению со своей ЛВС, вместо того чтобы подключаться к концентратору, расположенному в одной лаборатории, чтобы связаться с другой.

Многие из наших сотрудников имеют домашние VPN-маршрутизаторы/межсетевые экраны, и главная трудность состоит в том, чтобы добиться их совместимости с оборудованием Nokia и ПО Check Point. Домашние МЭ нужно сконфигурировать таким образом, чтобы весь трафик, предназначенный для нашей корпоративной сети, направлять через VPN-каналы, а весь остальной трафик - в Интернет через местного провайдера.

Однако не у всех наших редакторов имеются домашние МЭ, поэтому там, где речь будет идти только о маршрутизаторе с NAT, мы будем использовать удаленный доступ по протоколу PPTP. Кроме того, протокол PPTP будут применять те наши пользователи, которые работают на машинах с отличной от Windows ОС, где невозможно использовать клиенты IPsec сторонних фирм.

В тех случаях, когда мы будем вынуждены обращаться к PPTP или к несовместимым с VPN-1 клиентам IPsec сторонних фирм, мы сможем отступить от нашего принципа и прибегнуть к установленному в нашей лаборатории в Сиракузах концентратору VPN 3005 Concentrator фирмы Cisco Systems, который сейчас применяется для удаленного доступа сотрудниками этой лаборатории. К сожалению, в этом случае трафик будет проходить более длинный путь, но мы предпочитаем поддерживать один концентратор удаленного доступа для всех пользователей, чем устанавливать и поддерживать несколько концентраторов.

Одновременно с ВЧС журнал Network Computing строит интрасеть. Одна из ее главных функций - консолидация аутентификации и контроля доступа пользователей к ресурсам. Мы используем самые разнообразные платформы, начиная от Windows и NetWare и кончая Solaris и Linux, и охватить все эти системы единым механизмом аутентификации чрезвычайно важно для нас. Наша цель - обеспечить, как минимум, аутентификацию пользователей по имени и паролю, используя протокол LDAP поверх SSL-соединения.

На начальном этапе реализации нашего VPN-решения применительно к телекомьютерам мы интегрируем его со справочником LDAP и по мере необходимости добавляем другие службы. Хотя мы не получаем при этом единой точки регистрации, все же централизация облегчает и упрощает управление бюджетами пользователей.

На следующем этапе в ВЧС будут использоваться цифровые сертификаты, а также имена и пароли, которые обеспечат идентификацию пользователей. Чтобы осуществить это, нам необходимо будет организовать удостоверяющий центр, работающий с VPN-клиентами и VPN-серверами. Эта задача намного труднее, чем кажется. Например, создатели компонентов Dial-Up Networking в Microsoft Windows 2000 и XP Professional предполагали наличие в цифровых сертификатах расширений, позволяющих использовать их для IPsec-аутентификации. Поэтому, если мы хотим поддерживать в среде Windows ее собственную VPN-технологию, мы должны обеспечить выпуск соответствующим образом сконфигурированных сертификатов. Другие VPN-клиенты тоже могут иметь подобные ограничения.

Конечно, все это только теория. Построить нашу ВЧС с оборудованием Nokia мы планируем в течение двух месяцев. Сначала, для выполнения начального конфигурирования и формулирования правил для ВЧС, мы проведем тестовую инсталляцию. Она позволит проверить нашу конфигурацию ВЧС в реальной управляемой провайдерами среде и подготовить оборудование, заранее сконфигурировав его для использования на удаленных узлах.

Как только все будет готово, мы займемся мониторингом межсетевых экранов и трафика, чтобы убедиться в том, что наша политика безопасности действует именно так, как мы и рассчитывали. Через несколько месяцев мы опубликуем новую статью на эту тему.