Какво е тунел 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. Щом можете да посочите вътрешния пакет и външния пакет като отделни обекти, повечето поведение на тунела престава да е загадъчно и се превръща в таблица за маршрутизация, която можете да прочетете.