Наистина ли трафикът минава през VPN? Как да го проверите

Две повреди изглеждат еднакво от иконата в системния трей: трафик, който влиза в тунела, и трафик, който тихо го заобикаля. Клиентът показва Connected и в двата случая, защото Connected означава само, че интерфейсът на тунела съществува и че клиентът е инсталирал маршрутите, които е искал. Дали един пакет от едно приложение е използвал тези маршрути, е отделен въпрос, на който се отговаря на друго място в стека. Четири измервания решават по-голямата част от него — търсенето в маршрута, първият хоп, прихващането на физическия адаптер и наблюдението отвън — а изгледът на сесията на сървъра покрива останалото.

Започнете с маршрута, по който ще тръгне пакетът

Таблицата за маршрутизация е решението, затова я попитайте за една дестинация, вместо да четете цялата и да гадаете. В Linux ip route get показва интерфейса и адреса на източника, които ядрото е избрало:

ip route get 203.0.113.10
ip route get 10.20.5.7

В Windows Find-NetRoute -RemoteIPAddress 203.0.113.10 е по-полезен от route print -4 по същата причина: той съобщава маршрута, който е спечелил, а не всички съществуващи маршрути. Все пак прочетете таблицата веднъж заради реда 0.0.0.0. Двойка /1 там означава, че клиент на пълен тунел е презаписал маршрута по подразбиране: опцията redirect-gateway def1 на OpenVPN инсталира 0.0.0.0/1 и 128.0.0.0/1 през тунела, което побеждава съществуващия 0.0.0.0/0 при най-дългото съвпадение на префикса, без да изтрива физическия маршрут по подразбиране. Затова два маршрута по подразбиране могат да съществуват едновременно, а всичко пак да влиза в тунела.

Две подробности правят таблицата лъжлива. Първо, гледайте префикса, който е съвпаднал, а не броя на маршрутите по подразбиране, защото победителят се определя от метриката на интерфейса или от двойка /1. Второ, връзка, която вече съществува, запазва пътя, с който е установена; след като тунелът се вдигне, отворена сесия може да продължи да използва стария маршрут, докато не бъде нулирана, и затова пресвързването сякаш оправя проблем с маршрутизацията. Работещият клиент — ps ax | grep openvpn — доказва само, че процесът е стартирал.

Проследете едно вътрешно и едно публично име

Търсенето в маршрута показва намерение; пътят показва доставяне. Докато сте свързани, проследете име, което трябва да е вътрешно, и име, което не бива да е, и сравнете първия хоп:

traceroute intranet.corp.example
traceroute 1.1.1.1

Един и същ първи хоп за двете означава, че вътрешното име никога не е влязло в тунела и повредата е над него — обикновено име, което се разрешава до публичен адрес, или маршрут, който така и не е бил инсталиран. Ако вътрешният трафик излиза през 10.8.0.1, а публичният — през 192.168.1.1, това означава, че разделеният тунел прави точно това, за което е конфигуриран. Път, който стига до VPN шлюза и после връща само изтичания, обикновено е проблем с обратния път или със сървърната защитна стена, а не липсващ маршрут за препращане.

Филтрираният ICMP прави тази проверка лъжлива: звездички и по двата пътя изглеждат като мъртъв тунел и обикновено са защитна стена. Проверете TCP порт, където можете — traceroute -T -p 443 в Linux — и помнете, че проследяването не казва кой резолвер е отговорил: едно име може да се разреши локално и пак да е достъпно през тунела.

Прихващайте на физическия адаптер, не на тунела

Физическата връзка е единственото място, което показва какво мрежата наистина вижда. При вдигнат тунел сесията към офиса трябва да изглежда като криптиран товар, адресиран до VPN сървъра, а не като връзка към 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Първият филтър хваща разрешаването на имена, което излиза локално; това е най-честата и най-тихата теч — страницата все пак се зарежда, просто резолверът е видял заявката. Вторият хваща обикновен трафик към вътрешен адрес, който би трябвало да съществува само вътре в тунела. В Windows pktmon върши същата работа без драйвер: pktmon filter add -p 53, после pktmon start --capture --pkt-size 128, после pktmon stop и pktmon format pktmon.etl -o capture.txt. Тези флагове се различават малко между изданията на Windows, затова проверете pktmon filter add /?, преди да се доверите на синтаксиса.

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

Попитайте външна услуга, после я попитайте отново за всяко приложение

Единствената проверка, която доказва изхода, е отговор отвън: услуга, която връща адреса на източника, който е видяла. Стартирайте я от шел, където можете да изберете интерфейса, и я стартирайте два пъти:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Различните отговори ви дават доказателство за двата пътя и начин да тествате конкретно приложение: вържете го към интерфейс или го стартирайте в мрежово пространство от имена с един маршрут и вижте кой адрес записва далечната страна. Еднаквите отговори са интересната повреда: или връзването не е подействало, или нещо между хоста и далечната страна пренаписва адреса на източника, преди да пристигне. В Windows curl --interface иска адреса на адаптера, а не името му.

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

Използвайте изгледа на сървъра, за да потвърдите партньора

Сървърът отговаря на друг въпрос: дали партньорът е свързан, колко е пренесъл и дали сесията е рестартирала. Партньор, който е активен на сървъра, докато броячите на клиента едва мърдат, означава, че трафикът на приложението не влиза в тунела, каквото и да казва таблицата на клиента. А партньор, който прехвърля много данни за потребител, който твърди, че нищо не работи, е друго разследване.

Тук се крият два капана. Маскиран тунел прави всеки поток да изглежда идващ от шлюза, затова регистрите и отчетността по клиенти се сриват в един адрес. А клиентът се третира като локален хост, затова въпросът дали някой копира файлове през VPN се отговаря от трафика за споделяне на файлове на сървъра или от одита на хоста на сървъра — наблюдението на тунела дава крайни точки и обем, не имена на файлове.

Различавайте проектно решение от теч

Не всичко извън тунела е теч. Трафикът до локалния сегмент и широкомовният трафик остават локални по проект, принтер, открит чрез multicast, продължава да се обявява в LAN, а DHCP трябва да излиза локално. Приложение, вързано към конкретен интерфейс, умишлено заобикаля таблицата за маршрутизация и това се променя само от правило на защитна стена, пространство от имена или политически маршрут.

IPv6 заслужава собствен ред в контролния списък. Тунел, който носи само IPv4, оставя на двустеков хост втори използваем път и двустекова дестинация ще го предпочете — включително за DNS, ако резолверът е достъпен през IPv6. Изключете IPv6 на адаптера или потвърдете, че тунелът го носи, преди да приемете резултат за IPv4 като пълен.

Когато проверките се разминават, разминаването обикновено посочва повредата:

Работещ ред: запазете таблицата за маршрутизация преди и след свързването, проследете едно вътрешно и едно публично име, прихванете DNS на физическия адаптер, върнете адреса на изхода от шела за конкретното приложение, после прочетете сървъра за обем. Ако първите четири съвпадат, тунелът носи това, което смятате, а останалият проблем е над него. Ако две от тях се разминават, двойката, която се разминава, е повредата, не иконата.