VPN-клієнти доходять до сервера, але не до LAN: яке рішення?

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

Спочатку визначте, який напрямок зламаний

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

Питання перше: чи можете ви редагувати маршрутизатор віддаленої LAN-мережі?

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

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

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

Питання друге: чи може LAN-мережа перестати бачити адреси клієнтів?

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

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

Ціна — це атрибуція: адреси на клієнта зникають із записів LAN-мережі. Будь-який список дозволених на хості в LAN-мережі тоді має називати сервер замість пулу.

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

Питання третє: чи сервер сам є клієнтом іншого тунелю?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

Потім перевірте обидва напрямки й обидва розміри

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

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

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