Чому сервер за VPN-клієнтом відповідає через тунель

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

Відповідь маршрутизується, а не запам'ятовується

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

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

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

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

Три способи зберегти зворотний шлях

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

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

Коли машина маршрутизує і для LAN

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

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

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

Три перевірки, що розділяють причини

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

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

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