Går trafikken eigentleg gjennom VPN-en? Slik stadfestar du det

To feil ser like ut frå ikonet i systemstatusfeltet: trafikk som går inn i tunnelen og trafikk som stille går utanom han. Klienten viser Connected i begge tilfelle, fordi Connected berre betyr at tunnelgrensesnittet finst og at klienten har installert rutene han ville ha. Om ein pakke frå ein applikasjon brukte desse rutene, er eit eige spørsmål som blir svara på ein annan stad i stakken. Fire målingar avgjer det meste — rutesøket, første hopp, eit opptak på den fysiske adapteren og ein observasjon utanfrå — og sesjonsbiletet på serveren dekkjer resten.

Byrja med ruta pakken vil ta

Rutetabellen er avgjerda, så spør han om éin destinasjon i staden for å lese heile og gjette. På Linux namngir ip route get grensesnittet og kjeldeadressa som kjernen valde:

ip route get 203.0.113.10
ip route get 10.20.5.7

På Windows er Find-NetRoute -RemoteIPAddress 203.0.113.10 meir nyttig enn route print -4 av same grunn: han rapporterer ruta som vann, ikkje alle ruter som finst. Les likevel tabellen éin gong på grunn av 0.0.0.0-rada. Eit /1-par der betyr at ein fulltunnelklient har skrive om standardruta: OpenVPN sitt redirect-gateway def1 installerer 0.0.0.0/1 og 128.0.0.0/1 gjennom tunnelen, som slår den eksisterande 0.0.0.0/0 på lengste prefiksmatch utan å slette den fysiske standardruta. Difor kan to standardruter eksistere samstundes medan alt framleis går inn i tunnelen.

To detaljar gjer tabellen løgnaktig. For det første, sjå på prefikset som passa og ikkje talet på standardruter, fordi ein grensesnittmetrikk eller eit /1-par avgjer vinnaren. For det andre held ein samband som allereie finst, vegen han vart etablert med; etter at tunnelen er oppe, kan ein open sesjon halde fram med å bruke den gamle ruta til ho blir nullstilt, og difor ser det ut som om ny tilkopling reparerer eit ruteproblem. Ein klient som køyrer — ps ax | grep openvpn — beviser berre at prosessen starta.

Følg eitt internt og eitt offentleg namn

Rutesøket viser intensjon; vegen viser levering. Følg eit namn som må vere internt og eit namn som ikkje må vere det, medan du er tilkopla, og samanlikn første hopp:

traceroute intranet.corp.example
traceroute 1.1.1.1

Same første hopp for begge betyr at det interne namnet aldri kom inn i tunnelen og at feilen ligg over han, vanlegvis eit namn som blir løyst til ei offentleg adresse eller ei rute som aldri vart installert. Viss intern trafikk går ut via 10.8.0.1 medan offentleg trafikk går ut via 192.168.1.1, gjer delt tunnel nøyaktig det han vart konfigurert til. Eit spor som når VPN-gatewayen og deretter berre returnerer tidsavbrot, er vanlegvis eit returveg- eller serverbrannmurproblem, ikkje ei manglande vidaresendingsrute.

Filtrert ICMP gjer denne kontrollen løgnaktig: stjerner på begge spora ser ut som ein død tunnel og er vanlegvis ein brannmur. Test ein TCP-port der du kan — traceroute -T -p 443 på Linux — og hugs at sporet ikkje seier kva resolver som svara: eit namn kan løysast lokalt og likevel vere tilgjengeleg gjennom tunnelen.

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

Den fysiske sambindinga er det einaste staden som viser kva nettverket faktisk ser. Med tunnelen oppe bør ein sesjon til kontoret framstå som kryptert nyttelast adressert til VPN-serveren, ikkje som ei tilkopling 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 fangar namneoppslag som går ut lokalt, som er den vanlegaste og stillaste lekkasjen — sida blir lasta likevel, resolveren såg berre spørjinga. Det andre fangar vanleg trafikk til ei intern adresse som berre skal finnast inne i tunnelen. På Windows gjer pktmon same jobben utan drivar: pktmon filter add -p 53, deretter pktmon start --capture --pkt-size 128, deretter pktmon stop og pktmon format pktmon.etl -o capture.txt. Desse flagga varierer litt mellom Windows-versjonar, så sjekk pktmon filter add /? før du stolar på syntaksen.

Ta opptak av det fysiske grensesnittet for å finne lekkasjar; eit opptak på tunnelen inneheld pakkane du allereie trur er der, og på ein server inneheld det uleselege ytre pakkar kjelda til er gatewayen. Bytteteljarar på kva grensesnitt som helst skildrar pakkar, ikkje program; å tilskrive trafikk til ein prosess krev ein monitor som koplar sockets til prosessar.

Spør ein ekstern teneste, og spør henne deretter på nytt per applikasjon

Den einaste kontrollen som beviser utgangen, er eit svar utanfrå: ei teneste som ekkoar kjeldeadressa ho såg. Køyr henne frå eit skal, der du kan velje grensesnittet, og køyr henne to gonger:

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

Ulike svar gir deg bevis for begge vegar og ein måte å teste ein bestemt applikasjon på: bind han, eller køyr han i eit nettverksnamnerom med éi rute, og sjå kva adresse den fjerne enden registrerer. Identiske svar er den interessante feilen: anten verka ikkje bindinga, eller så skriv noko mellom verten og den fjerne enden om kjeldeadressa før ho kjem fram. På Windows vil curl --interface ha adressa til adapteren i staden for namnet.

Ein nettlesar som rapporterer VPN-adressa, beviser nettlesaren. Ein e-postklient, ein pakkehandsamar, ein tryggingskopiagent eller ein annan nettlesarprofil kan kvar ta ein annan veg, særleg når ei proxyinnstilling eller ei rute for delt tunnel dekkjer ein av dei. Ei adresseendring er ikkje bevis på lekkasje i seg sjølv: ein lastbalansar kan svare annleis avhengig av utgangen han såg, så samanlikn den registrerte kjeldeadressa, ikkje sida.

Bruk servervisinga til å stadfeste peer-en

Serveren svarar på eit anna spørsmål: om ein peer er tilkopla, kor mykje han har bore og om sesjonen vart starta på nytt. Ein peer som er oppe på serveren medan teljarane til klienten knapt rører seg, betyr at applikasjonstrafikken ikkje går inn i tunnelen, uansett kva klienttabellen sa. Ein peer som flyttar mykje data for ein brukar som melder at ingenting verkar, er ei anna undersøking.

To feller ligg her. Ein maskert tunnel får kvar straum til å sjå ut som han kjem frå gatewayen, så loggar og rekneskap per klient fell saman på éi adresse. Og ein klient blir handsama som ein lokal vert, så spørsmålet om nokon kopierer filer gjennom VPN-en blir svara av fildelingstrafikk på serveren eller av vertsrevisjon på serveren — å overvake tunnelen gir endepunkt og volum, ikkje filnamn.

Skil ei designavgjerd frå ein lekkasje

Ikkje alt utanfor tunnelen er ein lekkasje. Link-lokal og kringkasta trafikk blir verande lokal av design, ein skrivar funnen via multicast held fram med å annonsere seg på LAN-et, og DHCP må gå ut lokalt. Ein applikasjon bunden til eit bestemt grensesnitt omgår rutetabellen med vilje, og berre ein brannmurregel, eit namnerom eller ei policyrute endrar det.

IPv6 fortener si eiga line på sjekklista. Ein tunnel som berre ber IPv4, lèt ein dual-stack-vert få ein annan brukande veg, og ein dual-stack-destinasjon vil føretrekkje han — også DNS, om resolveren er tilgjengeleg over IPv6. Deaktiver IPv6 på adapteren eller stadfest at tunnelen ber det før du reknar eit IPv4-resultat som komplett.

Når kontrollane er usamde, namngir usemja vanlegvis feilen:

Ei rekkjefølgje som verkar: lagre rutetabellen før og etter tilkopling, følg eitt internt og eitt offentleg namn, ta opptak av DNS på den fysiske adapteren, ekko utgangsadressa frå skalet for den bestemte applikasjonen, og les deretter serveren for volum. Viss dei fire første er samde, ber tunnelen det du trur, og det gjenverande problemet ligg over han. Viss to av dei er usamde, er paret som er usamde feilen, ikkje ikonet.