VPN підключається, але пристрої LAN недоступні: що перевірити

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

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

Шлюз відповідає з власного стека

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

Сторінки адміністрування, доступні через тунель, також належать до першої категорії. Вони свідчать про тунель, а не про мережу за ним.

Прослідкуйте потік до першої межі, яка його відкидає

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

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

Зворотні маршрути та брандмауери хоста відмовляють окремо

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

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

Підтверджуйте кожен крок адресою джерела клієнта

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

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