Хорошо, это должно быть легко, но это сводит меня с ума.
Сценарий:
Сайт A (Сан-Франциско) Сайт B (Колумбия)
Оба сайта успешно подключены через IPSec (openswan, debian 8):
SiteA --------------- SiteB
10.2.0.1 <== inet ==> 10.3.0.1
Я могу успешно выполнить эхо-запрос PING 10.3.0.1 с SiteA .... Кроме того, 10 добавочных номеров в подсети 10.3.0.0 подключаются к SiteA. Милая, без проблем.
Однако обратите внимание на 10.3.0.1 НЕ В СПИСКЕ в качестве маршрута в любом месте таблицы маршрутизации ядра SiteA, но если я сделаю эхо-запрос из 10.2.0.1, он будет работать.
ЭТА ПРОБЛЕМА:
Хорошо. Я только что добавил SIP-маршрутизатор 10.11.208.93 в SiteB. SiteA должен иметь номер 10.11.208.94 и должен иметь доступ к 10.11.208.93 через 10.3.0.1. Я успешно добавил этот мост на 10.3.0.1 в SiteB.
Когда я пытаюсь создать статический маршрут к SIP-маршрутизатору через 10.3.0.1 в SiteA, команда маршрута сообщает, что хост недоступен. Но я могу пинговать 10.3.0.1 с SiteA.
ip route add -net 10.11.208.92/30 через 10.3.0.1
SIOADDR: хост недоступен
Вопрос: где / как, черт возьми, strongswan (ipsec) настраивает таблицу маршрутизации Linux для достижения 10.3.0.1 через туннель ??? он не отображается в таблице маршрутизации.
Если я могу пинговать 10.3.0.1, почему я не могу использовать его в качестве маршрута для достижения подсети, находящейся за ним, если у меня уже есть рабочий туннель?
StrongSwan по умолчанию устанавливает маршруты в таблице маршрутизации 220. Вы можете увидеть это с помощью ip route list table 220.
Однако добавление маршрута не приведет к туннелированию вашего трафика. IPsec основан на политике (вы можете увидеть это с помощью ip xfrm policy), поэтому, если у вас есть политика IPsec, разрешающая трафик между, например, 10.2.0.0/16 и 10.3.0.0/16 фактически туннелируется только соответствующий трафик. Это не относится к пакетам, отправленным с 10.11.208.94 по 10.11.208.93. Следовательно, вы должны явно добавить туннель, который покрывает эти IP-адреса.