Хто насправді відповідає на виділеній адресі VPN?

Адреса, що лежить невикористаною в пулі організації, не є слухачем, і додавання її до міжмережевого екрана не створює жодної. Щось має завершувати IKE на цій адресі, і механізм залежить від того, чи володіє шлюз адресою, чи її транслює пристрій вище шляхом. Саме шлях пакета розрізняє ці два випадки, і він же визначає, яка функція платформи вам потрібна, перш ніж хтось відкриє запит на зміну. Спочатку змоделюйте шлях, потім обирайте.

Шлях пакета за адресою

Партнер надсилає IKE на видану йому адресу, через UDP 500 або через UDP 4500, коли задіяне проходження через NAT. Пристрій, що тримає цю адресу на шляху, або приймає дейтаграму локально й відповідає на неї, або передає її далі в інше місце. Це єдині дві можливості, і все інше в цій статті випливає з того, яка з них правильна.

Локальний прийом означає, що на цьому пристрої існує сокет, прив'язаний до цієї адреси. Передача означає, що дейтаграма переписується й надсилається далі до іншої кінцевої точки, яка тоді має сокет. Правило міжмережевого екрана, що дозволяє UDP 500, нічого не каже про те, який із двох випадків відбувається.

Запишіть запис, перш ніж щось чіпати: адресу, з якою зв'язуються партнери, як її доставляє вища мережа, локальний інтерфейс або логічну кінцеву точку, що її приймає, і процес, який відповідає на IKE. Чотири рядки, і кожен можна перевірити. Коли один із них невідомий, ця невідомість і є роботою з проєктування, а не деталлю реалізації, яку вирішать пізніше. Заповнення їх після затвердження запиту на зміну — це шлях, яким правило трансляції потрапляє на неправильний пристрій.

Модель A: адресою володіє шлюз

У першій моделі шлюз сам тримає адресу: або як вторинну адресу на наявному інтерфейсі, або як адресу на виділеному інтерфейсі, або як loopback, який платформа підтримує як кінцеву точку тунелю. Це три різні функції з трьома різними шляхами налаштування, і платформа, що підтримує одну, може не підтримувати інші.

Перш ніж проєктувати навколо цього, переконайтеся, що платформа й випуск підтримують саме таку схему. Маршрутизований блок, додаткова адреса на інтерфейсі та loopback-кінцева точка не є взаємозамінними, а документація одного випуску не обіцяє, що наступний поводитиметься так само.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Слухаючий сокет і є доказом. Якщо до адреси нічого не прив'язано, шлюз не є завершувачем, хоч би що казала таблиця маршрутизації, і перехоплення пакетів покаже дейтаграми, що надходять, але ніщо на них не відповідає.

Не розміщуйте другий інтерфейс у підмережі, яка вже існує деінде в топології, і не припускайте, що платформа це залагодить. Перекривні підмережі інтерфейсів дають неоднозначний вибір джерела, а на багатьох платформах — пряму відмову від налаштування.

Модель B: її транслює пристрій вище шляхом

У другій моделі міжмережевий екран вище шляхом володіє виділеною адресою й передає трафік іншому шлюзу VPN. Це трансляція призначення зі зворотним шляхом, і це цілком припустима схема, поки її так задокументовано.

А от доказом того, що пристрій вище шляхом отримав локальний сокет VPN, це не є. Трансляція передає пакети; вона не робить верхню коробку відповідачем IKE. Якщо правило вище шляхом прибрати або його зворотний шлях порушиться, VPN зупиниться, хоча шлюз здоровий і його власні слухачі цілі.

Запишіть обидві адреси: ту, з якою зв'язуються партнери, і ту, яку шлюз справді бачить. Потім запишіть транспорт і зворотний шлях, бо трансляція, що працює для UDP 500, але не для інкапсульованого ESP, з'єднається й потім не зможе нести трафік, а це заплутаний збій для подальшого налагодження.

Ідентичність — це не зовнішня адреса

IPsec відокремлює кінцеву точку тунелю від трафіку, який він захищає, і архітектура тримає ці рішення в різних місцях. Зміна адреси, з якою зв'язуються партнери, автоматично не змінює, які внутрішні префікси дозволені, які маршрути встановлені й до яких ресурсів може дістатися сеанс.

Автентифікована ідентичність знову окрема. IKEv2 несе корисне навантаження ідентичності й обмін автентифікації, які не мусять збігатися із зовнішньою адресою пакета, і саме тому трансльована схема все ще може автентифікуватися правильно.

Ця незалежність корисна й водночас є пасткою. Два імені DNS, що розв'язуються в одного звичайного слухача, не обирають різні серверні частини VPN, а сертифікат, що називає одну ідентичність, не задовольнить партнера, який очікує іншу. Перш ніж припускати, що це вирішує сама лише адреса, переконайтеся, що саме перевіряє партнер.

Прийміть схему, спостерігаючи за одним з'єднанням

Перевірте, куди насправді доставляється нове авторизоване з'єднання, яка ідентичність відповідає і який приватний потік потім дозволений. Три спостереження, три різні рівні, і успішний публічний запит адреси не перевіряє жодного з них.

Збережіть і негативний випадок: партнера, якого не слід приймати, або внутрішній префікс, який не має бути доступним, перевірені після зміни. Запис, зроблений на початку, — це те, що робить таку перевірку можливою без відтворення схеми з пам'яті.

Сенс усього цього — дати власникові мережі змогу обрати підтримуваний спосіб виділення замість того, щоб покладатися на загальне твердження про те, що кожен міжмережевий екран уміє робити з додатковою адресою. Саме це твердження і є місцем, де такі схеми ламаються, бо воно звучить правдоподібно на кожній платформі й загалом не є істинним на жодній. Запис із чотирьох рядків вирішує це для вашої платформи за десять хвилин.