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

Одновременно с этим развиваются и технологии беспроводного доступа в интернет посредством мобильной связи. В РБ уже доступны и GPRS, и CDMA2000 - оба этих стандарта вполне справляются со своими задачами.

Два этих фактора не могли не породить потребности иметь не только доступ в интернет, но и возможность работать с корпоративными ресурсами, находясь вне стен офиса. Однако, как оказалось, сделать это не так просто. Проблема в том, что самый распространенный протокол организации VPN-соединений PPTP не может работать через трансляцию адресов, которую используют оба оператора, предоставляющие услуги GPRS и CDMA2000. Суть технологии трансляции заключается в том, что абоненту выдается IP-адрес из внутренней сети, как правило, это подсеть из диапазона 10.0.0.0. В результате оператор серьезно экономит на аренде реального пространства IP-адресов, но его абоненты теряют возможность пользоваться рядом протоколов, которые построены не на использовании TCP или UDP или требуют возможности приема соединений абонентом.

К сожалению, под это ограничение попал и PPTP, который использует протокол GRE, и L2TP, который использует протокол ESP. Эти протоколы, как правило, не работают через трансляцию адресов, а значит, не подходят для использования абонентами мобильной связи в РБ.

Компании Cisco и Microsoft отреагировали на эту проблему, выпустив версии протокола L2TP, которые способны работать через трансляцию адресов посредством использования для транспорта только UDP-пакетов. Однако оборудование Cisco не так дешево, чтобы использовать его только для решения этой проблемы, а поддержка модифицированного протокола L2TP (он еще называется NAT-T L2TP от NAT-Transparent) от Microsoft появилась только в Windows Server 2003, что тоже не радует, поскольку переустанавливать годами работающие шлюзы ради этого тоже не очень хочется. Про PPTP и вовсе забыли. С одной стороны, этот протокол уже давно не соответствует современным требованиям по глубине шифрования трафика, с другой, никто из производителей не отказывается от его поддержки вообще, но вот развивать уже не хотят, несмотря на нужды потребителей.

Ответ пришел, как ни странно, со стороны разработчиков программного обеспечения с открытым кодом. Существует проект OpenVPN, который ставит своей целью создание многоплатформенного гибкого решения для организации удаленного доступа. Изначально, как часто бывает, это решение работало только на Linux, но сейчас доступны версии для Windows, FreeBSD и ряда других операционных систем.

Как и L2TP, OpenVPN использует сертификаты PKI, но шифрование реализуется не через IPSec, а через SSL. Для транспорта OpenVPN может использовать как UDP, так и TCP, при этом он не привязан к какому-то конкретному порту, а его настройка проста (при наличии определенного опыта, разумеется).

В версии 1 протокол OpenVPN еще не поддерживает режим VPN-концентратора, т.е. узла, который может принимать множество VPN-соединений от пользователей. Эта возможность появилась в версии 2, которая хоть и находится на данный момент в стадии Beta, но работает довольно надежно. Версию 1 можно рекомендовать только тем, кому нужно установить только одно соединение, поскольку для второго тоннеля потребуется запускать еще один сервис на другом порту.

Настройка серверной части в версии 2 сводится к генерированию ключа сервера и созданию файла конфигурации, в котором, помимо всего прочего, задается тип протокола, порт, пул адресов, из которого будут назначаться адреса мобильным клиентам и имена файлов с ключом сервера и CA (Certificate Authority). При этом сервер может быть настроен в двух режимах - маршрутизатора или моста. В режиме моста удаленный клиент получает полный доступ в Сеть, включая и широковещательные пакеты, но для этого требуется поддержка возможности наведения моста между интерфейсами в ОС, на которой установлен сервер. Для больших сетей, не разбитых на сегменты второго уровня, применять этот режим нужно с осторожностью - при наличии большого количества широковещательного трафика, тонкий канал до удаленного клиента может быть перегружен широковещательным трафиком.

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

Итак, серверная часть почти готова - осталось решить, на каком порту и по какому протоколу он будет принимать соединения. По умолчанию это протокол UDP и порт 5000, если ориентироваться на всех ваших пользователей, которым может понадобиться доступ из другой корпоративной сети, то становится понятно, что логичнее использовать какой-то стандартный порт, который должен быть открыт в максимальном количестве корпоративных сетей. Например, порт 443/TCP. Вряд ли кто-то будет закрывать порт HTTPS. При этом клиент OpenVPN поддерживает работу через прокси и даже с возможностью аутентификации. Другими словами, выбор порта 443 и протокола TCP является одним из самых универсальных. Еще можно посоветовать порты 53/UDP и 25/TCP.

Настройка клиента производится еще проще - нужно указать адрес сервера, порт, тип протокола и имя файла с ключами клиента и CA. Сами ключи, разумеется, перед этим нужно сгенерировать (в случае необходимости) и скопировать на компьютер клиента.

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

Можно использовать и пакетные файлы - сам клиент OpenVPN запускается из командной строки и может принимать массу конфигурационных параметров. Гибкость OpenVPN находится на очень высоком уровне.

Отдельного внимания заслуживает то, каким образом OpenVPN создает интерфейс для обмена пакетами с удаленным клиентом. В отличие от PPTP, он создает виртуальный Ethernet-интерфейс изначально во время установки, и только уже после установки соединения переводит его в активное состояние (которое Windows воспринимает как подключение кабеля) и присваивается адрес. Плюс подобного решения в том, что такой интерфейс может работать в режиме моста и пропускать широковещательные пакеты.

Есть еще две примечательные особенности - применение компрессии LZO и способность "проталкивать" маршруты для клиента. Компрессия позволяет ускорить прокачку информации, которая, в принципе, сжимается, а "проталкивание" маршрутов позволяет передать клиенту список сетей, которые доступны через это VPN-соединение.

Думаю, многие, кто использовал протокол PPTP, знают об этой его неприятной особенности - если подключиться к интернету и установить VPN-соединение, то пропадет возможность работать с интернетом, но появится доступ в корпоративную сеть. Причина этого в том, что при установке VPN-соединения маршрут по умолчанию перестраивается на это соединение, и все пакеты, направленные в интернет, попадают вместо этого на VPN-шлюз, который, как правило, не поддерживает доступ в интернет через VPN-соединение (и правильно делает).

OpenVPN лишен этого недостатка, поскольку можно настроить сервер так, чтобы он сообщал клиенту точный список сетей, маршруты на которые следует установить через это VPN-соединение. В итоге, при использовании OpenVPN можно работать как с вашими внутренними ресурсами, так и с ресурсами сети интернет одновременно.

Сайт команды разработчиков расположен по адресу openvpn.sourceforge.net.

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

Алексей ГРЕЧАНИНОВ