Що таке тунель VPN і де закінчується захист
Тунель надягає другий конверт на вибрані пакети поверх каналу, який у вас уже був. Простежте один запит і побачите, яку адресу сайт справді фіксує.
Клієнт каже «підключено», замок закритий, а сайт усе одно фіксує адресу вашої квартири. Нічого не зламалося. Тунель не замінює Wi-Fi чи мобільне з’єднання; він надягає другий конверт на вибрані пакети й надсилає цей конверт мережею, яка у вас уже була. Зрозуміти трюк — це здебільшого простежити один запит і помітити, де конверт розкривається, бо майже кожен незрозумілий симптом, від витоку домашньої адреси до застряглого великого завантаження, походить саме від цієї межі.
Два конверти, один фізичний канал
Ноутбук зберігає звичайне з’єднання з маршрутизатором, а маршрутизатор зберігає звичайне з’єднання з провайдером. На цьому шляху нічого не змінюється, коли піднімається тунель. Змінюється те, що вибрані пакети передаються віртуальному інтерфейсу, загортаються в новий пакет з адресою VPN-партнера й надсилаються як звичайний трафік фізичним каналом.
Сторона приймання — пристрій, який розкриває конверт і передає початковий пакет до його призначення. Між двома кінцями спостерігач бачить зовнішній заголовок і нічого про внутрішній, якщо протокол його не шифрує, що роблять більшість споживчих протоколів і чого загальна техніка не вимагає.
Тому віртуальний інтерфейс одночасно реальний і оманливий. Він існує як об’єкт ядра з адресою та максимальною одиницею передавання, і операційна система спрямовує в нього трафік, як у будь-який інший інтерфейс. Це не кабель, і його існування доводить лише те, що компонент встановлено. Чи використовує його ваш браузер, вирішують маршрути, а не те, що інтерфейс піднятий.
Простежте один запит у дорозі
Виберіть призначення й запитайте ядро, який інтерфейс воно використає. Ця єдина команда вирішує більшість суперечок про те, чи робить тунель хоч щось:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0Якщо вивід маршруту називає інтерфейс тунелю, пакет буде загорнуто. Якщо він називає фізичний інтерфейс, цього не станеться, і жоден перезапуск клієнта цього не змінить. Друга команда показує обидва інтерфейси поруч, і саме так ви помічаєте тунель, що піднявся без адреси або з адресою з неправильної родини.
Потім подивіться на перший крок ізсередини конверта й порівняйте його з першим кроком ззовні:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5Усередині тунелю перший крок — це внутрішня адреса партнера, а не ваш маршрутизатор. Запис на інтерфейсі тунелю показує внутрішні пакети, тобто трафік, який застосунок вважає надісланим. Одночасний запис на фізичному інтерфейсі показує зовнішні пакети, і разом вони дають найясніший доказ того, що тунель насправді робить.
Три адреси, і сайт бачить лише одну
Люди постійно їх плутають, і плутанина породжує хибні звіти про витік. Це різні поля в різних заголовках з різним часом життя.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
Число біля віртуального адаптера — це другий рядок. Воно не є адресою, яку фіксує сайт, і видавати його за вашу публічну IP просто неправильно. Адресу, яку бачить сайт, призначає вихід, а в тунелі до приватної мережі публічного виходу може взагалі не бути, бо призначення розташоване всередині організації, а не в інтернеті.
Тунель між майданчиками — той самий механізм з іншими кінцевими точками. Два маршрутизатори загортають трафік між мережами, і на жодному окремому пристрої клієнт не встановлено. Конверт у принципі ідентичний, адміністративна межа — ні.
Де конверт розкривається і що його переживає
Тунель закінчується на своєму партнері. Якщо власне шифрування застосунку сягає далі, воно переживає цю межу, що є звичайним випадком для HTTPS: сеанс браузера закінчується на сайті, тому вихід передає шифротекст, який не може прочитати.
Більше нічого за замовчуванням не переживає. Незашифрований запит читається на виході точно так само, як читався у Wi-Fi кафе, і тунель не додає захисту, якого застосунок ніколи не мав. Так само правила брандмауера й політика пересилання на виході вирішують, що буде далі; успішне рукостискання — це факт про з’єднання з партнером, а не про решту подорожі.
Накладні витрати — інший видимий наслідок. Кожен пакет несе додатковий заголовок, а зовнішній транспорт може додати свій, тому корисне навантаження на пакет зменшується. На шляху з фіксованою максимальною одиницею передавання саме тому тунель може пропустити ping і зупинити велике вивантаження.
Перевірте шлях, який застосунок справді пройшов
Останній крок — підтвердити конкретний застосунок, а не машину загалом. Розв’яжіть призначення, подивіться на маршрут для цієї адреси, а потім спостерігайте за з’єднанням, поки воно відкрите:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'Якщо маршрут називає тунель, але список сокетів показує з’єднання з адресою джерела з фізичного інтерфейсу, застосунок прив’язаний до чогось конкретного, або другий тунель конкурує за маршрут за замовчуванням. Це питання маршрутизації, і на нього можна відповісти з цих трьох виводів, а не з екрана стану клієнта.
Архітектура безпеки RFC 4301 описує версію цього загортання на рівні IP для IPsec, і та сама логіка рівнів застосовна до WireGuard і OpenVPN. Щойно ви можете вказати на внутрішній пакет і зовнішній пакет як на окремі об’єкти, більша частина поведінки тунелю перестає бути загадковою і стає таблицею маршрутизації, яку можна прочитати.