IPSEC Site-To-Site Microsoft-AT

Здесь обсуждаются вопросы связанные с маршрутизаторами, сетевыми экранами, VPN

Модератор: Allied Telesis Russia

IPSEC Site-To-Site Microsoft-AT

Сообщение dmitry_tarakanov » 15 июн 2018, 21:19

Претензия на HOW-TO.
VPN Site-To-Site IPSEC между ISA 2004/ISA 2006/TMG/Windows Server на примере ISA 2006 и маршрутизаторами, поддерживающими IPSEC на примере AT-AR450S.

Суть проблемы.
Windows, начиная с версии Windows Server 2000 поддерживает протокол IPSEC. Но в мире Microsoft чистый IPSEC обычно не используется. В разное время гигант индустрии предлагал иные решения, в основном второго уровня, как то PPTP, потом L2TP, теперь вот к ним добавились SSTP и своя собственная реализация GRE. Уже 18 лет системные администраторы планеты при построении корпоративных сетей на базе Windows с одной стороны и железных маршрутизаторов с другой стороны имеют дилемму. Попытать счастья на совместимость майкрософтовской реализации L2TP/PPTP и реализации L2TP/PPTP производителя маршрутизатора или попытаться настроить стандартный IPSEC. И производители оборудования и Microsoft рекомендуют IPSEC. Но с другой стороны, трудность в траблшутинге обрывов и зависаний IPSEC для системных администраторов Windows, вынуждает их искать иные решения. Причины таковы:
1. невозможность послать и принять ICMP-пакет непосредственно с хоста Windows, терминирующего туннель в сам туннель.
2. Отсутствие keep-alive внутри туннеля или несовместимость этих механизмов между Microsoft и железными маршрутизаторами.
3. Отсутствие штатного механизма разрыва и повторного соединения со стороны Windows IPSEC.
4. Сложность и ненаглядность журналов событий IPSEC стороны Windows
5. Сложность разбора IPSEC-траффика в сетевом сниффере.
Ситуация усложняется тем, что начиная с 2006 года имеются рекомендации Microsoft включать в фильтры для IPSEC кроме приватных адресов на другом конце туннеля, еще и внешние адреса устройства, терминирующего туннель со стороны железного устройства. Рекомендации понятны и сделаны для того, чтобы корректно работало ICMP между внешними адресами хостов на концах туннелей в том случае, если оба конца на основе Windows Server. Мастер настройки туннеля ISA 2006 по-умолчанию предлагает включить этот адрес в фильтрацию. Забегая вперед, эти рекомендации в моем примере сознательно проигнорированы и удалены.

Итак, типичная схема сети:
Example1.jpg

После настройки IPSEC согласно рекомендациям Allied Telesyn с поправкой на то, что в AR450 отсутствует аппаратный 3DES, но есть аппаратный DES имеем:
Код: Выделить всё
add firewall poli="guilan" nat=enhanced int=vlan1 gblin=eth0
add firewall poli="guilan" ru=100 ac=allo int=eth0 prot=udp po=500 ip=178.bbb.bbb.58 gblip=178.bbb.bbb.58 gblp=500
add firewall poli="guilan" ru=1001 ac=non int=eth0 prot=ALL ip=192.168.75.0-192.168.75.255 enc=ips
add firewall poli="guilan" ru=1002 ac=non int=vlan1 prot=ALL ip=192.168.75.0-192.168.75.255 rem=192.168.144.0-192.168.151.255
create ipsec sas=1 key=isakmp prot=esp enc=des hasha=sha
create ipsec bund=1 key=isakmp string="1" expirys=3600
create ipsec pol="isakmp" int=eth0 ac=permit lp=500 rp=500
create ipsec pol="vpn_mo" int=eth0 ac=ipsec key=isakmp bund=1 peer=109.aaa.aaa.60 isa="vpn_mo"
set ipsec pol="vpn_mo" lad=192.168.75.0 lma=255.255.255.0 rad=192.168.144.0 rma=255.255.248.0
set ipsec pol="vpn_mo" usepfsk=TRUE gro=2
create ipsec pol="internet" int=eth0 ac=permit
create isakmp pol="vpn_mo" pe=109.aaa.aaa.60 key=1 expirys=28800 gro=2

Example2.jpg

Это предупреждение и есть та рекомендация, благодаря которой соединение IPSEC Site-To-Site между хостами с Windows будет работать стабильно и ICMP будет доходить хотя бы до внешнего интерфейса другого конца тоннеля. Но с точки зрения например Allied Telesyn этого делать не нужно. Точнее бесполезно. Поэтому придется ждать 28800 секунд до попытки восстановить туннель со стороны Microsoft. И в частном случае, если со стороны AT какой-то хост пытается послать пакет в сторону Windows, то туннель восстановится. А вот если такого хоста нет, то firewall AT попытку восстановления IPSEC со стороны Microsoft просто проигнорирует. Почему? Да потому, что таймаут файерволла пройдет. Выручают следующие команды, открывающие протокол IPSEC на интерфейсе, прикрытом файерволлом и кажущиеся после их введения очевидными:
Код: Выделить всё
add firewall poli="guilan" ru=798 ac=allo int=eth0 prot=51
add firewall poli="guilan" ru=799 ac=allo int=eth0 prot=esp

Тем самым мы достигли результата, IPSEC самовосстанавливается после пропадания соединения с интернетом одного из маршрутизаторов. Не позднее, чем через 8 часов. Но хочется-то бОльшего. Конечно хочется keep alive. И такие средства и в AT и в Microsoft имеются. Попробуем:
Код: Выделить всё
SecOff ro-ramenskoe> ping 192.168.150.30
Request 1 timed-out: No reply from 192.168.150.30
Request 2 timed-out: No reply from 192.168.150.30
Request 3 timed-out: No reply from 192.168.150.30
Request 4 timed-out: No reply from 192.168.150.30

Но если пускать пинг с другого интерфейса, то, о, чудо, пинг идет:
Код: Выделить всё
SecOff ro-ramenskoe> ping 192.168.150.30 sipaddress=192.168.75.254
Echo reply 1 from 192.168.150.30 time delay 2.760 ms
Echo reply 2 from 192.168.150.30 time delay 2.634 ms
Echo reply 3 from 192.168.150.30 time delay 2.738 ms

А вот с Windows такая штука не проходит. Нельзя прото так взять и назначить IP-адрес. Ну и соответственно посылать пинг в другие интерфейсы тоже толку не дает, пинг запутывается в фильтрах IPSEC и никуда не идет. Совсем не идет:
Example3.jpg
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Последний раз редактировалось dmitry_tarakanov 16 июн 2018, 15:24, всего редактировалось 2 раз(а).
dmitry_tarakanov
 
Сообщения: 38
Зарегистрирован: 28 янв 2009, 22:59

Re: IPSEC Site-To-Site Microsoft-AT

Сообщение dmitry_tarakanov » 15 июн 2018, 21:23

Продолжение:
Из всего этого есть следующие выводы:
А) Автоматически проверить живучесть канала с помощью ICMP со стороны AT возможность есть.
Б) Автоматически проверить живучесть канала с помощью ICMP со стороны Microsoft возможности нет.
Хорошо, Золотая рыбка, а вообще какие возможности хоть как-то увидеть AT из Windows есть? Многие системные администраторы заканчивали свои исследования именно на этом этапе:
Example4.jpg

Все форумы забиты FAQ по этому поводу. Что эта ситуация by design. А вот оказывается есть способ.
Если убрать из настройки IP-адресации удаленного сайта внешний IP-адрес AT, противореча рекомендациям Microsoft, то внешний адрес AT мы пингуем:
example5.jpg

Окей. Следующая проблемма, как сделать так, чтобы IPSEC перезапускался. Данный пункт для чистой WINDOWS с одним туннелем можно опустить, так как для формирования туннеля придется сделать статическую политику IPSEC. И соответственно в случае, если требуется перезапустить IPSEC, просто перезапустить службу IPSEC. Но как быть в случае, если туннель не один или в случае, если поверх WINDOWS установлена ISA/TMG и политики IPSEC формируются службой firewall динамически?
Перепробовав несколько вариантов, я остановился на следующем:
1. Создаем на Windows loopback интерфейс. Назначаем ему ip-адрес равный ип-адресу маршрутизатора на другом конце туннеля.
2. Переводим интерфейс в статус disabled
3. Если требуется перезапустить политику и фильтры IPSEC для конкретного туннеля, то на несколько секунд переводим loopback в статус enabled и затем в disabled.


План действий:

1) Подправляем firewall на AT, для того, чтобы в любое время поднимался ipsec со стороны Windows
2) Подправляем фильтры IPSEC на Windows так, чтобы пинговался внешний интерфейс AT со стороны Windows, минуя IPSEC
3) Ставим мониторинг туннеля со стороны AT штатными средствами ping polling.
4) Если туннель не доступен, то перекрываем фаирволлом на AT пинг со стороны Windows.
5) Как только туннель поднимается пинг на AT разрешаем.
6) Ставим мониторинг доступности внешнего интерфейса AT со стороны Windows
7) Как только интерфейс AT становится по ICMP недоступен, перестартуем тот туннель IPSEC, который относится к AT с помощью фейкового loopback-интерфейса.


Реализация:

1) Подправляем firewall
Код: Выделить всё
add firewall poli="guilan" ru=798 ac=allo int=eth0 prot=51
add firewall poli="guilan" ru=799 ac=allo int=eth0 prot=esp


2) Подправляем фильтры IPSEC на Windows так, чтобы пинговался внешний интерфейс AT со стороны Windows, минуя IPSEC:
Example2.jpg
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Последний раз редактировалось dmitry_tarakanov 16 июн 2018, 15:31, всего редактировалось 2 раз(а).
dmitry_tarakanov
 
Сообщения: 38
Зарегистрирован: 28 янв 2009, 22:59

Re: IPSEC Site-To-Site Microsoft-AT

Сообщение dmitry_tarakanov » 15 июн 2018, 21:27

Продолжение2:
3) Ставим мониторинг туннеля со стороны AT штатными средствами ping polling.
Ставим пинг
Код: Выделить всё
SecOff ro-ramenskoe> add ping poll=1 ipaddress=192.168.150.30 sipaddress=192.168.75.254 failcount=10 upcount=2 description=VPN_KEEP_ALIVE_ISA
SecOff ro-ramenskoe>enable ping poll=1

Ставим триггеры на пинг:
Код: Выделить всё
SecOff ro-ramenskoe> enable trigger
SecOff ro-ramenskoe> create trigger=11 module=ping event=devicedown poll=1 name="TR_VPN_DOWN" script=vpn_down.scp
SecOff ro-ramenskoe> create trigger=12 module=ping event=deviceup poll=1 name="TR_VPN_UP" script=vpn_up.scp



4) Если туннель не доступен, то перекрываем фаирволлом на AT пинг со стороны Windows. Так как параметры ICMP в штатном фаирволле AT-AR450S меняются глобально для всех адресов, а мы не хотим перекрывать ICMP со всего мира, воспользуемся механизмом IP-фильтрации:
Код: Выделить всё
add ip fil=22 so=109.aaa.aaa.60 ent=1 ac=exclude prot=icmp
add ip fil=22 so=0.0.0.0 ent=2 ac=include

Но интерфейсу фильтры не присоединяем, пока туннель живой.

Создаем скрипт, который будет запускать триггер при падении VPN
и установим в скрипте фильтр на внешний интерфейс,:
Код: Выделить всё
SecOff ro-ramenskoe> add script=vpn_down.scp text="# VPN_DOWN"
SecOff ro-ramenskoe> add script=vpn_down.scp text="set ip interface=eth0 filter=22"



5) Как только туннель поднимается пинг на AT разрешаем, убирая IP-фильтр с внешнего интерфейса:
Код: Выделить всё
SecOff ro-ramenskoe> add script=vpn_up.scp text="# VPN_UP"
SecOff ro-ramenskoe> add script=vpn_up.scp text="set ip interface=eth0 filter=None"

6) Ставим мониторинг доступности внешнего интерфейса AT со стороны Windows с помощью CMD-ника примерно следующего содержания
Код: Выделить всё
:begin
SET VPN=178.bb.bb.58
ping -n 2 %VPN% | find /i "TTL="
if %ERRORLEVEL%==1 (

echo "%VPN%" not reachable
echo ENABLE fake interface
netsh interface set interface LOOPBACK75 ENABLED

echo pause 15 second
choice /T 15 /C yn /D y

echo DISABLE fake interface
netsh interface set interface LOOPBACK75 DISABLED

)
echo pause 15 second
choice /T 15 /C yn /D y
goto begin

Въедливый читатель тут же мне возразит, мол как же так, у ISA Server имеются штатные средства мониторинга доступности в виде connectivity veryfiers и alert definitions. Средства-то есть, но лично мне не удалось при срабатывании триггера NO_CONNECTION передать далее в батник параметрами, какой именно connectivity feryfier сработал. Также стоит заметить, что если windows применяется без ISA-сервера, то придется-таки писать батник, тестирующий соединение.

7) Как только интерфейс AT становится по ICMP недоступен, перестартуем тот туннель IPSEC, который относится к AT с помощью фейкового loopback-интерфейса:
Для этого установим фейковый интерфейс Microsoft Loopback Adapter. Ставится он в зависимости от версии Windows разными способами, инструкций полон интернет. Далее назначаем IP-адрес:
example7.jpg

Ну и наконец тестируем туннель
Разрываем туннель, имитируя разрыв связи:
Код: Выделить всё
SecOff ro-ramenskoe> disable ipsec
Info (1081003): Operation successful.
SecOff ro-ramenskoe> enable ipsec
Info (1081003): Operation successful.



Ждем:
Код: Выделить всё
SecOff ro-ramenskoe> ping 192.168.150.30 sipaddress=192.168.75.254 number=10 delay=5

Request 1 timed-out: No reply from 192.168.150.30
Request 2 timed-out: No reply from 192.168.150.30
Request 3 timed-out: No reply from 192.168.150.30
Request 4 timed-out: No reply from 192.168.150.30
Request 5 timed-out: No reply from 192.168.150.30
Request 6 timed-out: No reply from 192.168.150.30
Echo reply 7 from 192.168.150.30 time delay 3.199 ms
Echo reply 8 from 192.168.150.30 time delay 3.255 ms
Echo reply 9 from 192.168.150.30 time delay 3.139 ms
Echo reply 10 from 192.168.150.30 time delay 3.592 ms

На усмотрение читателя остается способ вставки батника windows в автозагрузку и борьба с UAC

С уважением к коллегам, dmitry_tarakanov.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
dmitry_tarakanov
 
Сообщения: 38
Зарегистрирован: 28 янв 2009, 22:59


Вернуться в Маршрутизаторы и фаерволы

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4