Достъп до 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 може да се промени. Път, който работи само до следващата сесия, не е работещ път.