Технология виртуальных частных сетей сегодня как никогда пользуется большой популярностью. Ее применяют провайдеры для подключения пользователей к интернету, системные администраторы объединяют при помощи VPN удаленные офисы, командировочные и надомные сотрудники, работающие вне корпоративной сети, подключаются ко внутренним ресурсам компании по безопасному каналу. Технологий и протоколов разработано немало, все они имеют свои особенности, достоинства и недостатки, требуют специфических настроек роутеров. Попробуем навести порядок в знаниях.
Типичная для небольших городов или удаленных районов ситуация: кто-то покупает жирный канал и затем перепродает его желающим подключиться к интернету. Как правило, в этом случае параллельно создается локалка, через которую и обеспечивается подключение. Внутри LAN пользователи сами организуют внутренние сервисы, что является дополнительным стимулом к подключению. Для раздачи интернета в таком варианте лучше всего "подойдут" протоколы PPPoE и PPTP, наиболее популярные и удобные в классе host-to-network. Почему эти, а не другие? Давай разберемся.
Причины популярности PPPoE и PPTP банальны: клиенты имеются во всех популярных ОС, включая *nix. Процесс подключения и настройки достаточно прост и не требует особой подготовки. В Windows PPPoE и PPTP поддерживаются из коробки, пользователю стоит лишь настроить новое подключение в разделе "Сетевые подключения".
Конечно, это не догма, и часто выбор протокола зависит от предпочтений сисадмина, который будет все настраивать. Многие из администраторов посчитают более "удобным" OpenVPN, который отлично защищен, прост в настройке и адаптирован для работы из-за NAT. Но такое решение все-таки ориентировано именно на построение VPN подключения, а не как средство организации доступа в интернет, со всеми вытекающими последствиями, в частности, отсутствием готового и удобного биллинга. К тому же клиентам потребуется установка дополнительного ПО, что многими не приветствуется. Другой вариант – L2TP/IPsec – предпочтительнее с точки зрения безопасности, но значительно сложнее в настройках, поэтому, если его и предлагают провайдеры, то только как альтернативу PPPoE или PPTP для продвинутых и/или параноидальных пользователей. Если ты решил поднять платный VPN, чтобы другие юзеры или мелкие фирмы могли безопасно подключаться к сервисам интернета, скрывать свой IP, или же обходить блокировку IP на сайтах, отслеживающих регион посетителя, то кроме "традиционного" в таких случаях PPTP, следует обязательно предложить более защищенную альтернативу, вроде OpenVPN или L2TP/IPsec, снабдив пользователей подробными инструкциями по подключению.А вот выбор PPPoE или PPTP зависит от топологии и особенностей сети.
Подключение по протоколу PPPoE (Point-to-point protocol over Ethernet, RFC 2516) у клиентов обычно вызывает меньше проблем, поскольку пользователю всего лишь нужно помнить свой логин и пароль. Причем процесс настройки прост как в Windows, так и в *nix системах. Учитывая, что PPP соединение можно шифровать, раскрыть передаваемые данные нельзя. Поиск сервера провайдера производится автоматически при помощи широковещательного PADI-пакета (PPPoE Active Discovery Initiation), передаваемого на канальном уровне, то есть клиенту не нужно задавать IP-адрес сервера доступа, как при настроке PPTP. Более того, в сети параллельно может работать несколько серверов, которые одновременно отвечают клиенту на запрос, а клиент сам решает, к какому из них он будет подключаться. Сервера никак не мешают друг другу, поэтому достаточно просто организовать резервирование PPPoE подключения.Просмотреть список доступных серверов в *nix можно запустив утилиту pppoe-discovery, которая отправляет PADI пакет и выводит результат, имя сервера и его MAC-адрес.
# pppoe-discovery -I eth0 Access-Concentrator: MT-01
Это и есть наш сервер. Если в сети несколько PPPoE серверов, и нужно подключиться к определенному, явно указываем его в настройках /etc/ppp/peers/dsl-provider:
# nano /etc/ppp/peers/dsl-provider
plugin rp-pppoe.so rp_pppoe_ac MT-01 eth0
Использование второго сервера позволит также зарезервировать и другие полезные сервисы: DHCP, DNS и прочие. Для PPPoE еще одним очевидным преимуществом является возможность использования простых средств аутентификации и проверки полномочий на базе протокола RADIUS.
Недостатки PPPoE вытекают из его достоинств. Так как он работает только в сети Ethernet, то использование транзитных IP-маршрутизаторов недопустимо. В крупных, разветвленных сетях поиск сервера обычно затягивается, а широковещательные пакеты могут "застревать" в роутерах. Поэтому PPPoE эффективен при использовании в относительно небольших или средних обособленных сетях. Также стоит отметить, что стабильная работа PPPoE через WiFi не гарантируется: через некоторое время может возникнуть «подвисание» соединения. Для решения этой проблемы придется ставить дополнительный роутер на границе WiFi и Wired LAN, который и будет подключаться к PPPoE серверу.
Еще одна проблема, которая иногда всплывает – это размер MTU. Дело в том, что максимальный размер Ethernet-пакета равен 1500 байт, а максимальный размер пакета, передаваемого через PPPoE, равен 1492 байта (заголовок PPPoE – 6 байт и PPP Protocol ID – 2 байта). Некоторые роутеры поддерживают технологию Path MTU Discovery, которая запрещает фрагментацию пакетов. При этом оптимальный размер пакета определяется автоматически на основе сообщений ICMP (тип 3, код 4: Fragmentaion Needed and DF set, см. www.oav.net/mirrors/cidr.html). То есть если на каком-то этапе ICMP пакеты блокируются, между хостами могут возникнуть проблемы с обменом данными. Проверить MTU очень просто. Например, введем:
> ping synack.ru -f -l 1492
Требуется фрагментация пакета, но установлен запрещающий флаг. Как видишь, пакет размером 1492 не прошел. По умолчанию в Windows устанавливается MTU для протокола РРРоЕ равное 1480 байт, но некоторые программы или драйвера могут его изменить.Чтобы установить свое значение, следует создать раздел (если его нет) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Ndiswan\Parameters\Protocols\0, в котором прописать три REG_DWORD параметра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Ndiswan\Parameters\Protocols\0
В Linux проще автоматически уменьшать размер передаваемого пакета средствами pppd или ifconfig. Для pppd добавляем такую настройку:
# nano /etc/ppp/pppoe.conf
CLAMPMSS=1412
В правиле используется не MTU, а фактический блок данных MSS (Maximum Segment Size, максимальный размер сегмента), добавив к нему служебную инфу 40 байт (20 байт IP и 20 байт TCP), получим MTU.
При использовании ifconfig вот так указываем MTU интерфейса:
# ifconfig ppp0 mtu 1400
Протокол PPTP (Point-to-point tunneling protocol) позволяет клиентскому компьютеру организовать подключение к серверу через туннель в незащищенной сети. В PPTP кадры PPP инкапсулируются в IP-пакеты, что позволяет соединяться с сервером, который находится в другой сети. При создании туннеля в РРТР используется дополнительное (управляющее) TCP-соединение (порт 1723). После обмена служебными сообщениями создается соединение для пересылки данных (протокол Generic Routing Encapsulation, GRE).
Как и PPPoE, PPTP достаточно прост в настройке. Однако пользователь, помимо логина и пароля, должен знать еще IP-адрес сервера. Трудности в этом никакой – просто еще один шаг в настройках. Понятно, что сервер, к которому подключаются клиенты, не обязательно должен находиться в том же сегменте сети. Учитывая, что поддержка PPTP встроена в Windows "из коробки" (Microsoft является одним из его разработчиков), этот протокол получил большую популярность. Нет проблем и при подключении из *nix систем, достаточно установить pptp-client (pptpclient.sf.net), который есть в репозитариях и портах практически всех дистрибутивов. Из лицензионных соображений поддержка MPPE долгое время была доступна исключительно в виде патчей. Теперь MPPE встроен в ядра многих ОС. Например, поддержка шифрования MPPE появилась в ядре Linux версии 2.6.14, поэтому в настоящее время никаких дополнительных манипуляций производить не требуется.
Для аутентификации используются следующие методы: PAP, CHAP, SPAP, MSCHAP v1 и v2, EAP. Пользователь определяется по логину/паролю, но слабая защищенность механизмов аутентификации делает PPTP сессии легкой добычей для злоумышленников. Протокол уязвим практически для всех видов атак: атаки на LM-хеши, алгоритмы RC4, CHAP, MSCHAP v1 и v2 и так далее. За примером далеко ходить не нужно – утилита asleap (willhackforsushi.com/Asleap.html) призвана "восстанавливать" PPTP MSCHAP пароли. Как результат, от PPTP, как средства построения VPN (для чего он, собственно, и планировался), многие отказались в пользу более защищенных решений.
Проблему пытались решить, для чего к PPTP прикрутили EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) аутентификацию. Хотя это и сделало процесс распознавания пользователя более безопасным, но не устранило все уязвимости, связанные с передачей данных.
Также следует напомнить, что при использовании PPTP изменяется маршрут по умолчанию, и в результате весь трафик идет по защищенному VPN соединению. Зачастую это приводит к проблемам доступа ко внутренним ресурсам LAN, а в некоторых случаях даже к отключению от VPN-сервера. Многие провайдеры вынуждены на своих ресурсах дополнительно выкладывать таблицу маршрутизации, чтобы пользователи могли подключиться к VPN серверу, одновременно работать в интернете и подключаться к ресурсам "районной сети".Для подключения к PPTP серверу необходимо открыть 1723/TCP порт и разрешить GRE протокол (номер 47):
iptables -A INPUT -p tcp -s IP_VPN_сервера -d локальный_IP --sport 1723 -j ACCEPT iptables -A INPUT -p gre -s IP_VPN_сервера -d локальный_IP -j ACCEPT iptables -A OUTPUT -d IP_VPN_сервера -s локальный_IP -j ACCEPT
Для PF правила также несложны, пример можно посмотреть в статье "Свет в конце криптотуннеля" (www.xakep.ru/magazine/xa/109/160/1.asp), посвященной настройкам PPTP-сервера на базе FreeBSD/mpd и OpenBSD/poptop.
Есть одна проблема, которая мешает использовать PPTP при подключении пользователей к серверу через NAT. При таком соединении может быть активным только один VPN канал. В Linux это решается путем активации модуля ядра ip_nat_pptp, просто запускаем:
# /sbin/modprobe ip_nat_pptp
И все будет работать. Но в случае PF возникают сложности. Судя по всему, он не может корректно транслировать GRE-протокол, поэтому из локальной сети с частными (глобально немаршрутизируемыми) IP-адресами невозможно организовать несколько PPTP подключений. Вариантов выхода из ситуации несколько, один из них – трансляция PPTP соединений с помощью IPFW. Активируем пакетный фильтр и указываем скрипт с правилами:
# vi /etc/rc.conf
firewall_enable="YES" firewall_nat_enable="YES" firewall_script="/etc/ipfw.gre"
Теперь разрешаем прохождение нужных пакетов:
# vi /etc/ipfw.gre
#!/bin/sh /sbin/ipfw -q /dev/stdin <<RULES flush nat 10 config if fxp0 add 10 nat 10 gre from any to any add 11 nat 10 tcp from any to any dst-port pptp add 12 nat 10 tcp from any pptp to any add allow all from any to any RULES
Не забываем сделать скрипт /etc/ipfw.gre исполняемым:
# chmod +x /etc/ipfw.gre
В рулесетах PF запрещаем транслировать PPTP соединения и просто пропускаем их через фильтр:
# vi /etc/pf.conf
no nat on $external proto gre all no nat on $external proto tcp from any to any port = pptp no nat on $external proto tcp from any port = pptp to any
pass quick on $external inet proto tcp from any to any port 1723 pass quick on $external inet proto tcp from any port 1723 to any pass quick on $external inet proto gre from any to any
Но это не единственный вариант. Для трансляции PPTP пакетов можно задействовать специальные прокси, например, Frickin PPTP Proxy (frickin.sf.net) или pptpproxy (mgix.com/pptpproxy). На момент написания этих строк в OpenBSD 4.6-current добавили демон npppd, призванный разруливать множественные PPP сессии и помочь пользователю в установлении соединений по L2TP, PPTP и PPPoE.
Наличие удаленных офисов или складских помещений у компании сегодня не редкость. При такой "топологии" сотрудники в процессе работы должны обращаться ко внутренним ресурсам, размещенным на центральных серверах. Задача админа в этом случае заключается в том, чтобы максимально упростить процесс, не поставив под удар защищенность всей сети. Альтернативы VPN здесь нет, но выбор вариантов реализации достаточно широк: OpenVPN, L2TP/IPsec, PPTP, VTun (vtun.sf.net), SSH VPN и некоторые другие.
Напомним, что многие файерволы имеют все необходимое для организации такого канала: ISA Server ("Надежный сторожевой сети", X_05_2007), Kerio WinRoute Firewall ("Марш-бросок в большую сеть", X_09_2007), ITC Server (trafficcontrol.ru) и т.д. Если есть возможность выбора, одним из наиболее подходящих решений для организации site-to-site VPN является OpenVPN. Причин несколько. Реализация имеется для большинства популярных операционных систем: Linux, *BSD, Solaris, Mac OS X, Windows от 2000. Установка и настройка OpenVPN достаточно проста и под силу любому админу, представляющему процесс (подробнее о настройке OpenVPN читай в статьях "Доступ повышенной защищенности" и "Деликатное проникновение в частную сеть", опубликованных X_04_2007 и X_02_2008 соответственно). Для аутентификации и шифрования используются все доступные в SSL алгоритмы, поэтому можно запросто выбрать нужный, в соответствии с требованиями, предъявляемыми к защищенности (также стоит учесть пропускную способность канала и стоимость трафика).
Существенно, что поддерживается адаптивная компрессия потока, а работа через NAT происходит без проблем.
Еще одной альтернативой является использование протокола IPsec, большой плюс которого – встроенная поддержка всеми ОС, как Windows (от XP/2k3SP2 и выше), так и *nix. Соответствующие настройки для подключения имеются и в большинстве хардварных роутеров. Первоначальные настройки IPsec в *nix можно назвать простыми. Так ядра *BSD и Linux уже поддерживают IPsec. Если ядро Linux собиралось самостоятельно, то нужно проследить, чтобы были включены пункты "IPsec: transport mode", "IPsec: tunnel mode", "IPsec: BEET mode", "IP: AH transformation" "IP: ESP transformation" и "IP: IPComp transformation" и "PF_KEY sockets", находящиеся в "Networking support – Networking options". Опционально включаем поддержку протокола IPComp (IP Payload Compression Protocol). Также требуется активировать все пункты в Cryptographic API. Если для ускорения обработки криптографических вычислений будет использоваться специальная плата (это позволит снизить требования к CPU), то не забудь и про пункты в "Hardware crypto Devices".
Для работы IPsec использует следующие порты и протоколы:
Для установления IPsec соединений в файерволе следует открыть порт 500 и разрешить прохождение данных по протоколам AH/ESP. Приведем пример для iptables:
# iptables -A INPUT -p udp --dport 500 -m state --state NEW -j ACCEPT # iptables -A OUTPUT -p udp --dport 500 -m state --state NEW -j ACCEPT # iptables -A INPUT -p esp -j ACCEPT # iptables -A OUTPUT -p esp -j ACCEPT # iptables -A INPUT -p ah -j ACCEPT # iptables -A OUTPUT -p ah -j ACCEPT
Для управления туннелем понадобится набор утилит IPsec-tools (ipsec-tools.sf.net).Основной минус IPsec состоит в том, что маршрутизаторы не умеют извлекать заголовки, поэтому работа через NAT невозможна. Для устранения этой проблемы разработан протокол NAT-Traversal (NAT-T), обеспечивающий передачу ESP через UDP (ESPinUDP) и использующий в своей работе порт 4500/UDP. При выборе аппаратного маршрутизатора следует обратить внимание на поддержку NAT-Traversal, это снимет ряд вопросов при настройке туннеля IPsec. Если роутер уже есть, то возможно для него доступна прошивка, в которой данный протокол уже поддерживается. Обновления можно поискать на сайте производителя или на специализированных ресурсах вроде DD-WRT (dd-wrt.com), FreeWRT (freewrt.org), OpenWRT (openwrt.org), Midge (midge.vlad.org.ua) и так далее.
Ядро Linux уже поддерживает ESPinUDP, для его использования достаточно в настройках сервера разрешить NAT-Traversal в ipsec.conf:
nat_traversal=yes
Напомним, что кроме реализации IPsec, встроенной в ядро Linux, есть и альтернативы: strongSwan (strongswan.org) и Openswan (www.openswan.org).
Windows обзавелся поддержкой NAT-T еще в версиях 2000/SP3 и XP/SP2. Чтобы активировать функцию NAT-T в WinXP, следует в ветке реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPsec создать DWORD параметр
AssumeUDPEncapsulationContextOnSendRule и установить его в одно из трех значений, определяющих порядок использования IPsec:
Кстати, Microsoft выпустила инструмент Microsoft IPsec Diagnostic Tool, который позволяет отслеживать состояние IPsec-соединения на локальной или удаленной машине и диагностировать проблему подключения. Утилита работает в WinXP/2k3/Vista/2k8.
Чтобы решить проблемы PPTP и IPsec, в новых версиях Windows (Vista SP1, Win7 и Win2k8) Microsoft предлагает использовать подключения по протоколу SSTP (Secure Socket Tunneling Protocol, см. статью "Слоеный VPN" из августовского номера ][ за 2008 год).
Все ОС Windows, начиная с версии 2000, имеют все необходимое для подключения по IPsec, однако встроенный клиент сложен в настройке даже для администраторов, не говоря уже о рядовых пользователях. Именно поэтому многие обращаются к программам от сторонних разработчиков. Большой популярностью за рубежом пользуется TheGreenBow VPN Client (thegreenbow.com/vpn.html), имеющий большое количество настроек, в том числе аутентификацию при помощи смарт-карт.
D-Link VPN Client обеспечивает удобное подключение по IPsec (шифрование 3DES/AES и поддержка NAT-T) к VPN шлюзам, образованным различными продуктами D-Link.
Линуксоиды, вероятно, предпочтут программу, имеющую графический интерфейс, такую как KVpnc (работает с IPsec, IPsec/L2TP, PPTP, OpenVPN, Cisco, Vtun и SSH).
Также хочется отметить небольшой и бесплатный Shrew Soft VPN Client (shrew.net), доступный как для Windows (от 2k до Se7en), так и для FreeBSD, NetBSD, Linux. Он поддерживает подключение к туннелям, образованным IPsec-tools, OpenSWAN, FreeSWAN, StrongSWAN и Isakmpd.
Как ты мог убедиться, организация VPN-сервиса требует тщательного планирования и предварительного ознакомления с особенностями каждого протокола. При настройке защищенных соединений на стороне клиента нюансов и неувязок также предостаточно. Мы надеемся, эта статья прольет свет на подводные камни технологии виртуальных частных сетей и поможет тебе решить возникшие проблемы.
Часто помехой при создании VPN становится динамический IP, выдаваемый провайдером. Проблему можно решить при помощи специализированных сервисов динамического DNS. На таких сервисах время устаревания TTL указывается достаточно маленьким, поэтому другие DNS сервера фактические его не кэшируют. Вместо IP-адреса VPN-сервера в настройках подключения можно указать закрепленное доменное имя. Многие хардварные роутеры имеют встроенную поддержку Dynamic DNS. Сегодня доступно несколько таких серверов – dyndns.org, dyndns.dk,no-ip.com. Полный список смотри в DMOZ – dmoz.org/Computers/Internet/Protocols/DNS/DNS_Providers/Dynamic_DNS
