Site-to-Site VPN на основе PPTP и ClearOS в качестве VPN-концентратора

 

Итак, представим, что компания в которой вы установили ClearOS в качестве сетевого шлюза и возможно чего-нибудь ещё, решила открыть пару филиалов. В соответствии с новой задачей, необходимо обеспечить тесную интеграцию ИТ-систем филиалов в единую, управляемую сеть. Естественно на ум приходит мысль о построении VPN, но сразу возникает вопрос, на основе чего её строить? Конечно, если у вас в подсобке завалялось несколько маршрутизаторов Cisco, в филиалах уже используется, или планируется использовать ClearOS или компания, в которой вы работаете просто достаточно богата, правильное решение напрашивается само собой. Но если в подсобке лежат лишь поломанные механические мышки, деньги на покупку нового оборудования достаются с большим трудом, а городить для трёх с половиной компьютеров в филиалах шлюзы на базе ClearOS не целесообразно, можно пойти другим путём. Кстати, с VPN между парой ClearOS-ов тоже, увы не всё гладко, о чём будет сказано ниже.

В ClearOS доступно три технологии для построения VPN. Для подключения клиентских компьютеров предпочтительным выглядит использование сервера PPTP. Для построения же межсетевых VPN соединений остаются два других варианта: OpenVPN и IPSEC, последний кстати изначально для этого и предназначался. Но вот вопрос, много ли вам встречалось дешёвых роутеров (которые планируется ставить в филиалах) имеющих встроенного OpenVPN клиента? Итого остаётся специально предназначенный для данной задачи IPSEC.

И вот выбрав недорогой роутер с поддержкой IPSEC вы обнаруживаете, что реализация IPSEC в ClearOS 5.2 сделана, скажем аккуратно, не наилучшим образом. Хорошо, если без большого напильника вообще удастся установить IPSEC соединение с чем-либо отличным от другой ClearOS, но нам желательноне только устанавливающееся, но и стабильно работающее VPN-соединение, а ведь на нашем тернистом пути может встретиться и NAT, и динамический IP в филиале. Конечно, такое может случиться только в очень неудачной компании и надеюсь вам в этом смысле повезло больше.

Стоит отметить, если вы сочтёте, что поставить во всех филиалах ClearOS всё же проще, чем подружить IPSEC от ClearOS c каким-нибудь D-Link'ом, то и здесь ждёт разочарование. По последним данным с форумов, после того как ClarkConnect превратился в ClearOS, у пользователей без подписки возникли проблемы со стабильностью работы IPSEC между двумя ClearOS шлюзами. Падение VPN-канала с интервалом в восемь часов не доставляет удовольствия сетевым администраторам. Возможно подписчикам тоже досталось немного проблем с IPSEC, но нам, админам бедных контор, привыкшим пользоваться ПО нахаляву, об этом ничего не известно.

Что же делать? Поднимать туннель с помощью OpenVPN ? Но и здесь есть засада, в ClearOS через WEB-интерфейс не предусмотрена настройка OpenVPN-клиента. Читать FAQ и с напильником в руках в консоль ? Можно, но в определённом смысле с таким же успехом можно было сразу поставить какой-нибудь Debian, CentOS или вообще FreeBSD и всё настроить «как надо».

Кстати, у вас случаем нет пользователей, которым уже давно настроен удалённый доступ к офисной сети через PPTP ? А если таковые есть, так почему бы не задействовать уже работающую службу для организации межсетевой VPN ? Всё бы ничего, но на этом пути есть одна небольшая сложность - маршрутизация. По умолчанию, при подключении пользователя по PPTP, ClearOS добавляет в таблицу маршрут к удалённому клиенту, но нам то для полноценного сетевого взаимодействия требуется обеспечить маршрутизацию между сетями. Для этого, конечно, совсем без напильника не обойтись, но по сравнению с другими вариантами решения нашей задачи, его размер может быть довольно скромным.

Рассмотрим решение данной задачи на примере объединения двух офисов.

 

В головном офисе установлен ClearOS и настроена локальная сеть 172.16.55.0/24. На ClearOS включен PPTP-сервер с настройками указанными на Рис.1

Если, как в примере, вы раздаёте адреса для клиентов удалённого доступа из той же подсети что и для компьютеров локальной сети, не забудьте определить диапазон адресов для VPN-подключений таким образом, чтобы они не пересекались с диапазоном из которого выдаются адреса DHCP-сервером локальной сети.

 

 1.png

Рис. 1

 

По умолчанию ClearOS предлагает использовать 128-ми разрядный ключ шифрования для PPTP-соединений, при этом следует учесть, что подключение клиентов не поддерживающих MPPE-шифрование будет невозможно. Если необходимо предоставить возможность подключения клиентам не поддерживающих шифрование, потребуется зайти в консоль и в файле /etc/ppp/options.pptpd удалить опцию «require-mppe-128». Важно помнить, что при любом изменении настроек PPTP-сервера через WEB-интерфейс, данная опция будет автоматически добавлена вновь!

В нашем примере дополнительный офис (сеть: 192.168.111.0/24) будет подключён к сети Интернет через ADSL-маршрутизатор Acorp W422G v2.0 с официальной прошивкой, позволяющей использовать встроенного PPTP-клиента в режиме роутера. На Рис. 2 приведены настройки VPN-соединения с головным офисом. Особое внимание следует уделить размеру MTU, неверное или несогласованное с сервером значение данного параметра может привести к потерям пакетов больше некоторого размера, либо снижению пропускной способности VPN-канала. Для PPTP-соединения оптимальным значением MTU будет 1460 байт. Надо отметить, что в используемом модеме, фактический размер MTU будет устанавливаться на 4 байта меньше значения, задаваемого через WEB интерфейс.

На Рис. 3 приведен снимок интерфейса модема с настройками необходимых маршрутов. Если у вас несколько удалённых сетей и требуется обеспечить взаимодействие не только с головным офисом, но и между филиалами, добавьте аналогичным образом маршруты в эти сети, указав в качестве интерфейса PPTP-соединение с головным офисом.

 2.png

Рис. 2

 3.png

Рис. 3

 

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

Для исполнения сценариев при подключении пользователей с помощью PPTP в системе предусмотрен скрипт /etc/ppp/ip-up.local, добавьте в его начало следующий код:

 

if [ -f /etc/ppp/routing/${PEERNAME} ]; then

   cat /etc/ppp/routing/${PEERNAME} | while read ROUTESTRING; do

       /sbin/route add -net $ROUTESTRING dev $1

   done

fi

Теперь, после подключения удалённого пользователя, скрипт ip-up.local будет искать в подкаталоге /etc/ppp/routing текстовый файл, имя которого соответствует имени пользователя и добавлять все содержащиеся в нём маршруты в таблицу маршрутизации, с указанием виртуального pptp-интерфеса текущего подключения. Осталось только создать в /etc/ppp подкаталог routing и разместить в нём текстовые файлы, содержащие списки сетей для соответствующих учётных записей. Создавайте файлы с описанием маршрутов только для аккаунтов под которыми будут подключаться маршрутизаторы удалённых сетей. Для подключения клиентских компьютеров всё остаётся по прежнему.

Маршруты к сетям в файле описания должны указываться в соответствии с приведённым примером:

Файл /etc/ppp/routing/branch1

192.168.111.0/24

192.168.125.0/24

Связь и маршрутизация между сетями установлены, теперь осталось решить две проблемы.

По умолчанию, при подключении PPTP-клиента, ClearOS создаёт соответствующий виртуальный интерфейс с MTU-size = 1500 байт, что при соединении с маршрутизаторами, может вызвать проблемы прохождения пакетов более 1470 байт. Чтобы обойти это, необходимо добавить последней строкой в скрипт /etc/ppp/ip-up.local команду:

ifconfig $1 mtu 1400

Важно обратить внимание, что эта строка обязательно должна следовать после вызова:

/usr/share/system/scripts/firewall-up $1 ,

который изначально присутствует в файле ip-up.local. Дело в том, что вызываемый сценарий firewall-up уже содержит в себе команду, устанавливающую размер MTU=1500 байт, но вносить изменения в данный файл не желательно, так как нельзя исключать, что при установке обновлений дистрибутива скрипт может быть заменён.

Вторая проблема может доставить значительно больше хлопот, хотя обойти её вполне возможно средствами WEB-интерфейса.

Не совсем ясно чем руководствовались разработчики ClearOS, но на всех пользователей, подключающихся к PPTP VPN-серверу распространяются те же правила фильтрации исходящего трафика, что и для пользователей локальной сети, НО, не только по отношению к внешней сети (Интернет), а и к локальной тоже! Таким образом, если вы запретили пользователям локальной сети доступ в Интернет по всем портам, кроме к примеру 110-го (POP3) для получения почты с внешних серверов, то всем подключившимся через VPN пользователям будут доступны подключения только по 110-му порту, в том числе к компьютерам локальной сети. Через WEB-интерфес проблему можно обойти путём добавления IP-адресов или DNS-имён компьютеров локальной сети, с которыми необходимо обеспечить связь из удалённых сетей, в раздел «Destination Domains», как показано на Рис. 4

В случае, если таких адресов окажется много, или возникнут какие-либо другие препятствия для применения данного «костыля», вам вновь придётся отправиться в консоль, но это уже тема для другой статьи.


 4.png

Рис. 4

 

P. S. Справедливости ради стоит отметить, что широко распространённых дешёвых роутеров с вменяемым PPTP-клиентом автору встречалось не больше, чем таковых с OpenVPN-клиентом. В большинстве не предусмотрена возможность отключения NAT на pptp-интерфейсе, или невозможно задать маршруты в другие сети через данный интерфейс. Хорошо, если хотя бы поддерживается шифрование MPPE. Если вас интересует модель подходящего для данной задачи маршрутизатора, обратите внимание на продукцию под торговой маркой «MikroTik» (используется RouterOS), либо устройства в которые возможно установить прошивку «DD-WRT».
 
 

От Администрации: статья подготовлена участником клуба "ClearPRO"Error.

Обсуждение - здесь