Маршрутизатор LAN і клієнт VPN: два пристрої, дві таблиці маршрутів

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

Намалюйте два кроки, перш ніж торкатися маршруту

Візьміть ілюстративну схему: хости LAN на 192.168.50.0/24, звичайний маршрутизатор на 192.168.50.1, виділений клієнт на 192.168.50.15 і віддалена мережа LAN на 10.60.0.0/24, доступна лише через тунель, який тримає цей клієнт. Жоден із двох приватних діапазонів не перекривається з іншим, а тунель має власний план адрес.

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

Крок 1: спрямуйте маршрутизатор на клієнта, а не на тунель

На маршрутизаторі LAN додайте маршрут призначення, наступним кроком якого є адреса LAN клієнта:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Цей запис каже «достав це машині, яка вміє тунелювати». Він нічого не каже про те, як будується тунель, і не замінює власний маршрут клієнта. На керованому маршрутизаторі еквівалент живе на сторінці статичних маршрутів пристрою; на маршрутизаторі Linux він належить конфігурації інтерфейсу, який володіє LAN, а не оболонці, яку ви закриєте.

Перевірте відповідь другої команди. Якщо вона повідомляє клієнта як gateway, а інтерфейс LAN як device, перший крок правильний, і решта роботи — на іншій машині.

Крок 2: дайте клієнту власний маршрут з боку тунелю

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

Подивіться, перш ніж щось додавати:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Відсутність маршруту префікса в усіх таблицях — це знахідка, яку ви шукаєте. Додайте його через власну конфігурацію тунелю, щоб наступне перепідключення встановило його знову; ручна ip route add зникає разом із сеансом і повертає несправність у найневдаліший момент. Наступний крок — це інтерфейс тунелю або адреса, яку VPN призначає як свого партнера, залежно від клієнта, і адреса партнера має братися з поточного профілю, а не зі старої нотатки.

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

Крок 3: дозвольте пересилання і виберіть зворотний шлях

Отримання й пересилання — різні дозволи. net.ipv4.ip_forward=1 на клієнті дозволяє транзит на рівні ядра, і правило брандмауера все одно має дозволити його між інтерфейсом LAN і тунелем. Правило, яке дозволяє доступ до власної сторінки керування клієнта, не дозволить транзит до віддаленої LAN, і цю різницю легко пропустити, коли той самий хост локально відповідає на ping.

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

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

Крок 4: зробіть обидва рішення постійними, потім перевірте реальний шлях

Кожен маршрут має власника, і власник — це конфігурація, яка відтворюється під час завантаження або перепідключення. На маршрутизаторі це може бути запис статичного маршруту; на клієнті це може бути профіль VPN, NetworkManager або systemd-networkd. Перевірте, перепідключивши тунель і перезавантаживши клієнта, потім прочитайте таблицю знову, а не покладайтеся на правку.

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

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