A kalon vërtet trafiku përmes VPN? Si ta verifikoni

Dy dështime duken njësoj nga ikona e tabakasë: trafiku që hyn në tunel dhe trafiku që e anashkalon në heshtje. Klienti tregon Connected në të dyja rastet, sepse Connected do të thotë vetëm se ndërfaqja e tunelit ekziston dhe se klienti ka instaluar rrugët që donte. Nëse një paketë e një aplikacioni i përdori ato rrugë është pyetje më vete, së cilës i përgjigjet diku tjetër në stivë. Katër matje zgjidhin pjesën më të madhe — kërkimi i rrugës, kërcimi i parë, një kapje në përshtatësin fizik dhe një vëzhgim nga jashtë — dhe pamja e sesionit në server mbulon pjesën tjetër.

Filloni me rrugën që do të marrë paketa

Tabela e rrugëtimit është vendimi, prandaj pyeteni për një destinacion të vetëm në vend që ta lexoni të gjithë dhe të hamendësoni. Në Linux, ip route get emërton ndërfaqen dhe adresën burimore që zgjodhi kerneli:

ip route get 203.0.113.10
ip route get 10.20.5.7

Në Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 është më i dobishëm se route print -4 për të njëjtën arsye: raporton rrugën që fitoi, jo të gjitha rrugët që ekzistojnë. Gjithsesi lexoni tabelën një herë për rreshtin 0.0.0.0. Një palë /1 atje do të thotë që një klient i tunelit të plotë ka rishkruar rrugën e paracaktuar: opsioni redirect-gateway def1 i OpenVPN instalon 0.0.0.0/1 dhe 128.0.0.0/1 përmes tunelit, gjë që tejkalon rrugën ekzistuese 0.0.0.0/0 në përputhjen më të gjatë të prefiksit pa fshirë rrugën e paracaktuar fizike. Kjo është arsyeja pse dy rrugë të paracaktuara mund të bashkëjetojnë ndërsa gjithçka vazhdon të hyjë në tunel.

Dy detaje e bëjnë tabelën gënjeshtare. Së pari, shikoni prefiksin që përputhej dhe jo numrin e rrugëve të paracaktuara, sepse metrika e ndërfaqes ose një palë /1 vendosin fituesin. Së dyti, një lidhje që ekziston tashmë mban shtegun me të cilin u krijua; pasi tuneli ngrihet, një sesion i hapur mund të vazhdojë të përdorë rrugën e vjetër derisa të rivendoset, dhe kjo është arsyeja pse rilidhja duket se rregullon një problem rrugëtimi. Një klient në punë — ps ax | grep openvpn — provon vetëm se procesi filloi.

Ndiqni një emër të brendshëm dhe një emër publik

Kërkimi i rrugës tregon qëllimin; shtegu tregon dorëzimin. Ndërsa jeni të lidhur, ndiqni një emër që duhet të jetë i brendshëm dhe një që nuk duhet, dhe krahasoni kërcimin e parë:

traceroute intranet.corp.example
traceroute 1.1.1.1

I njëjti kërcim i parë për të dyja do të thotë që emri i brendshëm nuk hyri kurrë në tunel dhe defekti është sipër tij, zakonisht një emër që zgjidhet në një adresë publike ose një rrugë që nuk u instalua kurrë. Nëse trafiku i brendshëm del përmes 10.8.0.1 ndërsa ai publik del përmes 192.168.1.1, tuneli i ndarë bën pikërisht atë për të cilin u konfigurua. Një gjurmë që arrin portën e VPN dhe pastaj kthen vetëm skadime kohore është zakonisht problem i shtegut të kthimit ose i murit të zjarrit të serverit, jo një rrugë përcjelljeje që mungon.

ICMP i filtruar e bën këtë kontroll gënjeshtar: yjet në të dyja gjurmët duken si tunel i vdekur dhe zakonisht janë mur zjarri. Provoni një port TCP ku mundeni — traceroute -T -p 443 në Linux — dhe mbani mend se gjurma nuk thotë cili zgjidhës u përgjigj: një emër mund të zgjidhet lokalisht dhe gjithsesi të arrihet përmes tunelit.

Kapni në përshtatësin fizik, jo në tunel

Lidhja fizike është vendi i vetëm që tregon çfarë sheh vërtet rrjeta. Me tunelin lart, një sesion drejt zyrës duhet të shfaqet si ngarkesë e kriptuar drejtuar serverit VPN, jo si lidhje drejt 10.20.5.7:

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

Filtri i parë kap zgjidhjen e emrave që del lokalisht, që është rrjedhja më e zakonshme dhe më e heshtur — faqja prapë ngarkohet, zgjidhësi thjesht pa kërkesën. I dyti kap trafik të thjeshtë drejt një adrese të brendshme që duhet të ekzistojë vetëm brenda tunelit. Në Windows, pktmon bën të njëjtën punë pa drejtues: pktmon filter add -p 53, pastaj pktmon start --capture --pkt-size 128, pastaj pktmon stop dhe pktmon format pktmon.etl -o capture.txt. Këto flamuj ndryshojnë pak mes versioneve të Windows, prandaj kontrolloni pktmon filter add /? përpara se t'i besoni sintaksës.

Kapni ndërfaqen fizike për të gjetur rrjedhje; një kapje në tunel përmban paketat që tashmë besoni se janë atje, dhe në një server përmban paketa të jashtme të palexueshme, burimi i të cilave është porta. Numëruesit e bajtëve në çdo ndërfaqe përshkruajnë paketa, jo programe; për t'i atribuar trafikun një procesi nevojitet një monitor që përputh socketa me procese.

Pyetni një shërbim të jashtëm, pastaj pyetni përsëri për çdo aplikacion

Kontrolli i vetëm që provon daljen është një përgjigje nga jashtë: një shërbim që kthen adresën burimore që pa. Ekzekutojeni nga një shell, ku mund të zgjidhni ndërfaqen, dhe ekzekutojeni dy herë:

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

Përgjigje të ndryshme ju japin provën e të dyja shtigjeve dhe një mënyrë për të testuar një aplikacion të caktuar: lidheni atë, ose ekzekutojeni në një hapësirë emrash rrjete me një rrugë të vetme, dhe shikoni cilën adresë regjistron skaji i largët. Përgjigjet identike janë defekti interesant: ose lidhja nuk funksionoi, ose diçka midis hostit dhe skajit të largët rishkruan adresën burimore para se të arrijë. Në Windows, curl --interface kërkon adresën e përshtatësit dhe jo emrin e tij.

Një shfletues që raporton adresën e VPN provon shfletuesin. Një klient poste, një menaxher paketash, një agjent kopjesh rezervë ose një profil i dytë shfletuesi mund të marrë secili një shteg tjetër, sidomos kur një konfigurim proxy ose një rrugë e tunelit të ndarë mbulon një prej tyre. Një ndryshim adrese nuk është provë rrjedhjeje në vetvete: një balancues mund të përgjigjet ndryshe sipas daljes që pa, prandaj krahasoni adresën burimore të regjistruar, jo faqen.

Përdorni pamjen e serverit për të konfirmuar palën

Serveri i përgjigjet një pyetjeje tjetër: nëse një palë është e lidhur, sa ka transportuar dhe nëse sesioni është rinisur. Një palë aktive në server ndërsa numëruesit e klientit mezi lëvizin do të thotë që trafiku i aplikacionit nuk po hyn në tunel, çfarëdo që tha tabela e klientit. Ndërsa një palë që lëviz shumë të dhëna për një përdorues që raporton se asgjë nuk funksionon është një hetim tjetër.

Këtu fshihen dy kurthe. Një tunel i maskuar bën çdo rrjedhë të duket sikur vjen nga porta, prandaj regjistrat dhe kontabiliteti për klient përplasen në një adresë të vetme. Dhe klienti trajtohet si host lokal, prandaj pyetjes nëse dikush kopjon skedarë përmes VPN i përgjigjet trafiku i ndarjes së skedarëve në server ose auditimi i hostit në server — vëzhgimi i tunelit jep skaje dhe vëllim, jo emra skedarësh.

Dalloni një vendim projektimi nga një rrjedhje

Nuk është rrjedhje gjithçka jashtë tunelit. Trafiku lidhës-vendor dhe transmetues mbetet vendore sipas projektimit, një printer i gjetur përmes multicast vazhdon të njoftojë në LAN, dhe DHCP duhet të dalë vendor. Një aplikacion i lidhur me një ndërfaqe të caktuar e anashkalon qëllimisht tabelën e rrugëtimit, dhe vetëm një rregull muri zjarri, një hapësirë emrash ose një rrugë politike e ndryshojnë atë.

IPv6 meriton rreshtin e vet në listën e kontrollit. Një tunel që mbart vetëm IPv4 i lë një hosti me dy stiva një shteg të dytë të përdorshëm, dhe një destinacion me dy stiva do ta preferojë — duke përfshirë DNS, nëse zgjidhësi është i arritshëm përmes IPv6. Çaktivizoni IPv6 në përshtatës ose konfirmoni se tuneli e mbart atë përpara se ta konsideroni të plotë një rezultat IPv4.

Kur kontrollet nuk përputhen, mospërputhja zakonisht emërton defektin:

Një rend që funksionon: ruani tabelën e rrugëtimit para dhe pas lidhjes, ndiqni një emër të brendshëm dhe një publik, kapni DNS në përshtatësin fizik, ktheni adresën e daljes nga shell-i për aplikacionin e caktuar, pastaj lexoni serverin për vëllimin. Nëse katër të parat përputhen, tuneli mbart atë që mendoni dhe problemi i mbetur është sipër tij. Nëse dy prej tyre nuk përputhen, pala që nuk përputhet është defekti, jo ikona.