Hvilken kildeadresse ser STUN med en router-VPN?
Rute, kildevalg og oversættelse afgør den adresse, en reflektor rapporterer. Tre fakta at skrive ned, derefter ét query for at bekræfte, hvilken vej der vinder.
Spørgsmålet lyder som ét opslag og er i virkeligheden tre beslutninger. Hvilken rute binding request'en tager, hvilken kilde kernen vælger til den rute, og om noget undervejs omskriver den kilde. Ændr én af dem, og den adresse, en STUN-server rapporterer, ændrer sig med. Derfor siger udsagnet om, at VPN'en sidder på routeren, næsten intet i sig selv.
Beslutningen hviler på tre fakta
For det første ruten: politikregler og routingtabellen afgør, om anmodningen forlader gennem tunnelen eller gennem det almindelige WAN, og en udelukket destination tager den anden vej, selv mens en tunnel er oppe. For det andet kilden: kernen vælger en kilde til den valgte rute, og det valg afhænger af rutens foretrukne kilde og af enhver regel, der matchede. For det tredje oversættelsen: NAT undervejs erstatter den valgte kilde. Den reflekterede adresse er produktet af alle tre, ikke en egenskab ved tunnelen.
Ændr en af de tre, og svaret ændrer sig, mens hver komponent stadig ser sund ud i sin egen log. Det er den sædvanlige grund til, at denne diagnose går i stå.
Skriv de tre fakta ned for den flow, du tester, før du begynder. Interface, rute og oversættelsesregel er nok til at forudsige resultatet, og netop forudsigelsen gør en overraskelse informativ. Kan du ikke udfylde en af de tre, er det hul det egentlige fund.
Følg én binding request gennem vejen
En STUN-binding request beder en server om at rapportere den observerede kilde-transportadresse. Svaret beskriver den vej, anmodningen tog, ikke en oversigt over interfaces på klientmaskinen. To anmodninger ad to veje rapporterer ærligt to forskellige 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 |
Læs tabellen som et sæt betingelser, ikke som en menu over udbydere. Den midterste række kræver, at den private reflektor kan nås under tunnelens egen routing og peer-politik; det er et konfigurationsfaktum, du kan verificere, og ikke noget, et kontoniveau antyder. Den nederste række er normalt den, der betyder noget for politik, fordi den trafik skulle blive inde i tunnelen. Imellem dem ligger det almindelige tilfælde, hvor exit'en oversætter, og reflektoren kun ser exit'en.
Host-kandidater og server-refleksive kandidater kommer fra forskellige mekanismer, så en kandidatliste er ikke en udtalelse om, hvilken vej mediet faktisk brugte. Læs det valgte par, ikke indsamlingsloggen, når du vil vide, hvor sessionen gik hen.
Hvad routerens tunneladresse ikke er
En tunneladresse, der er tildelt routeren, hører til et interface på routeren. En browser på en LAN-vært har sine egne interfaceadresser og intet direkte indblik i routerens tunnelinterface. Behandler man de to som udskiftelige, får man sikre forkerte svar på, hvad en webside kan lære.
Videresendelse er det, der forbinder dem. Anmodningen krydser routeren som routed trafik, og dens kilde er det, routing og oversættelse frembragte.
Hvis tunnelstien bevarer LAN-kilden, kan en privat reflektor lære den LAN-adresse, hvilket er en ægte afsløring og en anden end tunneladressen. Hvis stien oversætter til tunneladressen, lærer reflektoren i stedet tunneladressen. Begge udfald er forenelige med den samme browser på den samme vært, og derfor skal en observation knyttes til en bestemt flow. Spørg kernen, hvilken kilde den ville bruge, før du bebrejder applikationen.
Afsløring versus omgåelse: to fund, to reparationer
En reflekteret tunneladresse afslører en intern identifikator over en vej, du har tilladt. En anmodning direkte over WAN omgår en vej, du ville kræve. Det første er et informationsspørgsmål, det andet et håndhævelsesspørgsmål, og de repareres forskellige steder. Slår man dem sammen til ét ord, får man en reparation, der ikke adresserer nogen af dem.
WebRTC gør dette mere synligt uden at gøre det forkert, fordi det at indsamle en kandidat ikke er det samme som at vælge den.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showKør rutequeryen for hver reflektoradresse, du tillader, med den kilde, du forventer, at flowet bærer, og kør den derefter igen for de udelukkede områder for at se, hvad fallbacken vælger. Sammenlign de to svar med den politik, du skrev ned. Når de afviger på en måde, du ikke havde tilsigtet, har du fundet reparationspunktet uden at skulle fortolke en browsers kandidatliste overhovedet.