Доступ к клиенту IKEv2 по назначенному виртуальному IP

Шлюзу нужно начать соединение с ноутбуком, подключённым к нему через IKEv2, используя виртуальный адрес, назначенный этому клиенту. Туннель поднят, клиент достигает всего за шлюзом, но обратное направление по-прежнему не работает. Эта асимметрия нормальна: согласованная политика описывает, какие адреса могут общаться, а не то, какая сторона может инициировать. Три вещи должны совпасть, прежде чем запрос, начатый шлюзом, заработает.

Туннель не исправляет адрес источника

CHILD SA охватывает пару селекторов трафика, по одному на каждую сторону, и разрешает трафик в обоих направлениях этой пары. Она ничего не говорит о том, который из партнёров первым открыл обмен IKE. Шлюз, который изначально слушал туннель, всё ещё может отправить первый пакет приложения, если выбранные источник и назначение попадают в установленные селекторы. Когда запрос уходит не через тот интерфейс, он просто не подходит для туннеля.

Маршрутизация к клиенту необходима и недостаточна. Политика должна допускать источник, который вы действительно использовали.

Читайте установленную политику, а не файл конфигурации

Начните с активной ассоциации и её селекторов, потому что динамическое назначение меняет то, что установлено в ядре.

ipsec statusall
ip xfrm policy

Вывод состояния называет соединение, назначенный виртуальный адрес и селекторы, действующие сейчас для этого партнёра. Дамп политики показывает те же селекторы как состояние ядра, и именно к нему фактически обращается выбор пакетов. Сравните селектор со стороны шлюза с источником, который будет использовать ваше приложение, потому что несовпадение сразу объясняет сбой. Читайте текущий адрес клиента, а не адрес из прошлой сессии, потому что переназначенный VIP делает старую политику недействительной.

Клиент должен слушать там, куда приходит пакет

Даже безупречная политика доходит до закрытого порта, когда служба привязана только к loopback. Слушатель должен быть на назначенном адресе или на локальном адресе с подстановочным знаком.

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

Проверьте новое направление отдельно

Рабочий запрос от клиента к серверу никогда не проходит этот путь. Создайте запрос со шлюза и наблюдайте за обоими концами.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Поиск маршрута отвечает, какой источник и интерфейс использовал бы шлюз, и именно это значение должна допускать политика. Запись должна показать, что запрос уходит внутри ESP, а не как обычный TCP на публичном интерфейсе. На клиенте запишите расшифрованный трафик, чтобы подтвердить приход и ответ службы. Если запрос исчезает без ESP в сети, подозревайте адрес источника раньше межсетевого экрана клиента.

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