IPSec GRE VPN с резервированием на базе pfSense

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

pfSensegw.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.

pfSenseДля реализации этой схемы предполагается настроить по паре виртуальных каналов 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.

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

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

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

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

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

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

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

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

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

pfSensepfSensepfSensepfSensepfSensepfSenseВо время загрузки системы конфигурирование интерфейсов 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:

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

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

pfSensepfSenseОбратите внимание, что сервер 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. Он сразу содержит в себе и все необходимые опции, и сертификаты:

pfSenseК файлам настроек клиентов 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:

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

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

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

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

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

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

Похожие публикации
Оставите комментарий ?

16 Комментарии。

  1. Круто!
    Но костыль со скриптом для ГРЕ...
    Есть еще варианты избежать эту проблему?

    • Вся описанная методика – это и есть один большой костыль, использующий недокументированные особенности конкретно ОС pfSense v2.2. Возможно, в свежих версиях описанную проблему с интерфейсами GRE устранили, но вполне вероятно, что в них может не заработать что-то другое. Поэтому предложенное решение со скриптом – это мелочи 😉

  2. Есть похожая конфигурация, две точки, в планах третья, по два провайдера на каждую точку и по два Pfsens'а соответственно для полной отказоустойчивости. Вопрос один - чем обусловлен выбор GRE? Я всё решил с помощью OVPN в итоге, хотя в других местах до этого всегда использовал GRE. Разницы за полтора года не ощутил пока. Вот размышляю, может что-то упустил.

    • Выбор в пользу IPSec обусловлен привычкой: site-to-site традиционно строю на нем, client-to-site – OpenVPN. Теоретически IPSec должен требовать меньше ресурсов при больше производительности, поскольку работает на уровне ядра ОС, а OpenVPN – уровне пользовательских приложений, т.е. у IPSec меньше переключений контекста. Но реального подтверждения этому мне найти не удалось, скорее наоборот: https://openvpn.net/archive/openvpn-users/2007-02/msg00088.html Вам же я рекомендую использовать тот инструмент, который лучше знаете, при условии, что нет никаких претензий к его работе, и без особой на то надобности не городить огород, описанный в данной заметке 🙂

  3. Добрый день!
    Подскажите как организовать pfsense-to-pfsnse два провайдера в каждом. У Вас очень много замазано маркером не могу разобраться.

    • Замазано потому, что иллюстрации брались с реально работающей системы. А ответу на ваш вопрос посвящена вся данная заметка 🙂 Естественно, она требует понимания используемых протоколов и творческой переработки применительно к конкретной конфигурации. Готов проконсультировать и помочь по конкретно непонятным моментам. У меня нет возможности подготовить подробную пошаговую инструкцию, которая не потребует вникания в детали.

  4. Добрый день!
    У меня в каждом PF два WAN, одна локальная сеть 192.168.0ХХ.0/24
    Получается два GRE на каждом PF при такой схеме, а должно быть четыре. Как быть?

    • Посчитать тщательно 🙂 Для упрощения этого процесса можно нарисовать простенькую схему.

  5. Добрый вечер!
    Вопрос косвенно касающийся вашей публикации, а точнее касающийся только части с OSPF. Есть 2 офиса, по 2 провайдера в каждом (основной быстрее, резервный гораздо медленнее). Настроен MultiWAN Поднял 2 OpenVPN PKI туннеля: WAN1_Офис1 - WAN1_Oфис2 и WAN2_Офис1 - WAN2_Oфис2 (Понимаю, что для полной отказоустойчивости надо 4, но пока бы с 2 разобраться).
    OpenVPNы привязал к WAN'ам (имеет ли смысл в моём случае привязывать их к localhost?)
    Работоспособность туннелей протестирована включением их по отдельности.
    В настройках Quagga OSPFd в обоих офисах создал по 2 интерфейса, привязал их к объявленным явно впн интерфейсам (не знаю, обязательно ли это), каждый из интерфейсов ввёл в зону 1.1.1.1 и задал разную метрику (10 на тех интерфейсах, который имеют отношение к каналу на основных провайдерах, 20 на резервных), большие никакие галочки не ставил, настройки не менял. В основных настройках Quagga, задал пароль, RID (Указал IP основного WAN. Не знаю, правильно ли), зону 1.1.1.1, поставил галочку Enables the redistribution of connected networks и в These rules take precedence over any redistribute options specified above добавил подсети OVPN туннелей (10.0.8.0/30 и 10.0.9.0/30). Но при падении основного WAN первый туннель тоже падает, трафик по второму не идёт... Что я сделал не так? Можно с вами ещё как-то связаться для обмена скриншотами/консультаций?
    Заранее спасибо

    • В первую очередь необходимо изучить информацию в разделе Services -> Quagga OSPFd -> Status. Видят ли друг друга оба экземпляра Quagga OSPFd? Обмениваются ли информацией? Также следует обратить внимание на таблицу маршрутизации в Diagnostics-> Routes.
      Я не знаю, поддерживает ли OpenVPN мультикастовый трафик. Он необходим для функционирования OSPF. Именно по этой причине я городил огород с GRE.
      Мой контакты опубликованы тут же блоге: http://uzlec.ru/kompyuternaya-diagnostika-reno-v-orle.html Но бесплатно я готов дать консультации общего характера. Если потребуется разбираться с вашими настройками и проводить диагностику, то такая помощь возможна только на платной основе.

  6. Добрый день!
    Хотел бы узнать по вашим настройкам, предопределены ли параметры в VPN\OpenVPN\Client Specific Overrides\Advanced
    для каждого внешнего пользователя? И если да, то что именно?
    У меня не получается присвоить IP каждому подключению. Хотя у каждого пользователя есть свой сертификат, имя и параметры которых прописаны в Client Specific Overrides.
    Спасибо.

  7. Дьяус

    Добрый день. есть проблема с настройкой GRE и IPsec:

    Есть два роутера Pfsense xxx.xxx.xxx.28 и xxx.xxx.xxx.27, за ними локалки 192.168.110.0/24 и 192.168.111.0/24. Задача поднять между локальными сетями GRE туннель под IPSEC. Туннель готов( 10.0.0.1 - 10.0.0.2)но при включении IPSEC во вкладке Status->IPsec, пакеты пересылаемых файлов не отображаются то есть ощущение, что траффик проходит совершенно не по туннелю . При этом если сделать traceroute между машинами из локальных сетей, то пакеты в траффике IPsec отображаются, но только входящие, пришедшие в ответ. То есть на локальном PFsense отобразятся 3 входящих пакета, а на удаленном 3 исходящих. Все, больше траффика в IPsec не видно, ни от пинга ни от пересылаемых файлов.

    • Удостовериться в том шифруется ли трафик можно с помощью tcpdump на интерфейсе WAN.

      • Дьяус

        Спасибо, но почему не отражается траффик в статусе IPsec? Выглядит это странно.

        • Не знаю. Этот вопрос следует адресовать разработчикам. Никогда не обращал внимания на эти счетчики.

Оставить комментарий


Примечание - Вы можете использовать эти HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>