Går trafikken egentlig gjennom VPN-en? Slik verifiserer du det

To feil ser like ut fra ikonet i systemstatusfeltet: trafikk som går inn i tunnelen og trafikk som stille går utenom den. Klienten viser Connected i begge tilfeller, fordi Connected bare betyr at tunnelgrensesnittet finnes og at klienten har installert rutene den ville ha. Om én pakke fra én applikasjon brukte disse rutene, er et eget spørsmål som besvares et annet sted i stakken. Fire målinger avgjør det meste — rutesøket, første hopp, et opptak på den fysiske adapteren og en observasjon utenfra — og serverens eget sesjonsbilde dekker resten.

Begynn med ruten pakken vil ta

Rutingtabellen er beslutningen, så spør den om én destinasjon i stedet for å lese hele og gjette. På Linux navngir ip route get grensesnittet og kildeadressen som kjernen 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 mer nyttig enn route print -4 av samme grunn: den rapporterer ruten som vant, ikke alle ruter som finnes. Les likevel tabellen én gang på grunn av 0.0.0.0-raden. Et /1-par der betyr at en fulltunnelklient har skrevet om standardruten: OpenVPNs redirect-gateway def1 installerer 0.0.0.0/1 og 128.0.0.0/1 gjennom tunnelen, som slår den eksisterende 0.0.0.0/0 på lengste prefiksmatch uten å slette den fysiske standardruten. Derfor kan to standardruter eksistere samtidig mens alt fortsatt går inn i tunnelen.

To detaljer gjør tabellen løgnaktig. For det første, se på prefikset som samsvarte og ikke antall standardruter, fordi en grensesnittmetrikk eller et /1-par avgjør vinneren. For det andre beholder en forbindelse som allerede finnes, veien den ble etablert med; etter at tunnelen er oppe, kan en åpen sesjon fortsette å bruke den gamle ruten til den nullstilles, og derfor ser det ut som om ny tilkobling reparerer et ruteproblem. En klient som kjører — ps ax | grep openvpn — beviser bare at prosessen startet.

Følg ett internt og ett offentlig navn

Rutesøket viser intensjon; veien viser levering. Følg et navn som må være internt og et navn som ikke må være det, mens du er tilkoblet, og sammenlign første hopp:

traceroute intranet.corp.example
traceroute 1.1.1.1

Samme første hopp for begge betyr at det interne navnet aldri kom inn i tunnelen og at feilen ligger over den, vanligvis et navn som løses til en offentlig adresse eller en rute som aldri ble installert. Hvis intern trafikk går ut via 10.8.0.1 mens offentlig trafikk går ut via 192.168.1.1, gjør delt tunnel nøyaktig det den ble konfigurert til. Et spor som når VPN-gatewayen og deretter bare returnerer tidsavbrudd, er vanligvis et returvei- eller serverbrannmurproblem, ikke en manglende videresendingsrute.

Filtrert ICMP gjør denne kontrollen løgnaktig: stjerner på begge sporene ser ut som en død tunnel og er vanligvis en brannmur. Test en TCP-port der du kan — traceroute -T -p 443 på Linux — og husk at sporet ikke sier hvilken resolver som svarte: et navn kan løses lokalt og likevel være tilgjengelig gjennom tunnelen.

Ta opptak på den fysiske adapteren, ikke på tunnelen

Den fysiske forbindelsen er det eneste stedet som viser hva nettverket faktisk ser. Med tunnelen oppe bør en sesjon til kontoret fremstå som kryptert nyttelast adressert 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 filteret fanger navneoppslag som går ut lokalt, som er den vanligste og stilleste lekkasjen — siden lastes likevel, resolveren så bare spørringen. Det andre fanger vanlig trafikk til en intern adresse som bare skal finnes inne i tunnelen. På Windows gjør pktmon samme jobben uten driver: pktmon filter add -p 53, deretter pktmon start --capture --pkt-size 128, deretter pktmon stop og pktmon format pktmon.etl -o capture.txt. Disse flaggene varierer litt mellom Windows-versjoner, så sjekk pktmon filter add /? før du stoler på syntaksen.

Ta opptak av det fysiske grensesnittet for å finne lekkasjer; et opptak på tunnelen inneholder pakkene du allerede tror er der, og på en server inneholder det uleselige ytre pakker hvis kilde er gatewayen. Byttetellere på et hvilket som helst grensesnitt beskriver pakker, ikke programmer; å tilskrive trafikk til en prosess krever en monitor som kobler sockets til prosesser.

Spør en ekstern tjeneste, og spør den deretter på nytt per applikasjon

Den eneste kontrollen som beviser utgangen, er et svar utenfra: en tjeneste som ekkoer kildeadressen den så. Kjør den fra et skall, der du kan velge grensesnittet, og kjør den to ganger:

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

Ulike svar gir deg bevis for begge veier og en måte å teste en bestemt applikasjon på: bind den, eller kjør den i et nettverksnavnerom med én rute, og se hvilken adresse den fjerne enden registrerer. Identiske svar er den interessante feilen: enten virket ikke bindingen, eller også skriver noe mellom verten og den fjerne enden om kildeadressen før den ankommer. På Windows vil curl --interface ha adressen til adapteren i stedet for navnet.

En nettleser som rapporterer VPN-adressen, beviser nettleseren. En e-postklient, en pakkebehandler, en sikkerhetskopiagent eller en annen nettleserprofil kan hver ta en annen vei, særlig når en proxyinnstilling eller en rute for delt tunnel dekker en av dem. En adresseendring er ikke bevis på lekkasje i seg selv: en lastbalanserer kan svare annerledes avhengig av utgangen den så, så sammenlign den registrerte kildeadressen, ikke siden.

Bruk servervisningen til å bekrefte peer-en

Serveren besvarer et annet spørsmål: om en peer er tilkoblet, hvor mye den har båret og om sesjonen ble startet på nytt. En peer som er oppe på serveren mens klientens tellere knapt beveger seg, betyr at applikasjonstrafikken ikke går inn i tunnelen, uansett hva klienttabellen sa. En peer som flytter mye data for en bruker som melder at ingenting virker, er en annen undersøkelse.

To feller ligger her. En maskert tunnel får hver strøm til å se ut som den kommer fra gatewayen, så logger og regnskap per klient faller sammen på én adresse. Og en klient behandles som en lokal vert, så spørsmålet om noen kopierer filer gjennom VPN-en besvares av fildelingstrafikk på serveren eller av vertsrevisjon på serveren — å overvåke tunnelen gir endepunkter og volum, ikke filnavn.

Skill en designbeslutning fra en lekkasje

Ikke alt utenfor tunnelen er en lekkasje. Link-lokal og kringkastet trafikk forblir lokal av design, en skriver funnet via multicast fortsetter å annonsere seg på LAN-et, og DHCP må gå ut lokalt. En applikasjon bundet til et bestemt grensesnitt omgår rutingtabellen med vilje, og bare en brannmurregel, et navnerom eller en policyrute endrer det.

IPv6 fortjener sin egen linje på sjekklisten. En tunnel som bare bærer IPv4, lar en dual-stack-vert få en annen brukbar vei, og en dual-stack-destinasjon vil foretrekke den — også DNS, hvis resolveren er tilgjengelig over IPv6. Deaktiver IPv6 på adapteren eller bekreft at tunnelen bærer det før du anser et IPv4-resultat som komplett.

Når kontrollene er uenige, navngir uenigheten vanligvis feilen:

En rekkefølge som virker: lagre rutingtabellen før og etter tilkobling, følg ett internt og ett offentlig navn, ta opptak av DNS på den fysiske adapteren, ekko utgangsadressen fra skallet for den bestemte applikasjonen, og les deretter serveren for volum. Hvis de fire første er enige, bærer tunnelen det du tror, og det gjenværende problemet ligger over den. Hvis to av dem er uenige, er paret som er uenige feilen, ikke ikonet.