Развертывание сети VPN

Павел Покровский
30.01.2003
LAN, #01/2003

В одной достаточно крупной компании, где имелась разветвленная сеть удаленных площадок, потребовалось развернуть виртуальную частную сеть (Virtual Private Network, VPN) и наладить шифрование информации между центральным и удаленными офисами, чтобы каждый филиал мог связываться с другим через защищенное соединение. Конкретное название используемой системы и точный алгоритм шифрования не имеют значения для целей статьи, так как одной из изюминок спроектированной схемы организации VPN была независимость решения от платформы и программного окружения. В общем случае шифратор является сквозным, т. е. шифрует все, что поступает в открытом виде на один из его интерфейсов, и передает в сеть уже зашифрованные данные через другой интерфейс.

Казалось бы, проще всего включить шифратор в «разрыв» локальной сети, т. е. установить его между коммутатором и маршрутизатором. Но одним из условий развертывания VPN было обеспечение бесперебойного функционирования сети в целом, независимо от того, включено шифрование или нет. Подключение шифратора вело к появлению узкого места в любом случае, однако при его установке на «горло» сети бесперебойность работы подвергалась серьезной опасности, так как, выйди шифратор из строя, данный офис потеряет связь с остальными. Для центрального офиса кратковременная потеря связи с удаленными площадками — небольшая трагедия, а вот последние удаленно работали с серверами, физически расположенными в центральном офисе компании, так что простои вследствие неполадок в работе шифрующего оборудования были недопустимы. Таким образом, функционирование локальной сети в целом должно было быть обеспечено независимо от работы шифраторов.

СХЕМА СЕТИ

Все рабочие станции центрального офиса и часть серверов подключались к одному коммутатору. Прочее серверное оборудование центрального офиса работало через другой коммутатор и относилось к демилитаризованной зоне. Оба коммутатора соединялись с маршрутизатором Cisco, который и связывал локальные сети центрального и удаленных офисов в единую корпоративную сеть. Топология удаленной локальной сети выглядела еще проще: коммутатор для подключения серверного оборудования отсутствовал, поэтому не было и демилитаризованной зоны, а единственный коммутатор присоединялся напрямую к маршрутизатору Cisco; тот, в свою очередь, связывался с маршрутизаторами центрального и удаленных офисов. Их взаимодействие осуществлялось по протоколу динамической маршрутизации EIGRP.

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

Одному из интерфейсов шифратора был назначен IP-адрес той локальной сети, где он был установлен. Второму — IP-адрес виртуальной сети класса C. Для простоты первый интерфейс назовем «внутренним», а второй — «внешним». Открытый трафик поступал на внутренний интерфейс, а с внешнего отправлялся уже зашифрованный трафик, причем он был инкапсулирован таким образом, что IP-адресом отправителя пакета являлся IP-адрес внешнего интерфейса шифратора, а IP-адресом получателя — IP-адрес внешнего интерфейса шифратора того офиса компании, для которого предназначался изначальный открытый пакет. Сам шифратор не занимался никаким анализом проходящего через него трафика, т. е. был, как уже говорилось, сквозным.

ОРГАНИЗАЦИЯ ШИФРУЕМОГО СОЕДИНЕНИЯ

Для пояснения схемы мы рассмотрим пример работы по защищенному соединению между центральным офисом и одной из удаленных площадок. Трафик из локальной сети центрального офиса через коммутатор поступал на маршрутизатор Cisco. На маршрутизаторе были заданы правила условной маршрутизации (policy routing), согласно которым трафик, предназначавшийся для удаленного офиса компании, направлялся не в среду ATM, а на внутренний интерфейс установленного в локальной сети шифратора. Наглядно схема включения шифратора в сеть представлена на Рисунке 1. Маршрутизировать трафик — дело маршрутизатора, так что возлагать функции анализа трафика на шифрующие устройства не стоит. Шифратор «знал» только ключи шифрования для конкретных адресов получателей.

Рисунок 1. Схема сети с шифратором.

С внешнего интерфейса шифратора инкапсулированный защищенный трафик направлялся опять-таки на маршрутизатор, на интерфейсе Ethernet которого было задано два IP-адреса: один — соответствовал локальной сети центрального офиса; другой — принадлежал виртуальной сети шифратора и служил для него шлюзом по умолчанию. Далее зашифрованный пакет снова сверялся со списками доступа маршрутизатора, где описываются правила динамической маршрутизации EIGRP, и, согласно им, направлялся в то или иное подразделение компании. Маршрутизатор удаленного офиса имел схожую конфигурацию, но не хранил сложные списки доступа c описанием маршрутизации EIGRP, а все пакеты, в том числе предназначавшиеся для других удаленных площадок, пересылались в центральную сеть. На интерфейсе Ethernet маршрутизатора удаленного офиса также было задано два IP-адреса: один принадлежал локальной сети филиала, а второй — виртуальной сети установленного там шифратора и являлся для шифратора шлюзом по умолчанию.

Внешнему интерфейсу шифратора центрального офиса был назначен IP-адрес 192.168.0.2, внутреннему — 10.0.0.253. Все машины в локальной сети имели адрес из сети 10.0.0.0/24. Для интерфейса Ethernet на маршрутизаторе центрального офиса были определены адреса 10.0.0.1 и 192.168.0.1. На шифраторе в качестве шлюза по умолчанию был задан адрес 192.168.0.1. На всех рабочих станциях центрального офиса в качестве адреса шлюза по умолчанию был указан адрес 10.0.0.1.

Внешнему интерфейсу маршрутизатора удаленного офиса соответствовал IP-адрес 192.168.1.2, а внутреннему — 10.0.1.253; все машины локальной сети удаленного офиса имели адреса из сети 10.0.1.0/24. Интерфейсу Ethernet на маршрутизаторе были назначены адреса 10.0.1.1 и 192.168.1.1. На шифраторе в качестве шлюза по умолчанию был указан адрес 192.168.1.1. На всех рабочих станциях локальной сети удаленного офиса в качестве шлюза по умолчанию был задан адрес 10.0.1.1. В скобках отметим, что приведенные адреса не существуют реально и используются только для иллюстрации схемы.

Предположим, клиент из удаленной сети хочет установить защищенное соединение с сервером из центрального офиса по протоколу telnet. Его рабочая станция имеет IP-адрес 10.0.1.22, а сервер центрального офиса — 10.0.0.44. Таким образом, трафик от удаленного клиента имеет адрес отправителя 10.0.1.22 и адрес получателя 10.0.0.44, порт 23 (telnet). Поскольку шлюзу по умолчанию в удаленном офисе присвоен адрес 10.0.1.1, то все пакеты поступают на маршрутизатор Cisco. На маршрутизаторе настроены списки доступа, где описываются правила условной маршрутизации: в частности, пакеты, предназначающиеся сервису telnet (TCP-порт 23), должны маршрутизироваться не напрямую в центральный офис, а на внутренний интерфейс шифратора.

Пакет от маршрутизатора попадает на указанный интерфейс, затем производится шифрование и инкапсуляция пакета. В результате с внешнего интерфейса шифратора удаленного офиса отсылается пакет с адресом отправителя 192.168.1.2 (внешний интерфейс шифратора удаленного офиса), адресом получателя 192.168.0.2 (внешний интерфейс шифратора центрального офиса), TCP-портом получателя 23. Пакет следует на интерфейс Ethernet маршрутизатора удаленного офиса, где, в соответствии с правилами маршрутизации для сети 192.168.0.0/24, направляется в центральный офис, на маршрутизаторе которого настроен список доступа — согласно ему, пакет с адресом получателя из сети 192.168.0.0/24 передается на внешний интерфейс шифратора (192.168.0.1). Далее он декапсулируется, расшифровывается и с внутреннего интерфейса шифратора центрального офиса попадает в сеть с адресом отправителя 10.0.1.22, адресом получателя 10.0.0.44 и портом получателя 23 (telnet), т. е. с исходными данными. После поступления на маршрутизатор пакет передается далее в соответствии с обычными правилами маршрутизации в локальной сети. В обратном направлении диалог сервера 10.0.0.44 с клиентом 10.0.1.22 происходит в соответствии с аналогичной процедурой, за исключением того, что списки доступа условной маршрутизации создаются на основании TCP-порта отправителя, а не получателя.

ПЛЮСЫ И МИНУСЫ

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

У данного подхода есть еще одно неоспоримое преимущество — это бо’льшая устойчивость сети в целом по сравнению с подключением шифратора на «горло» локальной сети. В частности, протоколы динамической маршрутизации позволяют определить доступность интерфейсов шифратора и автоматически перестроить таблицу маршрутизации в случае выхода из строя одного из интерфейсов либо шифратора в целом. Никакой инкапсуляции проводиться не будет, так что офисы компании станут доступны друг другу по сети. Но подобное решение имеет одну очень неприятную особенность: если администратор не узнает об изменении таблиц маршрутизации, то передаваемый в открытом виде трафик может оказаться скомпрометированным. На такой случай нужно предусмотреть схему оповещения администратора.

Может показаться, что при статической маршрутизации схема параллельного включения шифратора в сеть ничем не отличается от схемы его подключения на «горло» сети, так как связь все равно пропадет, но это не так. Откат конфигурации маршрутизатора (хотя бы даже удаленно) осуществить гораздо проще, чем физически перекоммутировать оборудование на непосредственную маршрутизацию. У такого подхода есть свои плюсы — о защите трафика несложно позаботиться еще до того, как он попадет в среду передачи данных, где может произойти его компрометация.

Мы намеренно не использовали встроенные возможности маршрутизатора Cisco по созданию VPN, так как уверены в следующем:

1. маршрутизатор должен заниматься только маршрутизацией, а шифрованием - отдельное устройство;
2. налицо значительная разница в стоимости IOS с поддержкой шифрования и IOS без таковой; кроме того, нельзя не учитывать существующие экспортные/импортные ограничения на криптографическое оборудование и алгоритмы;
3. алгоритм шифрования DES, характерный для Cisco IOS, не считается устойчивым, и его применение не рекомендуется;
4. процессор Cisco оптимизирован на выполнение простых логических функций и работу с маршрутизацией; сложные математические операции шифрования создают непропорциональную нагрузку.

УСЛОВНАЯ МАРШРУТИЗАЦИЯ

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

В настройках Cisco рекомендуется отключить IP Redirect на интерфейсах Ethernet посредством команды no ip redirects в конфигурации интерфейса Ethernet, поскольку при создании условного маршрута маршрутизатор с настройками по умолчанию рассылает широковещательное ICMP-сообщение Network Redirect. при его получении машины из подсети меняют статический маршрут для сети, для которой задан условный маршрут Cisco, со шлюза по умолчанию на криптошлюз. Естественно, в ситуации, когда необходимо восстановить изначальную конфигурацию сети (без криптошлюзов), откат не ограничивается восстановлением конфигурации Cisco — помимо этого, изменение маршрутов необходимо произвести вручную на рабочих станциях и серверах защищенной сети.

ДОВЕРЯЙ, НО ПРОВЕРЯЙ

Работа шифраторов контролировалась очень просто: в том же сегменте сети, где был установлен шифратор, была размещена машина под управлением Linux с установленной на ней программой tcpdump. На порту коммутатора, к которому подключен шифратор, была включена функция мониторинга. Трафик дублировался на порт коммутатора, к которому была подключена машина под управлением Linux с программой tcpdump. Сетевой интерфейс машины перевели в режим приема всех пакетов (promiscuous mode). Tcpdump настроили так, чтобы отслеживать только пакеты, у которых адреса источника и получателя принадлежали к виртуальным сетям шифраторов. Таким образом, было видно, что пакеты инкапсулируются, а их содержимое зашифровано.

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

Автор выражает благодарность Мяснянкину Владиславу (hugevlad@yahoo.com) и Карфидову Игорю (karfidoff@rambler.ru), с чьей помощью была развернута вышеописанная сеть VPN.

Павел Покровский — специалист по информационной безопасности. С ним можно связаться по адресу: underling@yandex.ru.