Який пакет має зіставляти політика VPN із двома WAN?

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

Назвіть дві розмови

Уявіть віддаленого працівника, під'єднаного до офісного шлюзу, який відкриває HTTPS до внутрішнього сервера застосунків. У лінії дві незалежні розмови, і на кожному кінці вони мають різні адреси. Зовнішня розмова точиться між двома кінцевими точками VPN: від адреси шлюзу до адреси партнера, з тим протоколом і портом, які узгодило розгортання. Внутрішня розмова йде від адреси, виданої клієнтові, до адреси сервера застосунків на порту 443.

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

Знайдіть, де ваша політика справді бачить пакет

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

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

Підтвердьте узгоджений транспорт

Для IPsec, інкапсульованого в UDP, RFC 3948 вміщує ESP усередині UDP і використовує маркер, що не є ESP, щоб IKE залишався розрізнюваним на спільному порту. Звичайний ESP — це протокол IP, а не порт TCP чи UDP, тому правило міжмережевого екрана, написане за номером порту, зовсім його не зіставить. Ця різниця вирішує, чи потрібне вашій політиці WAN правило UDP, правило протоколу або обидва.

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

Перевірте зворотний шлях, перш ніж фіксувати

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

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

Перевірте обидва рівні двома записами

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

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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