Går trafikken virkelig gennem VPN'en? Sådan kontrollerer du det

To fejl ser ens ud fra ikonet i proceslinjen: trafik, der går ind i tunnelen, og trafik, der stille går uden om den. Klienten viser Connected i begge tilfælde, fordi Connected kun betyder, at tunnelinterfacet findes, og at klienten har installeret de ruter, den ville have. Om én pakke fra én applikation brugte de ruter, er et separat spørgsmål, som besvares et andet sted i stakken. Fire målinger afgør det meste — rutesøgningen, det første hop, en optagelse på den fysiske adapter og en observation udefra — og serverens eget sessionsbillede dækker resten.

Begynd med den rute, pakken vil tage

Routingtabellen er beslutningen, så spørg den om én destination i stedet for at læse det hele og gætte. På Linux navngiver ip route get det interface og den kildeadresse, som kernen valgte:

ip route get 203.0.113.10
ip route get 10.20.5.7

På Windows er Find-NetRoute -RemoteIPAddress 203.0.113.10 mere nyttig end route print -4 af samme grund: den rapporterer den rute, der vandt, ikke alle ruter, der findes. Læs alligevel tabellen én gang for dens 0.0.0.0-række. Et /1-par der betyder, at en full-tunnel-klient har omskrevet standardruten: OpenVPNs redirect-gateway def1 installerer 0.0.0.0/1 og 128.0.0.0/1 gennem tunnelen, hvilket slår den eksisterende 0.0.0.0/0 på længste præfiks uden at slette den fysiske standardrute. Derfor kan to standardruter eksistere samtidig, mens alt stadig går ind i tunnelen.

To detaljer får tabellen til at lyve. For det første, se på det præfiks, der matchede, i stedet for antallet af standardruter, fordi en interface-metrik eller et /1-par afgør vinderen. For det andet bevarer en forbindelse, der allerede findes, den vej, den blev etableret med; efter tunnelen er oppe, kan en åben session fortsætte med at bruge den gamle rute, indtil den nulstilles, og derfor ser det ud, som om genopkobling løser et routingproblem. En kørende klient — ps ax | grep openvpn — beviser kun, at processen startede.

Følg ét internt og ét offentligt navn

Rutesøgning viser hensigt; vejen viser levering. Følg et navn, der skal være internt, og et navn, der ikke må være det, mens du er forbundet, og sammenlign det første hop:

traceroute intranet.corp.example
traceroute 1.1.1.1

Samme første hop for begge betyder, at det interne navn aldrig kom ind i tunnelen, og at fejlen ligger over det, normalt et navn, der opløses til en offentlig adresse, eller en rute, der aldrig blev installeret. Hvis intern trafik forlader gennem 10.8.0.1, mens offentlig trafik forlader gennem 192.168.1.1, betyder det, at split tunneling gør præcis det, den blev konfigureret til. Et spor, der når VPN-gatewayen og derefter kun returnerer timeouts, er normalt et returvejs- eller serverfirewallproblem, ikke en manglende videresendelsesrute.

Filtreret ICMP får denne kontrol til at lyve: stjerner på begge spor ligner en død tunnel og er normalt en firewall. Prøv en TCP-port, hvor du kan — traceroute -T -p 443 på Linux — og husk, at sporet intet siger om, hvilken resolver der svarede: et navn kan opløses lokalt og stadig nås gennem tunnelen.

Optag på den fysiske adapter, ikke på tunnelen

Det fysiske link er det eneste sted, der viser, hvad netværket faktisk kan se. Med tunnelen oppe bør en session til kontoret fremstå som krypteret nyttelast adresseret til VPN-serveren, ikke som en forbindelse til 10.20.5.7:

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

Det første filter fanger navneopløsning, der forlader lokalt, hvilket er den mest almindelige lækage og den mest stille — siden indlæses stadig, resolversen har bare set forespørgslen. Det andet fanger almindelig trafik til en intern adresse, som kun burde findes inde i tunnelen. På Windows gør pktmon det samme arbejde uden en driver: pktmon filter add -p 53, derefter pktmon start --capture --pkt-size 128, derefter pktmon stop og pktmon format pktmon.etl -o capture.txt. Disse flag varierer lidt mellem Windows-versioner, så kontroller pktmon filter add /?, før du stoler på syntaksen.

Optag det fysiske interface for at finde lækager; en optagelse på tunnelen indeholder de pakker, du allerede tror er der, og på en server indeholder den ulæselige ydre pakker, hvis kilde er gatewayen. Byte-tællere på et hvilket som helst interface beskriver pakker, ikke programmer; at tilskrive trafik til en proces kræver en monitor, der knytter sockets til processer.

Spørg en ekstern tjeneste, og spørg den igen for hver applikation

Den eneste kontrol, der beviser udgangen, er et svar udefra: en tjeneste, der ekkoer den kildeadresse, den så. Kør den fra en shell, hvor du kan vælge interfacet, og kør den to gange:

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

Forskellige svar giver dig bevis for begge veje og en måde at teste en bestemt applikation: bind den, eller kør den i et netværksnavnerum med én rute, og se, hvilken adresse den fjerne ende registrerer. Identiske svar er den interessante fejl: enten virkede bindingen ikke, eller også omskriver noget mellem værten og den fjerne ende kildeadressen, før den ankommer. På Windows vil curl --interface have adapterens adresse frem for dens navn.

En browser, der rapporterer VPN-adressen, beviser browseren. En mailklient, en pakkehåndtering, en backup-agent eller en anden browserprofil kan hver tage en anden vej, især når en proxyindstilling eller en split-tunnel-rute dækker en af dem. En ændring af adressen er ikke i sig selv bevis for en lækage: en load balancer kan svare anderledes afhængigt af den udgang, den så, så sammenlign den registrerede kildeadresse, ikke siden.

Brug serverens visning til at bekræfte peer'en

Serveren besvarer et andet spørgsmål: om en peer er forbundet, hvor meget den har båret, og om sessionen blev genstartet. En peer, der er oppe på serveren, mens klientens tællere næsten ikke rykker, betyder, at applikationstrafikken ikke går ind i tunnelen, uanset hvad klientens tabel sagde. En peer, der flytter mange data for en bruger, som rapporterer, at intet virker, er en anden undersøgelse.

To fælder ligger her. En maskeret tunnel får hver strøm til at se ud, som om den kommer fra gatewayen, så logfiler og regnskab per klient falder sammen på én adresse. Og en klient behandles som en lokal vært, så et spørgsmål om, hvorvidt nogen kopierer filer gennem VPN'en, besvares af fildelingstrafik på serveren eller af værtsrevision på serveren — at overvåge tunnelen giver endepunkter og volumen, ikke filnavne.

Skeln en designbeslutning fra en lækage

Ikke alt uden for tunnelen er en lækage. Link-local og broadcast-trafik forbliver lokal af design, en printer fundet via multicast fortsætter med at annoncere på LAN'et, og DHCP skal forlade lokalt. En applikation bundet til et bestemt interface omgår rutingtabellen med vilje, og kun en firewallregel, et navnerum eller en politikrute ændrer det.

IPv6 fortjener sin egen linje på tjeklisten. En tunnel, der kun bærer IPv4, efterlader en dual-stack-vært med en anden brugbar vej, og en dual-stack-destination vil foretrække den — også DNS, hvis resolversen kan nås over IPv6. Deaktiver IPv6 på adapteren, eller bekræft, at tunnelen bærer det, før du betragter et IPv4-resultat som komplet.

Når kontrollerne er uenige, navngiver uenigheden normalt fejlen:

En rækkefølge, der virker: gem rutingtabellen før og efter tilslutning, følg ét internt og ét offentligt navn, optag DNS på den fysiske adapter, ekko udgangsadressen fra shellen for den bestemte applikation, og læs derefter serveren for volumen. Hvis de første fire er enige, bærer tunnelen det, du tror, og det resterende problem ligger over den. Hvis to af dem er uenige, er det par, der er uenige, fejlen, ikke ikonet.