Hva et STUN-svar avslører når VPN-en kjører på ruteren

Når tunnelen bor på ruteren, har maskinen som kjører nettleseren ingen tunnelgrensesnitt i det hele tatt. Spør den maskinen om dens lokale adresser, og du får en privat LAN-adresse og en loopback, ingenting som ligner en VPN-adresse. Likevel kan en STUN-server på den andre siden fortsatt rapportere noe meningsfullt om ruten, og det den rapporterer avhenger fullstendig av hvordan akkurat den forespørselen ble rutet og oversatt.

Det er den delen som er verdt å senke tempoet for. «Nettleseren eier ikke VPN-adressen» svarer på et spørsmål om grensesnitt, mens en reflektert adresse er et svar om en rute gjennom oversettelse. Å blande de to gir selvsikre konklusjoner om avsløring som bevisene ikke støtter.

To enheter, to sett med grensesnitt

I et ruterbasert oppsett avsluttes tunnelen på ruteren, og LAN-klienten sender vanlig trafikk til sin standard gateway. Klientens grensesnittliste forblir kort: én privat adresse, kanskje en til for et annet nettverk, og loopback. Risikoen er ikke at en av dem tilfeldigvis er tunneladressen; den er at forespørselen går ut over en rute du ikke valgte.

Spør klienten hvilken rute en bestemt destinasjon ville ta i stedet for å spørre hvilke grensesnitt som finnes. Svaret navngir en gateway og kildeadressen kjernen ville brukt, og det er allerede mer opplysende enn noen adresseoversikt.

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

Dokumentasjonsområder er gode testmål fordi de aldri løses opp til en ekte tjeneste. Sammenlign hva klienten sier med hva ruteren sier, og behandle enhver uenighet som bevis på at policy-ruting, en splitt-tunnel-regel eller en andre standardrute gjør noe du ikke har tatt høyde for.

Hva et Binding-svar har lov til å si

RFC 8489 definerer Binding-forespørselen og -svaret, der serveren rapporterer kilde-transportadressen den observerte for den forespørselen. Det er en uttalelse om én femling på ett tidspunkt, ikke en folketelling av klientens grensesnitt. Alt interessant skjer derfor mellom klienten og observasjonspunktet.

Det gapet fylles av ruting og oversettelse. En ruter som kilde-NAT-er utgående trafikk, erstatter klientens private kilde med sin egen adresse på det utgående grensesnittet. Er det grensesnittet tunnelen, ser reflektoren tunneladressen. Ble pakken utelukket fra tunnelen, ser reflektoren det WAN-oversettelsen produserte. Samme klient, samme reflektor, annet svar.

Tre tilfeller som ligner hverandre og ikke er det

Den nyttige forskjellen er ikke offentlig kontra privat, men hvilket håndhevingspunkt som behandlet pakken. Gå gjennom tilfellene med ruterens egne tabeller åpne, fordi én nettleser kan produsere alle tre avhengig av en regel du glemte at du skrev.

Bare det andre tilfellet bryter et krav om at viss trafikk aldri går direkte ut, og bare det første og det tredje avslører en identifikator fra tunnelsiden. Ingen av de tre radene er en påstand om en bestemt leverandørs oppførsel: om en privat reflektor i det hele tatt er nåbar, avhenger av ruting, motpartens tillatte IP-adresser og brannmurpolitikken i begge ender.

Å ha en konto hos samme leverandør beviser ingenting av dette. Det er også verdt å huske at en rutet forespørsel kan beholde klientens LAN-kilde hvis ingenting oversetter den, så kildefeltet må spores i stedet for å antas fra topologidiagrammet.

Innsamling er ikke utvalg

WebRTC samler kandidatadresser for å prøve, og en kandidat som dukker opp i en diagnostisk liste, bærer kanskje aldri medier. Å lese listen som «dette er hva motparten lærte» overdriver bevisene. Det valgte paret er det som faktisk bar sesjonen, og det ligger i et annet felt.

En HTTPS-utgangssjekk svarer på enda et spørsmål: kildeadressen en webserver så for den forespørselen. Det er en nyttig kryssjekk nettopp fordi den bruker en annen protokoll og ofte en annen destinasjon enn en UDP-reflektor, og uenighet mellom de to peker vanligvis på en rutingregel snarere enn en feil.

Bestem policyen, les så svaret

Skriv ned hensikten før testing: hvilken trafikk som må bruke tunnelen, hvilken som kan gå direkte ut, hvilke adressefamilier som er i omfang, og hva som skal skje når tunnelen er nede. Uten den grunnlinjen er hver observasjon tvetydig, fordi du ikke kan skille en lekkasje fra en rute du bevisst tillot.

Still så ett spørsmål om gangen. Hvilken rute tar denne destinasjonen. Hvilken adresse rapporterer denne reflektoren. Hvilket kandidatpar valgte sesjonen. Hold svarene ved siden av policyen og datér dem, fordi en fastvareoppdatering kan endre standardoppførsel på måter som stille ugyldiggjør fjorårets konklusjon.

Ruteren er fortsatt et sterkt håndhevingspunkt, fordi den ser trafikk en klient ikke kan omgå uten å omkonfigurere klienten selv. Det er ikke et løfte om at hvert felt i enhver applikasjonsprotokoll ikke avslører noe, og det er ingen erstatning for å skrive ned rutene du valgte å tillate.