Клієнт OpenVPN досягає сервера, але не вузлів LAN: контрольний список

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

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

Перший крок: спостерігайте за рішенням маршрутизації клієнта

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

ip route get 192.168.50.10

Якщо у відповіді названо ваш фізичний адаптер і офісний шлюз, жодна зміна на боці сервера не допоможе. OpenVPN роздає маршрути лише тоді, коли сервер їх проштовхує, тому шукайте push "route 192.168.50.0 255.255.255.0" у конфігурації сервера і після цього перепідключіть клієнт. Більшість клієнтів застосовують проштовхнуті маршрути під час підключення, а не коли ви перезавантажуєте профіль.

У Windows те саме питання має іншу команду. Find-NetRoute -RemoteIPAddress 192.168.50.10 виводить інтерфейс і наступний перехід, який вибрав би стек, а route print -4 показує, чи існує проштовхнутий префікс узагалі.

Другий крок: переконайтеся, що сервер пересилатиме пакет

Якщо маршрут клієнта правильний, пакет досягає сервера, і сервер має погодитися його пересилати. Перемикач ядра — це перші ворота, і sysctl net.ipv4.ip_forward має повернути 1. Встановлення через echo 1 > /proc/sys/net/ipv4/ip_forward працює до наступного перезавантаження, і саме тому та сама скарга повертається за тижні.

Запишіть це туди, де воно переживе перезавантаження:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Другі ворота — таблиця фільтрів. Вузол з установленим Docker часто має політику FORWARD зі значенням DROP, і тунель успадковує це рішення. iptables -L FORWARD -v -n показує і політику, і лічильники пакетів; якщо політика DROP, пересиланню потрібен явний дозвіл для напрямку з тунелю в LAN і ще один для відповіді.

Третій крок: простежте пакет до LAN і шукайте відповідь

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

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

Четвертий крок: виберіть між трансляцією та зворотним маршрутом

Два виправлення закривають діру, і вибір має наслідки поза тим, чи працює ping. Трансляція джерела робить сервер позірним відправником:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Обмежте правило пулом та інтерфейсом LAN, потім зробіть його постійним, інакше наступне перезавантаження міжмережевого екрана тихо видалить ваше виправлення. Ціна — ідентичність: кожен клієнт виглядає як сервер VPN у журналах LAN і правилах доступу, і per-client policy becomes guesswork.

Статичний маршрут для 10.8.0.0/24 на маршрутизаторі LAN, що вказує на сервер VPN, зберігає адреси клієнтів видимими і є кращою довгостроковою відповіддю, коли цей маршрутизатор ваш. Багато майданчиків якийсь час тримають обидва рішення: NAT для негайного виправлення і маршрут, щойно написано політику міжмережевого екрана. Якщо сервер — це партнер «сайт-сайт», а не пул, боці сервера також потрібен iroute для віддаленої підмережі, інакше маршрут партнера існує, але трафік клієнтів ніколи з ним не пов’язується.

П’ятий крок: перевірте з боку клієнта і запишіть, що змінилося

Замикайте цикл з боку клієнта, а не сервера. Підключіться до реальної служби на вузлі LAN, потім підтвердьте, що лічильники трансляції зрушили за допомогою iptables -t nat -L POSTROUTING -v -n, бо правило без пакетів — це правило, яке ніколи не збігалося. conntrack -L -s 10.8.0.5 показує потік і його стан, коли потрібен доказ, що зворотний напрямок відстежується.

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

Схожі статті