Маршрут VPN чи правило брандмауера: що відкидає пакет?

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

Два рішення, один пакет, два власники

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

Фільтрування окреме. На хості Linux хуки netfilter поділяють трафік за тим, для кого пакет: вихід залишає машину, вхід завершується на ній, пересилання проходить через неї. Шлюзу, який приймає клієнтів VPN і спрямовує їх у LAN, потрібен шлях пересилання, і це саме той ланцюг, який більшість типових конфігурацій залишають порожнім.

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

Прочитайте, що пошук насправді вибрав

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

Фільтрування застосовується на хуку, а не на маршруті

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

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

Надішліть зонд шляхом, який використовує клієнт

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

Помістіть кожну зміну туди, де вона переживе повторне підключення

Маршрут, доданий через ip route add, живе до падіння інтерфейсу. Збережіть його в профілі з'єднання: NetworkManager приймає додаткові маршрути на з'єднанні, а netplan зберігає їх між завантаженнями. Те саме правило стосується винятку брандмауера на боці клієнта, який зникає після наступного перезавантаження правил.

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

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