Kva kildeadresse ser STUN med ein ruter-VPN?
Rute, kildeval og omsetjing avgjer adressa ein reflektor rapporterer. Tre fakta å skrive ned, deretter eitt søk for å stadfeste kva veg som vinn.
Spørsmålet høyrest ut som eitt oppslag og er eigentleg tre avgjerder. Kva rute binding requesten tek, kva kilde kjernen vel for den ruta, og om noko undervegs skriv om den kjelda. Endrar ein éin av dei, endrar adressa ein STUN-tenar rapporterer seg med han. Difor seier påstanden om at VPN-en sit på ruteren nesten ingenting i seg sjølv.
Avgjerda kviler på tre fakta
Fyrst ruta: policyreglar og rutetabellen avgjer om førespurnaden går ut gjennom tunnelen eller gjennom det vanlege WAN-et, og ein utelaten destinasjon tek den andre vegen sjølv medan ein tunnel er oppe. Så kjelda: kjernen vel ei kjelde for den valde ruta, og valet avheng av føretrekt kjelde for ruta og av kvar regel som passa. Til slutt omsetjinga: NAT undervegs erstattar kjelda som vart vald. Den reflekterte adressa er produktet av alle tre, ikkje ein eigenskap ved tunnelen.
Endrar du éin av dei tre, endrar svaret seg medan kvar komponent framleis ser sunn ut i sin eigen logg. Det er den vanlege grunnen til at denne diagnosen stoppar opp.
Skriv ned dei tre fakta for flyten du testar før du byrjar. Grensesnitt, rute og omsetjingsregel er nok til å føreseie resultatet, og nettopp føreseiinga gjer ei overrasking informativ. Klarar du ikkje å fylle inn éin av dei tre, er det holet det eigentlege funnet.
Følg éin binding request gjennom vegen
Ein STUN-binding request ber ein tenar rapportere kjelde-transportadressa han observerte. Svaret skildrar vegen førespurnaden tok, ikkje ei oversikt over grensesnitt på klientmaskinen. To førespurnader over to vegar rapporterer ærleg to ulike adresser.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Les tabellen som eit sett vilkår, ikkje som ein meny av leverandørar. Den midterste rada krev at den private reflektoren er nåbar under tunnelens eigen ruting og peer-policy; det er eit konfigurasjonsfaktum du kan stadfeste, og ikkje noko eit kontonivå antydar. Den nedste rada er vanlegvis den som tel for policyen, fordi den trafikken skulle blitt inne i tunnelen. Mellom dei ligg det vanlege tilfellet, der utgangen omset og reflektoren berre ser utgangen.
Vertskandidatar og tenar-refleksive kandidatar kjem frå ulike mekanismar, så ei kandidatliste seier ikkje kva veg media faktisk brukte. Les det valde paret, ikkje innsamlingsloggen, når du vil vite kvar sesjonen gjekk.
Kva ruterens tunneladresse ikkje er
Ei tunneladresse som er tildelt ruteren, høyrer til eit grensesnitt på ruteren. Ein nettlesar på ein LAN-vert har eigne grensesnittadresser og inga direkte innsikt i tunnelgrensesnittet til ruteren. Handsamar ein dei to som utskiftbare, får ein skråsikre gale svar på kva ei nettside kan lære.
Vidaresending er det som knyter dei saman. Førespurnaden kryssar ruteren som ruta trafikk, og kjelda er det ruting og omsetjing skapte.
Viss tunnelvegen bevarar LAN-kjelda, kan ein privat reflektor lære den LAN-adressa, noko som er ei ekte avsløring og ei anna enn tunneladressa. Viss vegen omset til tunneladressa, lærer reflektoren i staden tunneladressa. Begge utfalla er samsvarande med same nettlesaren på same verten, og difor må ei observasjon knytast til ein bestemt flyt. Spør kjernen kva kjelde han ville bruke før du gir programmet skulda.
Avsløring mot omgåing: to funn, to reparasjonar
Ei reflektert tunneladresse avslører ein intern identifikator over ein veg du tillét. Ein førespurnad rett over WAN-et omgår ein veg du meinte å krevje. Det fyrste er eit informasjonsspørsmål, det andre eit handhevingsspørsmål, og dei blir retta på ulike stader. Slår ein dei saman til eitt ord, får ein ein reparasjon som ikkje tek tak i nokon av dei.
WebRTC gjer dette meir synleg utan å gjere det gale, sidan det å samle ein kandidat ikkje er det same som å velje han.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showKøyr rutespørjinga for kvar reflektoradresse du tillèt, med kjelda du ventar at flyten ber, og køyr ho så igjen for dei utelatne områda for å sjå kva reservevegen vel. Samanlikn dei to svara med policyen du skreiv ned. Når dei vik av på ein måte du ikkje meinte, har du funne reparasjonspunktet utan å måtte tolke ei kandidatliste frå ein nettlesar i det heile.