Зелена іконка, та сама публічна IP: який маршрут пропустив VPN

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

Що клієнт насправді встановив

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

Три форми вибіркової маршрутизації

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

Далекий бік має переписати адресу джерела

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

Розв'язання імен іде своїм шляхом

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

resolvectl status | head -20
resolvectl query example.org

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

Чотири спостереження, які все вирішують

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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