Наступний крок у маршруті VPN: чому шлюз має бути доступним локально

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

Цей посібник охоплює звичайний випадок: ноутбук на 192.168.20.0/24, шлюз VPN з адресою LAN 192.168.20.5 і віддалена мережа 10.70.0.0/24 за цим шлюзом. Усі команди нижче припускають, що ви на ноутбуці, якщо не сказано інше.

Дві адреси, один маршрут

Передбачуваний запис — 10.70.0.0/24 via 192.168.20.5. Префікс каже, куди йде пакет; адреса via каже, хто несе його туди. Ядро відмовляється встановлювати маршрут, шлюз якого воно не може досягти через указаний вами інтерфейс, і ця відмова — уся суть: наступний крок, якому для доступності потрібен тунель, не може бути тим наступним кроком, який будує тунель.

Тому перша перевірка — не «чи працює шлюз», а «чи є шлюз на цьому звені». Власна підмережа ноутбука, його запис ARP або сусіда та інтерфейс у маршруті мають збігатися. Адреса, що існує лише всередині 10.70.0.0/24, може бути призначенням другого маршруту, але ніколи — via першого.

До чого наступний крок зобов'язує шлюз

Встановлення маршруту на ноутбуці вирішує лише перше передавання. Далі шлюзу потрібен власний шлях: увімкнене пересилання, тунельний маршрут для 10.70.0.0/24 і будь-яка політика доступу, що визначає, хто може ним користуватися. У Linux це net.ipv4.ip_forward=1 плюс тунельний маршрут; міжмережевому екрану перед ним потрібне правило, що дозволяє пересиланий потік.

Зворотний напрямок — та частина, яку люди забувають. Віддалена сторона повинна мати маршрут назад до 192.168.20.0/24, або проєкт має перетворювати джерело ноутбука на щось, що віддалена сторона знає. Робочий ping зі шлюзу доводить, що шлюз досягає віддаленої мережі; він нічого не каже про те, чи переживуть пакети ноутбука зворотну дорогу.

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

Запитайте ядро, який наступний крок воно вибере, і прочитайте інтерфейс у відповіді:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

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

Не використовуйте onlink, щоб підробити доступність

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

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

Тунелі «точка-точка» — це не Ethernet

Тунельний пристрій не робить ARP і часто не має осмисленої підмережі сусідів. Його маршрути часто виглядають як 10.70.0.0/24 dev tun0, без жодного via, бо партнер — єдина інша кінцева точка. Копіювання via у стилі LAN до цієї таблиці створює маршрут, який ядро може відкинути або, що гірше, такий, що вказує на адресу, на яку партнер ніколи не відповідає.

Тримайте дві моделі в посібнику окремо: маршрут LAN має досяжний шлюз, тунельний маршрут має інтерфейс і партнера. WireGuard, OpenVPN і IPsec показують трохи різні форми, тому записуйте форму, яку ви справді використовували, замість узагальнення з одного хоста.

Додайте, підтвердьте, відкотіть

Уся зміна — три команди й одна перевірка, і її слід записати саме в такому порядку:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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