Дали сообраќајот навистина поминува низ 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 на физичкиот адаптер, вратете ја излезната адреса од школката за одредената апликација, потоа прочитајте го серверот за обем. Ако првите четири се совпаѓаат, тунелот го носи тоа што го мислите и преостанатиот проблем е над него. Ако два од нив не се совпаѓаат, парот што не се совпаѓа е дефектот, а не иконата.