Vad ett STUN-svar avslöjar när VPN:en körs på routern
Routerns tunneladress är inte webbläsarens lokala adress. Följ hur varje begäran routas och översätts innan du läser vad en reflektor rapporterar.
När tunneln bor på routern har maskinen som kör webbläsaren inget tunnelgränssnitt alls. Fråga den maskinen om dess lokala adresser och du får en privat LAN-adress och en loopback, ingenting som liknar en VPN-adress. Ändå kan en STUN-server på andra sidan fortfarande rapportera något meningsfullt om vägen, och vad den rapporterar beror helt på hur just den begäran routades och översattes.
Det är den delen som är värd att sänka tempot för. ”Webbläsaren äger inte VPN-adressen” svarar på en fråga om gränssnitt, medan en reflekterad adress är ett svar om en väg genom översättning. Att blanda de två ger självsäkra slutsatser om avslöjande som bevisen inte stöder.
Två enheter, två uppsättningar gränssnitt
I en routerbaserad uppsättning avslutas tunneln på routern och LAN-klienten skickar vanlig trafik till sin standardgateway. Klientens gränssnittslista förblir kort: en privat adress, kanske en till för ett annat nätverk, och loopback. Risken är inte att en av dem råkar vara tunneladressen; den är att begäran går ut över en väg du inte valde.
Fråga klienten vilken väg en viss destination skulle ta i stället för att fråga vilka gränssnitt som finns. Svaret namnger en gateway och källadressen kärnan skulle använda, och det är redan mer upplysande än någon adressförteckning.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentationsområden är bra testmål eftersom de aldrig löses upp till en riktig tjänst. Jämför vad klienten säger med vad routern säger, och behandla varje oenighet som bevis för att principbaserad routning, en delad tunnel-regel eller en andra standardväg gör något du inte har räknat med.
Vad ett Binding-svar får säga
RFC 8489 definierar Binding-begäran och -svaret, där servern rapporterar den källtransportadress den observerade för den begäran. Det är ett uttalande om en enda femling vid ett tillfälle, inte en folkräkning av klientens gränssnitt. Allt intressant sker därför mellan klienten och observationspunkten.
Den luckan fylls av routning och översättning. En router som käll-NAT:ar utgående trafik ersätter klientens privata källa med sin egen adress på det utgående gränssnittet. Är det gränssnittet tunneln ser reflektorn tunneladressen. Uteslöts paketet från tunneln ser reflektorn det WAN-översättningen producerade. Samma klient, samma reflektor, annat svar.
Tre fall som ser likadana ut och inte är det
Den användbara skillnaden är inte offentlig kontra privat, utan vilken tvingande punkt som hanterade paketet. Arbeta igenom fallen med routerns egna tabeller öppna, eftersom en enda webbläsare kan producera alla tre beroende på en regel du glömde att du skrev.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Bara det andra fallet bryter kravet att viss trafik aldrig går ut direkt, och bara det första och det tredje avslöjar en identifierare från tunnelsidan. Ingen av de tre raderna är ett påstående om en viss leverantörs beteende: om en privat reflektor alls är nåbar beror på routning, motpartens tillåtna IP-adresser och brandväggspolicyn i båda ändarna.
Att ha ett konto hos samma leverantör bevisar ingenting av detta. Det är också värt att komma ihåg att en routad begäran kan behålla klientens LAN-källa om ingenting översätter den, så källfältet måste spåras i stället för att antas från topologidiagrammet.
Insamling är inte urval
WebRTC samlar kandidatadresser att prova, och en kandidat som dyker upp i en diagnostisk lista bär kanske aldrig media. Att läsa listan som ”det här är vad motparten lärde sig” överdriver bevisen. Det valda paret är det som faktiskt bar sessionen, och det finns i ett annat fält.
En HTTPS-utgångskontroll svarar på ännu en fråga: den källadress som en webbserver såg för den begäran. Det är en användbar korscheck just för att den använder ett annat protokoll och ofta en annan destination än en UDP-reflektor, och oenighet mellan de två pekar vanligen på en routningsregel snarare än en bugg.
Bestäm policyn, läs sedan svaret
Skriv ner avsikten före testning: vilken trafik som måste använda tunneln, vilken som får gå direkt ut, vilka adressfamiljer som ingår och vad som ska hända när tunneln ligger nere. Utan den baslinjen är varje observation tvetydig, eftersom du inte kan skilja ett läckage från en väg du medvetet tillät.
Ställ sedan en fråga i taget. Vilken väg tar denna destination. Vilken adress rapporterar denna reflektor. Vilket kandidatpar valde sessionen. Håll svaren bredvid policyn och datera dem, eftersom en firmwareuppdatering kan ändra standardbeteendet på sätt som tyst ogiltigförklarar fjolårets slutsats.
Routern är fortfarande en stark tvingande punkt, eftersom den ser trafik som en klient inte kan kringgå utan att omkonfigurera sig själv. Det är inget löfte om att varje fält i varje applikationsprotokoll inte avslöjar något, och det ersätter inte att skriva ner de vägar du valde att tillåta.