UZLEC.ru - Узлец блог

Компании потребовалось организовать VPN между удаленными офисами. Задача на сегодняшний день весьма тривиальная на первый взгляд. Однако существовало ряд "отягощающих обстоятельств": наличие двух отдельных сегментов локальной сети и двух провайдеров в центральном отделении, необходимость коммутируемого удаленного доступа ко всем внутренним ресурсам через публичный Internet.
В качестве основного инструмента для реализации данной задачи была выбрана ОС pfSense v2.2. Что было обусловлено, во-первых, ее бесплатностью, а, во-вторых, наличием у заказчика большого количества старых офисных компьютеров. Любой из них, дооборудованный необходимым количеством сетевых карт и флешь памятью USB, легко превращается с помощью pfSense NanoBSD в многофункциональный маршрутизатор. Простой в несколько часов не является критичным, поэтому в случае выхода из строя старого оборудования, функционирование сети может быть быстро восстановлено путем перестановки флешь памяти USB в другой системный блок.
Рассмотрим схему организации сети.

gw.omb.lan – это маршрутизатор центрального офиса, к нему подключено две локальных сети: 192.168.80.0/24 и 192.168.90.0/24 Имеется подключение к Internet через двух разных провайдеров: PTL ISP1 и BL ISP2. gw.wh.omb.lan и gw.wh.mk.lan – это два удаленных офиса. Их конфигурация достаточно проста: по одной локальной сети и по одному подключению к провайдеру PTL ISP1. Необходимо обеспечить прозрачное хождение трафика между всеми сегментами локальных сетей организации. Поскольку все офисы стыкуются с PTL ISP1, то именно он обеспечивает минимальную задержку в прохождении трафика, поэтому развертывать VPN будем внутри его сети. А BL ISP2 в центральном офисе будет использоваться преимущественно для доступа пользователей к публичному Internet. Однако, если стык с PTL ISP1 у gw.omb.lan откажет, то VPN должен автоматически переключиться на функционирование через BL ISP2.

Для реализации этой схемы предполагается настроить по паре виртуальных каналов IPSec VPN между gw.omb.lan и каждым удаленным офисом, а переключением между ними организовать с помощью протокола динамической маршрутизации OSPF.
Удаленный доступ отдельных пользователей к ресурсам локальной сети через публичный Intrenet будет обеспечен с помощью сервера OpenVPN на gw.omb.lan.
Хочу сразу оговориться, что данная заметка не представляет собой подробное пошаговое руководство. Скорее это будет набор снимков экрана настроек pfSense с моими пояснениями. Поэтому изложенный материал потребует от читателя некоторых базовых знаний в области маршрутизации и фильтрации трафика TCP/IP, функционировании IPSec и OSPF.
Вопросы с базовым конфигурированием pfSense я пропускаю. Начнем сразу с Multi-WAN на gw.omb.lan Напомню, что основным провайдером для доступа к Internet в центральном офисе является BL ISP2, а если он дал сбой, переключаемся на PTL ISP1.

Организуем мониторинг доступности каждого из каналов подключения к Internet. В качестве сенсоров я использовал адреса IP хоста "ya.ru".

Создадим группу шлюзов по умолчанию, в которой BL ISP2 будет являться основным каналом (Tier 1), а PTL ISP1 – резервным (Tier 2).

Созданную группу шлюзов назначим обеим локальным сетям gw.omb.lan

На всех роутерах выключаем автоматическое генерирование правил NAT. Настраиваем его вручную.

На gw.wh.omb.lan и gw.wh.mk.lan Multi-WAN отсутствует, переходим к настройке IPSec. Обычно это делают в режиме туннеля, однако он не поддерживает multicast, который необходим для функционирования OSPF. Поэтому IPSec будет настроен в транспортном режиме, а туннели организованы с помощью GRE.

Настройки IPSec на gw.omb.lan для gw.wh.omb.lan:

Настройки IPSec на gw.omb.lan для gw.wh.mk.lan:

Обратите внимание, что IPSec на gw.omb.lan привязываются к интерфейсам LAN, для авторизации используется имя, а не адрес IP. Такая настройка обусловлена тем, что иначе в локальную таблицу добавляется статичный маршрут через один из интерфейсов WAN к gw.wh.omb.lan и gw.wh.mk.lan, а в конфигурации Multi-WAN это полностью нарушает работу резервных каналов IPSec, они не инициализируются. Использование интерфейсов LAN для IPSec потребует соответствующей настройки NAT и брандмауэра. Но об этом немного позже.
Также необходимо учесть, что при попытке добавить еще один канал IPSec с тем же Remote Gateway, что был использован уже ранее, будет выдано сообщение об ошибке. Для решения этой проблемы просто временно отключите IPSec с уже задействованным Remote Gateway, а после добавления второго IPSec, включите обратно.
Настройки IPSec на gw.wh.omb.lan для gw.omb.lan:

Настройки IPSec на gw.wh.mk.lan для gw.omb.lan: На gw.wh.omb.lan и gw.wh.mk.lan нет Multi-WAN, поэтому настройки тривиальные.
В транспортном режиме IPSec не может туннелировать трафик локальных сетей, эта задача будет возложена на GRE.
Настройки GRE на gw.omb.lan:

GRE на gw.omb.lan из-за Multi-WAN также привязывается к интерфейсам LAN. Размер MTU уменьшается до 1400 байт для предотвращения проблем с фрагментированным трафиком.
Настройки GRE на gw.wh.omb.lan: Настройки GRE на gw.wh.mk.lan:

Во время загрузки системы конфигурирование интерфейсов GRE происходит раньше, чем IPSec VPN. Что приводит к сбою в работе GRE. Для того, что бы устранить эту проблему, достаточно просто передернуть интерфейсы GRE. Автоматизировать эту задачу можно с помощью скрипта "/usr/local/etc/rc.d/ifdownup.sh" следующего содержания:

#!/bin/sh

IFCONFIG=`which ifconfig`
AWK=`which awk`
INTERFACES=`${IFCONFIG} | ${AWK} '{ gsub(/\t/, " "); print }' | cut -c1-8 | sort | uniq -u | ${AWK} -F: '{print $1;}' | grep gre`

for if in ${INTERFACES};
do

${IFCONFIG} ${if} down
${IFCONFIG} ${if} up

done

exit 0

Маршрутизацию трафика внутри VPN будет обеспечивать OSPF. Его поддержку в pfSense реализует пакет "Quagga OSPF", который необходимо установить дополнительно.
Рассмотрим настройки OSPF на gw.omb.lan:

Обратите внимание на настройки, которые обеспечивают анонсирование статичного маршрута Quagga к сети 192.168.0.0/16 Он необходим для обеспечения маршрутизации к клиентам сервера OpenVPN, о котором речь пойдет далее. А также на изменение стандартной метрики у интерфейсов GRE. Использование разных значений для основных и резервных каналов IPSec VPN гарантирует переключение между ними. Интерфейсы LAN и OpenVPN объявлены пассивными.
Настройки OSPF на gw.wh.omb.lan: Настройки OSPF на gw.wh.mk.lan:

Сервер OpenVPN на gw.omb.lan настроен достаточно традиционно, но опять же с некоторыми поправками на Multi-WAN:

Обратите внимание, что сервер OpenVPN привязан к интерфейсу локальной петли localhost. Как Вы уже могли догадаться по аналогии с IPSec VPN, обусловлено это Multi-WAN, поэтому также потребует соответствующей настройки NAT и брандмауэра.
Я вручную добавляю несколько дополнительных опций в файл настроек сервера OpenVPN:

push "ip-win32 dynamic 0 3600"
push "comp-lzo adaptive"
push "ping 10"
push "ping-exit 60"
push "explicit-exit-notify 3"
mssfix 1450
tun-mtu 1500
fragment 1300

Рекомендую установить в систему дополнительный пакет "OpenVPN Client Export Utility", который позволяет генерировать комплексный файл настроек для клиентов OpenVPN. Он сразу содержит в себе и все необходимые опции, и сертификаты:

К файлам настроек клиентов OpenVPN также добавляется несколько дополнительных опций:

remote-random
comp-lzo adaptive
ping 10
ping-exit 60
mssfix 1450
tun-mtu 1500
fragment 1300
explicit-exit-notify 3

Как уже неоднократно указывалось ранее в конфигурации Multi-WAN сервисы IPSec VPN, GRE и OpenVPN пришлось привязать к внутренним интерфейсам, а не WAN. Это требует дополнительных настроек брандмауэра и NAT:

В данном случае мы пробрасываем ряд протоколов и портов. Поскольку на gw.wh.omb.lan и gw.wh.mk.lan нет Multi-WAN, там мы привязываем сервисы напрямую к интерфейсу WAN, необходимости в дополнительных ухищрениях нет.
Также необходимо побеспокоиться, что бы соответствующий трафик не отбрасывался брандмауэром. Сначала для удобства я создал псевдоним "VPNnets", в котором указал все сети и адреса IP, имеющие отношение к функционированию IPSec VPN в том числе WAN. Он несколько упростит написание правил. Вот как они выглядят на gw.omb.lan:

Для того, что бы избежать проблем в хождении трафика TCP внутри локальных сетей и VPN необходимо отключить механизм контроля за сессиями TCP в брандмауэре PF. Рассмотрим соответствующее правило:

Это правило необходимо привязать ко всем интерфейсам, за исключением WAN.
На всех интерфейсах VPN и GRE следует разрешить сквозной транзит трафика локальных сетей:

Брандмауэр на gw.wh.omb.lan:

Брандмауэр на gw.wh.mk.lan:

Это все нюансы, на которые следует обратить внимание при реализации схемы, аналогичной моей. Многие типовые вопросы, например ограничение скорости доступа к Internet из локальных сетей, я намеренно оставил за бортом. Поскольку о том, как их настраивать в pfSense, написано много. Делается однотипно. Мне к этому добавить нечего.

Поделиться ссылкой: