Доступ до клієнта 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 може змінитися. Шлях, що працює лише до наступної сесії, не є робочим шляхом.