Hvilken kildeadresse ser STUN med en ruter-VPN?
Rute, kildevalg og oversettelse avgjør adressen en reflektor rapporterer. Tre fakta å skrive ned, deretter ett søk for å bekrefte hvilken vei som vinner.
Spørsmålet høres ut som ett oppslag og er egentlig tre beslutninger. Hvilken rute binding requesten tar, hvilken kilde kjernen velger for den ruten, og om noe underveis skriver om den kilden. Endre én av dem, og adressen en STUN-server rapporterer endres med den. Derfor sier påstanden om at VPN-en sitter på ruteren nesten ingenting i seg selv.
Beslutningen hviler på tre fakta
Først ruten: policyregler og rutetabellen avgjør om forespørselen går ut gjennom tunnelen eller gjennom det vanlige WAN-et, og en utelatt destinasjon tar den andre veien selv mens en tunnel er oppe. Så kilden: kjernen velger en kilde for den valgte ruten, og valget avhenger av rutens foretrukne kilde og av enhver regel som traff. Til slutt oversettelsen: NAT underveis erstatter kilden som ble valgt. Den reflekterte adressen er produktet av alle tre, ikke en egenskap ved tunnelen.
Endre én av de tre, og svaret endres mens hver komponent fortsatt ser sunn ut i sin egen logg. Det er den vanlige grunnen til at denne diagnosen stopper opp.
Skriv ned de tre fakta for flyten du tester før du begynner. Grensesnitt, rute og oversettelsesregel er nok til å forutsi resultatet, og nettopp forutsigelsen gjør en overraskelse informativ. Klarer du ikke å fylle inn én av de tre, er det hullet det egentlige funnet.
Følg én binding request gjennom veien
En STUN-binding request ber en server rapportere kilde-transportadressen den observerte. Svaret beskriver veien forespørselen tok, ikke en oversikt over grensesnitt på klientmaskinen. To forespørsler over to veier rapporterer ærlig to forskjellige 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 et sett betingelser, ikke som en meny av leverandører. Den midterste raden krever at den private reflektoren er nåbar under tunnelens egen ruting og peer-policy; det er et konfigurasjonsfaktum du kan verifisere, og ikke noe et kontonivå antyder. Den nederste raden er vanligvis den som betyr noe for policyen, fordi den trafikken skulle blitt inne i tunnelen. Mellom dem ligger det vanlige tilfellet, der exit-noden oversetter og reflektoren bare ser exit-noden.
Vertskandidater og server-refleksive kandidater kommer fra forskjellige mekanismer, så en kandidatliste er ikke en uttalelse om hvilken vei mediet faktisk brukte. Les det valgte paret, ikke innsamlingsloggen, når du vil vite hvor sesjonen gikk.
Hva ruterens tunneladresse ikke er
En tunneladresse som er tildelt ruteren, tilhører et grensesnitt på ruteren. En nettleser på en LAN-vert har egne grensesnittadresser og ingen direkte innsikt i ruterens tunnelgrensesnitt. Behandler man de to som utskiftbare, får man skråsikre gale svar på hva en nettside kan lære.
Videresending er det som forbinder dem. Forespørselen krysser ruteren som rutet trafikk, og kilden er det ruting og oversettelse produserte.
Hvis tunnelveien bevarer LAN-kilden, kan en privat reflektor lære den LAN-adressen, noe som er en ekte avsløring og en annen enn tunneladressen. Hvis veien oversetter til tunneladressen, lærer reflektoren i stedet tunneladressen. Begge utfallene er forenlige med samme nettleser på samme vert, og derfor må en observasjon knyttes til en bestemt flyt. Spør kjernen hvilken kilde den ville brukt før du gir applikasjonen skylden.
Avsløring mot omgåelse: to funn, to reparasjoner
En reflektert tunneladresse avslører en intern identifikator over en vei du tillot. En forespørsel direkte over WAN-et omgår en vei du mente å kreve. Det første er et informasjonsspørsmål, det andre et håndhevingsspørsmål, og de rettes på forskjellige steder. Slår man dem sammen til ett ord, får man en reparasjon som ikke adresserer noen av dem.
WebRTC gjør dette mer synlig uten å gjøre det galt, siden det å samle en kandidat ikke er det samme som å velge den.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showKjør rutespørringen for hver reflektoradresse du tillater, med kilden du forventer at flyten bærer, og kjør den så igjen for de utelatte områdene for å se hva reserveveien velger. Sammenlign de to svarene med policyen du skrev ned. Når de avviker på en måte du ikke mente, har du funnet reparasjonspunktet uten å måtte tolke en nettlesers kandidatliste i det hele tatt.