IPSEC к Fortigate

То, что вы пока не учитываете, — это то, что стандартный IPsec (тот, который вы используете) работает независимо от маршрутизации, точнее, он поверх маршрутизации, после того как та уже выполнена. В отличие от других типов VPN, IPsec не создает туннельный интерфейс, который можно использовать в качестве шлюза. Ему достаточно, чтобы обычная маршрутизация отправила пакет куда-то, а не в никуда. А потом, после всех операций маршрутизации и файрволла, включая NAT, политики IPsec проверяют пакеты и, если им что-то нравится, "перехватывают" их, шифруют и отправляют через соответствующие туннели IPsec, которые называются security associations.

Так что в вашем случае, когда основная политика IPsec говорит, что всё (dst-address=0.0.0.0/0) должно идти через туннель, конкретный маршрут, который вы добавили для веб-сервера, то есть dst-address=b.b.b.b gateway=WAN, ничего в этом поведении не меняет. Поскольку вы можете открыть веб-страницу сервера через браузер, если вводите IP-адрес, но не можете открыть по домену, я предположу, что проблема связана с работой DNS.

Первым делом попробуйте пропинговать доменное имя сервера, и если пинг не проходит, значит, проблема точно в DNS. Скорее всего, ваши DNS-серверы недоступны через IPsec-туннель, потому что они находятся в другом сегменте вашей локальной сети, а не в 192.168.0.0/24, или Fortigate блокирует DNS-запросы ко всем серверам, кроме тех, которые он разрешил, или же настроенные вами DNS-серверы не принимают запросы с адреса, на который Fortigate делает NAT (если он его делает).

Также возможно, что имя сервера зарегистрировано только в DNS Fortigate, а публичные DNS про него ничего не знают, и Fortigate не перенаправляет DNS-запросы своим серверам.

В общем, опишите ситуацию подробнее, чтобы получить более точный совет. Я понимаю, что молчание — золото, но не тогда, когда нужна поддержка.

Итак, подытожим: когда туннель не работает, ты можешь заходить на веб-страницы по имени и пинговать серверы по имени, кроме того сервера, для которого требовался IPsec, так? Когда туннель работает, ты можешь заходить на веб-страницы и пинговать серверы по IP-адресу, включая тот самый сервер с IPsec, так? Когда туннель работает: можешь ли ты пинговать серверы в интернете по имени (выбери те серверы, которые ты сегодня еще не посещал, чтобы кеш DNS не влиял на результат)? Можешь ли пинговать интересующий тебя сервер по имени? И еще объясни, пожалуйста, uplink. Ты упомянул PPPoE на своем 'Tik и роутер с адресом 192.168.0.1 — значит, у тебя два uplink? Обычно ADSL-роутеры либо работают как роутеры, тогда на 'Tik нельзя запустить pppoe-клиент, либо работают как мосты, и тогда ты запускаешь pppoe, но в таком случае DNS на роутере не работает, потому что он не видит интернет, а pppoe передается тебе.

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

Проблема в том, что «VPN селекторы 0.0.0.0/0-0.0.0.0/0», что по-другому называют ipsec policy у Mikrotik, означают отправку всего трафика через туннель. И если с локальной сетью было просто «отрубиться», то вот отсеять весь трафик, кроме IP веб-сервера (b.b.b.b), уже не так просто. Поэтому сначала попробуй поменять политику с src-address=0.0.0.0/0 dst-address=0.0.0.0/0 на src-address=0.0.0.0/0 dst-address=b.b.b.b/32; если туннель установится — отлично, если нет — придётся заморочиться с более сложными правилами action=none перед этим.

То, что ты сделал, — это не то, что я имел в виду. Политика с action=none должна была остаться без изменений (то есть с dst-address=192.168.0.0/24) на данный момент. Политика с action=encrypt должна иметь dst-address=b.b.b.b вместо dst-address=0.0.0.0/0. В итоге должно быть вот так:

_/ip ipsec policy print  
Flags: T - шаблон, X - отключено, D - динамическое, I - неверное, A - активно, default  
0     ;;; VPN  
src-address=0.0.0.0/0 src-port=any dst-address=192.168.0.0/24 dst-port=any protocol=all action=none  
1  A  ;;; VPN  
src-address=0.0.0.0/0 src-port=any dst-address=b.b.b.b/32 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=My-Public-IP sa-dst-address=a.a.a.a proposal=default ph2-count=1_

Но, как я и говорил — пэр может не принять соединение, потому что он получает информацию о политике, которую мы используем по отношению к нему. Если он принимает соединения только с политикой dst-address=0.0.0.0/0, у нас возникает проблема, которую нужно обойти. С другой стороны, если пэр примет и все заработает, политика с action=none станет лишней, и её можно будет удалить.

Это именно то, чего я и ожидал. Администратор Fortigate считает, что любое устройство в мире должно работать так же, как его Fortigate, поэтому он даже не догадывается, что принуждение людей использовать политику, которая совпадает со всем трафиком, может вызвать проблемы у клиентов. Чтобы обойти это, вам понадобится куча политик с action=none, которые будут соответствовать пакетам, не предназначенным для его сети, так что только те, что пройдут мимо всех этих политик без совпадений, в итоге попадут на политику 0.0.0.0/0->0.0.0.0/0 и дойдут до него. Чтобы упростить, я покажу метод на первых двух байтах IP-адреса. Надеюсь, вы знакомы с преобразованиями между двоичной и десятичной системами, а также с принципом построения IP-маски.

Итак, пусть первые два байта b.b.b.b — 217.125. В двоичном виде это 1101 1001 0111 1101. Нужно идти побитно и создавать все префиксы разной длины от 1 до 32, которые совпадают с этим значением во всех битах, кроме последнего:

1101 1001 0111 1101 0…   … … => 0.0.0.0/1  
10.. …   … … => 128.0.0.0/2  
111. …   … … => 224.0.0.0/3  
1100 …   … … => 192.0.0.0/4  
1101 0…   … … => 208.0.0.0/5  
1101 11..   … … => 220.0.0.0/6  
1101 101.   … … => 218.0.0.0/7  
1101 1000   … … => 216.0.0.0/8  
1101 1001   1… … => 217.128.0.0/9  
1101 1001   00.. … => 217.0.0.0/10  
1101 1001   010. … => 217.64.0.0/11  
1101 1001   0110 … => 217.96.0.0/12  
1101 1001   0111 0… => 217.112.0.0/13  
1101 1001   0111 10.. => 217.120.0.0/14  
1101 1001   0111 111. => 217.126.0.0/15  
1101 1001   0111 1100 => 217.124.0.0/16  

Для реального адреса b.b.b.b нужно вычислить все 32 префикса с несоответствующей подсетью именно так, и использовать каждый из них как dst-address в /ip ipsec policy с action=none, размещённой выше единственной политики с action=encrypt и dst-address=0.0.0.0, которую требует Fortigate. Хорошая новость в том, что если делать именно так, можно удалить ранее добавленную политику с action=none, так как одна из этих заменит её.

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

Так что сделайте следующее — оставьте конфигурацию с двумя политиками, которые были вчера: action=none src-address=0.0.0.0/0 dst-address=192.168.0.0/24 и action=encrypt src-address=0.0.0.0/0 dst-address=0.0.0.0/0, а сверху над action=encrypt добавьте ещё одну с action=none и src-address=ваш.wan.ip.address dst-address=0.0.0.0/0.

Это позволит туннелю успешно установиться, но при этом запретит что-либо отправлять через него, потому что всё, что вы отправляете вне вашей локальной сети, сначала маскируется (src-nat) под ваш публичный WAN-адрес.

Теперь возьмите какой-нибудь публичный IP-адрес, который вы контролируете и уверены, что он никогда не будет подключаться к VPN на Fortigate, например, m.m.m.m, и добавьте следующее правило выше текущего правила action=masquerade или action=src-nat, которое вы используете в /ip firewall nat chain=srcnat:

/ip firewall nat add chain=srcnat action=src-nat dst-address=b.b.b.b to-addresses=m.m.m.m

Таким образом, исходный адрес пакетов, которые вы отправляете на b.b.b.b, будет заменён на m.m.m.m, и вторая политика с action=none их проигнорирует, а политика с action=encrypt их сопоставит и отправит Fortigate.

Не знаю, используются у вас статические или динамические адреса на PPPoE, но по вашему описанию кажется, что они динамические, а это делает настройку довольно нестабильной (как только адреса меняются, связь перестает работать, пока вы не подкорректируете правила под новые адреса). У того, у кого 32 исключающие политики, с этим проблем нет. В любом случае, измените настройки /interface pppoe-client так, чтобы тот, у кого обычный публичный адрес, мог добавлять default gateway, а другой — нет. Тогда, даже если второй интерфейс будет активен, пакеты всегда будут выходить через первый. Публичный адрес первого pppoe (который разрешено назначать шлюзом по умолчанию) должен совпадать с адресом в политике с action=none, а публичный адрес второго pppoe (который не разрешено использовать как шлюз по умолчанию) должен быть в правиле, которое я вам дал. Чтобы проверить, пришлите, пожалуйста, вывод команд /interface pppoe-client export hide-sensitive и /ip firewall nat export, предварительно заменив IP-адреса на свои.