Hvad et STUN-svar afslører, når VPN’en kører på routeren

Når tunnelen bor på routeren, har maskinen, der kører browseren, slet ingen tunnelgrænseflade. Spørg den maskine om dens lokale adresser, og du får en privat LAN-adresse og en loopback, intet der ligner en VPN-adresse. Alligevel kan en STUN-server på den anden side stadig rapportere noget meningsfuldt om ruten, og hvad den rapporterer, afhænger fuldstændigt af, hvordan netop den anmodning blev rutet og oversat.

Det er den del, der er værd at sætte tempoet ned for. „Browseren ejer ikke VPN-adressen“ besvarer et spørgsmål om grænseflader, mens en reflekteret adresse er et svar om en rute gennem oversættelse. At blande de to sammen giver selvsikre konklusioner om afsløring, som evidensen ikke understøtter.

To enheder, to sæt grænseflader

I en routerbaseret opsætning afsluttes tunnelen på routeren, og LAN-klienten sender almindelig trafik til sin standardgateway. Klientens grænsefladeliste forbliver kort: én privat adresse, måske en anden til et andet netværk, og loopback. Risikoen er ikke, at en af dem tilfældigvis er tunneladressen; den er, at anmodningen forlader gennem en rute, du ikke valgte.

Spørg klienten hvilken rute en bestemt destination ville tage i stedet for at spørge, hvilke grænseflader der findes. Svaret navngiver en gateway og den kildeadresse, kernen ville bruge, og det er allerede mere oplysende end enhver adresseoversigt.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Dokumentationsintervaller er gode testdestinationer, fordi de aldrig opløses til en rigtig tjeneste. Sammenlign, hvad klienten siger, med hvad routeren siger, og behandl enhver uenighed som bevis på, at policy-routing, en split-tunnel-regel eller en anden standardrute gør noget, du ikke har taget højde for.

Hvad et Binding-svar må sige

RFC 8489 definerer Binding-anmodningen og -svaret, hvor serveren rapporterer den kildetransportadresse, den observerede for den anmodning. Det er en udtalelse om én femling på ét tidspunkt, ikke en folketælling over klientens grænseflader. Alt interessant sker derfor mellem klienten og observationspunktet.

Det hul udfyldes af routing og oversættelse. En router, der kilde-NAT’er udgående trafik, erstatter klientens private kilde med sin egen adresse på den udgående grænseflade. Er den grænseflade tunnelen, ser reflektoren tunneladressen. Er pakken udelukket fra tunnelen, ser reflektoren, hvad WAN-oversættelsen frembragte. Samme klient, samme reflektor, forskelligt svar.

Tre tilfælde, der ligner hinanden og ikke er

Den nyttige skelnen er ikke offentlig kontra privat, men hvilket håndhævelsespunkt der behandlede pakken. Gennemgå tilfældene med routerens egne tabeller åbne, fordi én browser kan frembringe alle tre afhængigt af en regel, du glemte, at du havde skrevet.

Kun det andet tilfælde bryder et krav om, at visse trafik aldrig forlader direkte, og kun det første og det tredje afslører en identifikator fra tunnelsiden. Ingen af de tre rækker er en påstand om en bestemt udbyders adfærd: om en privat reflektor overhovedet er nåelig, afhænger af routing, peerens tilladte IP-adresser og firewallpolitik i begge ender.

At have en konto hos den samme udbyder beviser intet af dette. Det er også værd at huske, at en rutet anmodning kan beholde klientens LAN-kilde, hvis intet oversætter den, så kildefeltet skal spores i stedet for at antages ud fra topologidiagrammet.

Indsamling er ikke udvælgelse

WebRTC indsamler kandidatadresser til at prøve, og en kandidat, der optræder på en diagnostisk liste, bærer måske aldrig medier. At læse listen som „det her er, hvad modparten lærte“ overdriver evidensen. Det valgte par er det, der faktisk bar sessionen, og det ligger i et andet felt.

En HTTPS-udgangskontrol besvarer endnu et spørgsmål: den kildeadresse, en webserver så for den anmodning. Det er en nyttig krydskontrol netop fordi den bruger en anden protokol og ofte en anden destination end en UDP-reflektor, og uenighed mellem de to peger normalt på en routingregel snarere end på en fejl.

Beslut politikken, læs så svaret

Skriv hensigten ned før test: hvilken trafik der skal bruge tunnelen, hvilken der må forlade direkte, hvilke adressefamilier der er i spil, og hvad der skal ske, når tunnelen er nede. Uden den baseline er hver observation tvetydig, fordi du ikke kan skelne en læk fra en rute, du bevidst tillod.

Stil så ét spørgsmål ad gangen. Hvilken rute tager denne destination. Hvilken adresse rapporterer denne reflektor. Hvilket kandidatpar valgte sessionen. Gem svarene ved siden af politikken, og datér dem, fordi en firmwareopdatering kan ændre standardadfærd på måder, der stille ugyldiggør sidste års konklusion.

Routeren er stadig et stærkt håndhævelsespunkt, fordi den ser trafik, en klient ikke kan omgå uden at omkonfigurere klienten selv. Det er ikke et løfte om, at hvert felt i enhver applikationsprotokol intet afslører, og det er ingen erstatning for at skrive de ruter ned, du valgte at tillade.