Når tunnelen bur på rutaren, har maskina som køyrer nettlesaren ingen tunnelgrensesnitt i det heile. Spør den maskina om dei lokale adressene hennar, og du får ei privat LAN-adresse og ein loopback, ingenting som liknar ei VPN-adresse. Likevel kan ein STUN-server på den andre sida framleis rapportere noko meiningsfullt om ruta, og det han rapporterer avheng heilt av korleis akkurat den førespurnaden vart ruta og omsett.

Det er den delen som er verd å senke tempoet for. «Nettlesaren eig ikkje VPN-adressa» svarar på eit spørsmål om grensesnitt, medan ei reflektert adresse er eit svar om ei rute gjennom omsetjing. Å blande dei to gir sjølvsikre konklusjonar om avdekking som prova ikkje støttar.

To einingar, to sett med grensesnitt

I eit ruterbasert oppsett endar tunnelen på rutaren, og LAN-klienten sender vanleg trafikk til standard gatewayen sin. Grensesnittlista til klienten held seg kort: éi privat adresse, kanskje éi til for eit anna nettverk, og loopback. Risikoen er ikkje at ei av dei tilfeldigvis er tunneladressa; han er at førespurnaden går ut over ei rute du ikkje valde.

Spør klienten kva rute ein bestemd destinasjon ville ta i staden for å spørje kva grensesnitt som finst. Svaret namngir ein gateway og kjeldeadressa kjernen ville bruke, og det er alt meir opplysande enn noka adresseoversikt.

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

Dokumentasjonsområde er gode testmål fordi dei aldri vert løyste opp til ein ekte teneste. Samanlikn kva klienten seier med kva rutaren seier, og handsam all usemje som prov på at policy-ruting, ein splitt-tunnel-regel eller ei andre standardrute gjer noko du ikkje har teke høgd for.

Kva eit Binding-svar har lov til å seie

RFC 8489 definerer Binding-førespurnaden og -svaret, der serveren rapporterer kjelde-transportadressa han observerte for den førespurnaden. Det er ei utsegn om éin femling på eitt tidspunkt, ikkje ei folketeljing av grensesnitta til klienten. Alt interessant skjer difor mellom klienten og observasjonspunktet.

Det gapet vert fylt av ruting og omsetjing. Ein ruter som kjelde-NAT-ar utgåande trafikk, erstattar den private kjelda til klienten med si eiga adresse på det utgåande grensesnittet. Er det grensesnittet tunnelen, ser reflektoren tunneladressa. Vart pakken utelukka frå tunnelen, ser reflektoren det WAN-omsetjinga produserte. Same klient, same reflektor, anna svar.

Tre tilfelle som liknar kvarandre og ikkje er det

Den nyttige skilnaden er ikkje offentleg kontra privat, men kva handhevingpunkt som handsama pakken. Gå gjennom tilfella med tabellane til rutaren opne, fordi éin nettlesar kan produsere alle tre avhengig av ein regel du gløymde at du skreiv.

Where the request leavesWhat rewrites the sourceWhat the reflector reports
Tunnel interface on the routerRouter NAT towards the tunnel addressThe tunnel address as seen on that path
WAN interface, excluded by policyOrdinary WAN translationThe public WAN address
Private reflector reached through the tunnel routeRouter NAT towards the tunnel addressAn internal identifier valid only inside that path

Berre det andre tilfellet bryt eit krav om at viss trafikk aldri går direkte ut, og berre det første og det tredje avdekkjer ein identifikator frå tunnelsida. Ingen av dei tre radene er ei påstand om åtferda til ein bestemd leverandør: om ein privat reflektor i det heile er nåbar, avheng av ruting, av tillatne IP-adresser hjå motparten og av brannmurpolitikken i begge endar.

Å ha ein konto hjå same leverandør provar ingenting av dette. Det er også verd å hugse at ein ruta førespurnad kan halde på LAN-kjelda til klienten om ingenting omset henne, så kjeldefeltet må sporast i staden for å verta antatt frå topologidiagrammet.

Innsamling er ikkje utval

WebRTC samlar kandidatadresser for å prøve, og ein kandidat som dukkar opp i ei diagnostisk liste, ber kanskje aldri medium. Å lese lista som «dette er kva motparten lærde» overdriv prova. Det valde paret er det som faktisk bar sesjonen, og det ligg i eit anna felt.

Ein HTTPS-utgangssjekk svarar på endå eit spørsmål: kjeldeadressa ein nettenar såg for den førespurnaden. Det er ein nyttig kryssjekk nettopp fordi han brukar ein annan protokoll og ofte ein annan destinasjon enn ein UDP-reflektor, og usemje mellom dei to peikar vanlegvis på ein rutingregel snarare enn ein feil.

Avgjer policyen, les så svaret

Skriv ned føremålet før testing: kva trafikk som må bruke tunnelen, kva som kan gå direkte ut, kva adressefamiliar som er i omfang, og kva som skal skje når tunnelen er nede. Utan den grunnlinja er kvar observasjon tvitydig, fordi du ikkje kan skilje ein lekkasje frå ei rute du med vilje tillét.

Still så eitt spørsmål om gongen. Kva rute tek denne destinasjonen. Kva adresse rapporterer denne reflektoren. Kva kandidatpar valde sesjonen. Hald svara ved sida av policyen og datér dei, fordi ein fastvareoppdatering kan endre standardåtferd på måtar som stille gjer fjorårets konklusjon ugyldig.

Rutaren er framleis eit sterkt handhevingpunkt, fordi han ser trafikk ein klient ikkje kan omgå utan å omkonfigurere klienten sjølv. Det er ikkje eit løfte om at kvart felt i kvar applikasjonsprotokoll ikkje avdekkjer noko, og det er inga erstatning for å skrive ned rutene du valde å tillate.

Relaterte artiklar