Веб-сервер зникає, коли підключається клієнт VPN

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

Симптом: запити всередину, відповіді назовні через неправильні двері

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

Підтвердьте це, спостерігаючи, куди йде відповідь, а не спостерігаючи, як надходить запит.

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

Два маршрути за замовчуванням і одне рішення про маршрутизацію

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

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

Тунель поводиться правильно весь час. Йому сказали нести маршрут за замовчуванням, і він робить саме це.

Виправте зворотний шлях, не зламавши тунель

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

Вибирайте за тим, що має робити хост, а не за тим, який фрагмент ви знайшли першим.

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

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Коли хост маршрутизує й для LAN за собою

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

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

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