Ide li promet zaista kroz VPN? Kako to provjeriti

Dva kvara izgledaju isto sa ikone u sistemskoj traci: promet koji ulazi u tunel i promet koji ga tiho zaobilazi. Klijent u oba slučaja prikazuje Connected, jer Connected znači samo da interfejs tunela postoji i da je klijent instalirao rute koje je htio. Da li je jedan paket jedne aplikacije koristio te rute, zasebno je pitanje na koje se odgovara na drugom mjestu u steku. Četiri mjerenja rješavaju većinu toga — pretraga rute, prvi skok, snimanje na fizičkom adapteru i posmatranje izvana — a prikaz sesije na serveru pokriva ostalo.

Počnite od rute kojom će paket krenuti

Tablica rutiranja je odluka, pa je pitajte o jednom odredištu umjesto da čitate cijelu i nagađate. Na Linuxu ip route get imenuje interfejs i izvornu adresu koje je jezgro odabralo:

ip route get 203.0.113.10
ip route get 10.20.5.7

Na Windowsu je Find-NetRoute -RemoteIPAddress 203.0.113.10 korisniji od route print -4 iz istog razloga: prijavljuje rutu koja je pobijedila, a ne sve rute koje postoje. Ipak pročitajte tablicu jednom zbog njenog reda 0.0.0.0. Par /1 tamo znači da je klijent punog tunela prepisao zadanu rutu: OpenVPN-ova opcija redirect-gateway def1 instalira 0.0.0.0/1 i 128.0.0.0/1 kroz tunel, što pobeđuje postojeću 0.0.0.0/0 po najdužem podudaranju prefiksa bez brisanja fizičke zadane rute. Zato dvije zadane rute mogu koegzistirati dok sve ipak ulazi u tunel.

Dva detalja čine tablicu lažljivom. Prvo, gledajte prefiks koji se podudario, a ne broj zadanih ruta, jer pobjednika odlučuje metrika interfejsa ili par /1. Drugo, veza koja već postoji zadržava put kojim je uspostavljena; nakon što se tunel podigne, otvorena sesija može nastaviti koristiti staru rutu dok se ne resetuje, i zato se čini da ponovno povezivanje popravlja problem s rutiranjem. Klijent koji radi — ps ax | grep openvpn — dokazuje samo da je proces pokrenut.

Pratite jedno interno i jedno javno ime

Pretraga rute pokazuje namjeru; put pokazuje dostavu. Dok ste povezani, pratite ime koje mora biti interno i ime koje ne smije biti, pa uporedite prvi skok:

traceroute intranet.corp.example
traceroute 1.1.1.1

Isti prvi skok za oba znači da interno ime nikada nije ušlo u tunel i da je kvar iznad njega, obično ime koje se razrješava na javnu adresu ili ruta koja nikada nije instalirana. Ako interni promet izlazi kroz 10.8.0.1, a javni kroz 192.168.1.1, to znači da podijeljeni tunel radi tačno ono za što je konfigurisan. Put koji stigne do VPN gejtveja i zatim vraća samo isteke obično je problem povratnog puta ili serverskog firewalla, a ne nedostajuća ruta prosljeđivanja.

Filtrirani ICMP čini ovu provjeru lažljivom: zvjezdice na oba puta izgledaju kao mrtav tunel i obično su firewall. Testirajte TCP port gdje možete — traceroute -T -p 443 na Linuxu — i zapamtite da praćenje ne govori koji je resolver odgovorio: ime se može razriješiti lokalno i ipak biti dostupno kroz tunel.

Snimajte na fizičkom adapteru, ne na tunelu

Fizička veza je jedino mjesto koje pokazuje šta mreža zaista vidi. Sa podignutim tunelom, sesija prema kancelariji treba da se pojavi kao šifrovani teret adresiran na VPN server, a ne kao veza prema 10.20.5.7:

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

Prvi filter hvata razrješavanje imena koje izlazi lokalno, što je najčešći i najtiši curenje — stranica se ipak učitava, resolver je samo vidio upit. Drugi hvata običan promet prema internoj adresi koja bi trebalo da postoji samo unutar tunela. Na Windowsu pktmon radi isti posao bez drajvera: pktmon filter add -p 53, zatim pktmon start --capture --pkt-size 128, zatim pktmon stop i pktmon format pktmon.etl -o capture.txt. Ti se flagovi malo razlikuju između verzija Windowsa, pa provjerite pktmon filter add /? prije nego što povjerujete sintaksi.

Snimajte fizički interfejs da nađete curenja; snimak na tunelu sadrži pakete za koje već vjerujete da su tamo, a na serveru sadrži nečitljive vanjske pakete čiji je izvor gejtvej. Brojači bajtova na bilo kojem interfejsu opisuju pakete, ne programe; da biste promet pripisali procesu, potreban je monitor koji povezuje sokete s procesima.

Pitajte vanjsku uslugu, pa je pitajte ponovo za svaku aplikaciju

Jedina provjera koja dokazuje izlaz je odgovor izvana: usluga koja vraća izvornu adresu koju je vidjela. Pokrenite je iz školjke, gdje možete odabrati interfejs, i pokrenite je dvaput:

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

Različiti odgovori daju vam dokaz oba puta i način da testirate konkretnu aplikaciju: vežite je za interfejs ili je pokrenite u mrežnom imenskom prostoru s jednom rutom, pa vidite koju adresu daleki kraj bilježi. Identični odgovori su zanimljiv kvar: ili vezivanje nije djelovalo, ili nešto između hosta i dalekog kraja prepisuje izvornu adresu prije nego što stigne. Na Windowsu curl --interface traži adresu adaptera, a ne njegovo ime.

Preglednik koji prijavi VPN adresu dokazuje preglednik. Poštanski klijent, menadžer paketa, agent za sigurnosne kopije ili drugi profil preglednika mogu svaki krenuti drugim putem, naročito kad postavka proxyja ili ruta podijeljenog tunela pokriva jedan od njih. Promjena adrese sama po sebi nije dokaz curenja: balanser opterećenja može odgovoriti drugačije zavisno od izlaza koji je vidio, pa uporedite zabilježenu izvornu adresu, a ne stranicu.

Upotrijebite prikaz servera da potvrdite peer

Server odgovara na drugo pitanje: da li je peer povezan, koliko je prenio i da li se sesija ponovo pokrenula. Peer koji je aktivan na serveru dok se brojači klijenta jedva pomjeraju znači da promet aplikacije ne ulazi u tunel, šta god tablica klijenta rekla. A peer koji prenosi mnogo podataka za korisnika koji tvrdi da ništa ne radi je druga istraga.

Tu vrebaju dvije zamke. Maskirani tunel čini da svaki tok izgleda kao da dolazi s gejtveja, pa se logovi i obračun po klijentu slijevaju u jednu adresu. A klijent se tretira kao lokalni host, pa se na pitanje kopira li neko datoteke kroz VPN odgovara prometom dijeljenja datoteka na serveru ili revizijom hosta na serveru — gledanje tunela daje krajnje tačke i obim, ne imena datoteka.

Razlikujte dizajnersku odluku od curenja

Nije sve izvan tunela curenje. Promet link-local i broadcast ostaje lokalni po dizajnu, printer pronađen preko multicast-a nastavlja se oglašavati na LAN-u, a DHCP mora izaći lokalno. Aplikacija vezana za određeni interfejs namjerno zaobilazi tablicu rutiranja i to mijenja samo pravilo firewall-a, imenski prostor ili politička ruta.

IPv6 zaslužuje svoj red u kontrolnoj listi. Tunel koji nosi samo IPv4 ostavlja dual-stack hostu drugi upotrebljiv put, a dual-stack odredište će ga preferirati — uključujući DNS, ako je resolver dostupan preko IPv6. Onemogućite IPv6 na adapteru ili potvrdite da ga tunel nosi prije nego što IPv4 rezultat smatrate potpunim.

Kad se provjere ne slažu, neslaganje obično imenuje kvar:

Redoslijed koji radi: sačuvajte tablicu rutiranja prije i poslije povezivanja, pratite jedno interno i jedno javno ime, snimite DNS na fizičkom adapteru, vratite adresu izlaza iz školjke za konkretnu aplikaciju, pa pročitajte server radi obima. Ako se prva četiri slažu, tunel nosi ono što mislite i preostali problem je iznad njega. Ako se dva od njih ne slažu, par koji se ne slaže je kvar, a ne ikona.