Vilken källadress ser STUN med ett router-VPN?
Rutt, källval och översättning avgör den adress som en reflektor rapporterar. Tre fakta att skriva ner, sedan en fråga för att bekräfta vilken väg som vinner.
Frågan låter som en enda uppslagning och är egentligen tre beslut. Vilken rutt binding requesten tar, vilken källa kärnan väljer för den rutten, och om något på vägen skriver om den källan. Ändra en av dem och adressen som en STUN-server rapporterar ändras med den. Därför säger påståendet att VPN:en sitter på routern nästan ingenting i sig.
Beslutet vilar på tre fakta
Först rutten: policyregler och routingtabellen avgör om begäran lämnar via tunneln eller via det vanliga WAN:et, och en undantagen destination tar den andra vägen även medan en tunnel är uppe. Sedan källan: kärnan väljer en källa för den valda rutten, och valet beror på ruttens föredragna källa och på varje regel som matchade. Till sist översättningen: NAT på vägen ersätter vilken källa som än valdes. Den reflekterade adressen är produkten av alla tre, inte en egenskap hos tunneln.
Ändra en av de tre och svaret ändras medan varje komponent fortfarande ser frisk ut i sin egen logg. Det är det vanliga skälet till att den här diagnosen kör fast.
Skriv ner de tre fakta för det flöde du testar innan du börjar. Gränssnitt, rutt och översättningsregel räcker för att förutsäga resultatet, och just förutsägelsen gör en överraskning informativ. Om du inte kan fylla i en av de tre är den luckan det egentliga fyndet.
Följ en binding request genom vägen
En STUN-binding request ber en server att rapportera den källtransportadress den observerade. Svaret beskriver den väg begäran tog, inte en inventering av gränssnitt på klientmaskinen. Två begäranden över två vägar rapporterar ärligt två olika 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 en uppsättning villkor, inte som en meny av leverantörer. Den mellersta raden kräver att den privata reflektorn nås under tunnelns egen routing och peer-policy; det är ett konfigurationsfaktum du kan verifiera och inte något som en kontonivå antyder. Den nedersta raden är oftast den som spelar roll för policyn, eftersom den trafiken var tänkt att stanna i tunneln. Mellan dem ligger det vanliga fallet, där exit-noden översätter och reflektorn bara ser exit-noden.
Värdkandidater och server-reflexiva kandidater kommer från olika mekanismer, så en kandidatlista är inget uttalande om vilken väg mediet faktiskt använde. Läs det valda paret, inte insamlingsloggen, när du vill veta vart sessionen tog vägen.
Vad routerns tunneladress inte är
En tunneladress som tilldelats routern hör till ett gränssnitt på routern. En webbläsare på en LAN-värd har egna gränssnittsadresser och ingen direkt insyn i routerns tunnelgränssnitt. Att behandla de två som utbytbara ger självsäkra felaktiga svar om vad en webbsida kan lära sig.
Vidarebefordran är det som förbinder dem. Begäran passerar routern som routad trafik, och dess källa är vad routing och översättning åstadkom.
Om tunnelvägen bevarar LAN-källan kan en privat reflektor lära sig den LAN-adressen, vilket är ett verkligt avslöjande och ett annat än tunneladressen. Om vägen översätter till tunneladressen lär sig reflektorn i stället tunneladressen. Båda utfallen är förenliga med samma webbläsare på samma värd, och därför måste en observation knytas till ett specifikt flöde. Fråga kärnan vilken källa den skulle använda innan du skyller på programmet.
Avslöjande kontra kringgående: två fynd, två åtgärder
En reflekterad tunneladress avslöjar en intern identifierare över en väg du tillät. En begäran direkt över WAN:et kringgår en väg du ville kräva. Det första är en informationsfråga, det andra en efterlevnadsfråga, och de åtgärdas på olika ställen. Slår man ihop dem till ett ord får man en åtgärd som inte löser någon av dem.
WebRTC gör detta mer synligt utan att göra det fel, eftersom att samla in en kandidat inte är samma sak som att välja den.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showKör ruttfrågan för varje reflektoradress du tillåter, med den källa du förväntar dig att flödet bär, och kör den sedan igen för de undantagna områdena för att se vad reservvägen väljer. Jämför de två svaren med den policy du skrev ner. När de skiljer sig på ett sätt du inte avsåg har du hittat åtgärdspunkten utan att ens behöva tolka en webbläsares kandidatlista.