Wat ’n STUN-antwoord onthul wanneer die VPN op die router werk
Die tonneladres van die router is nie die blaaier se plaaslike adres nie. Volg hoe elke versoek gerouteer en vertaal word voordat jy lees wat ’n reflektor rapporteer.
Wanneer die tonnel op die router woon, het die masjien wat die blaaier laat loop heeltemal geen tonnelkoppelvlak nie. Vra daardie masjien na sy plaaslike adresse en jy kry ’n private LAN-adres en ’n loopback, niks wat aan ’n VPN-adres herinner nie. Tog kan ’n STUN-bediener aan die oorkant steeds iets sinvols oor die pad rapporteer, en wat dit rapporteer hang heeltemal daarvan af hoe daardie spesifieke versoek gerouteer en vertaal is.
Dit is die deel waarvoor dit werd is om stil te staan. “Die blaaier besit nie die VPN-adres nie” beantwoord ’n vraag oor koppelvlakke, terwyl ’n weerkaatste adres ’n antwoord oor ’n pad deur vertaling is. Om die twee te verwar lewer selfversekerde gevolgtrekkings oor openbaarmaking wat die bewyse nie ondersteun nie.
Twee toestelle, twee stelle koppelvlakke
In ’n routergebaseerde opstelling eindig die tonnel op die router en die LAN-kliënt stuur gewone verkeer na sy verstekpoort. Die kliënt se koppelvlaklys bly kort: een private adres, miskien ’n tweede vir ’n ander netwerk, en loopback. Die risiko is nie dat een van dié toevallig die tonneladres is nie; dit is dat die versoek deur ’n pad vertrek wat jy nie gekies het nie.
Vra die kliënt watter roete ’n spesifieke bestemming sou volg in plaas daarvan om te vra watter koppelvlakke bestaan. Die antwoord noem ’n poort en die bronadres wat die kern sou gebruik, wat alreeds meer insiggewend is as enige adreslys.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentasie-reekse is goeie toetsbestemmings omdat hulle nooit na ’n werklike diens oplos nie. Vergelyk wat die kliënt sê met wat die router sê, en beskou enige verskil as bewys dat beleidroutering, ’n split-tonnel-reël of ’n tweede verstekroete iets doen waarvoor jy nie rekening gehou het nie.
Wat ’n Binding-antwoord mag sê
RFC 8489 definieer die Binding-versoek en -antwoord, waar die bediener die brontransportadres rapporteer wat hy vir daardie versoek gesien het. Dit is ’n stelling oor een vyf-tupel op een oomblik, nie ’n sensus van die kliënt se koppelvlakke nie. Alles interessante gebeur dus tussen die kliënt en die punt van waarneming.
Daardie gaping word deur routering en vertaling gevul. ’n Router wat uitgaande verkeer source-NAT, vervang die kliënt se private bron met sy eie adres op die uitgaande koppelvlak. As daardie koppelvlak die tonnel is, sien die reflektor die tonneladres. As die pakkie van die tonnel uitgesluit is, sien die reflektor wat die WAN-vertaling opgelewer het. Dieselfde kliënt, dieselfde reflektor, verskillende antwoord.
Drie gevalle wat eenders lyk en nie is nie
Die nuttige onderskeid is nie publiek teenoor privaat nie, maar watter handhawingspunt die pakkie hanteer het. Werk die gevalle deur met die router se eie tabelle oop, want een blaaier kan al drie lewer, afhangende van ’n reël wat jy vergeet het jy geskryf het.
| 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 |
Net die tweede geval breek ’n vereiste dat sekere verkeer nooit reguit mag vertrek nie, en net die eerste en derde openbaar ’n tonnel-kant-identifiseerder. Nie een van die drie rye is ’n bewering oor ’n bepaalde verskaffer se gedrag nie: of ’n private reflektor hoegenaamd bereikbaar is, hang af van routering, peer allowed-ips en firewallbeleid aan beide kante.
Om ’n rekening by dieselfde verskaffer te hê, bewys niks daarvan nie. Dit is ook die moeite werd om te onthou dat ’n gerouteerde versoek die kliënt se LAN-bron kan behou as niks dit vertaal nie, so die bronveld moet nagespeur word eerder as uit die topologie-diagram afgelei word.
Versameling is nie seleksie nie
WebRTC versamel kandidaatadresse om te probeer, en ’n kandidaat wat in ’n diagnostiese lys verskyn, dra dalk nooit media nie. Om die lys te lees as “dit is wat die peer geleer het” oorskat die bewyse. Die gekose paar is wat die sessie werklik gedra het, en dit woon in ’n ander veld.
’n HTTPS-uitgangstoets beantwoord nog ’n vraag: die bronadres wat ’n webbediener vir daardie versoek gesien het. Dit is ’n nuttige kruiskontrole juis omdat dit ’n ander protokol en dikwels ’n ander bestemming as ’n UDP-reflektor gebruik, en onenigheid tussen die twee dui gewoonlik op ’n routeringsreël eerder as op ’n fout.
Bepaal die beleid, lees dan die antwoord
Skryf die bedoeling neer voordat jy toets: watter verkeer die tonnel moet gebruik, watter reguit mag vertrek, watter adresfamilies in bereik is, en wat moet gebeur wanneer die tonnel af is. Sonder daardie basislyn is elke waarneming dubbelsinnig, want jy kan nie ’n lek van ’n doelbewus toegelate pad skei nie.
Vra dan een vraag op ’n slag. Watter roete volg hierdie bestemming. Watter adres rapporteer hierdie reflektor. Watter kandidaatpaar het die sessie gekies. Hou die antwoorde langs die beleid en dateer hulle, want ’n firmware-opdatering kan verstekgedrag verander op maniere wat verlede jaar se gevolgtrekking stilweg ongeldig maak.
Die router is steeds ’n sterk handhawingspunt, want dit sien verkeer wat ’n kliënt nie kan omseil sonder om die kliënt self te herkonfigureer nie. Dit is nie ’n belofte dat elke veld in elke toepassingprotokol niks openbaar nie, en dit is geen plaasvervanger daarvoor om die paaie neer te skryf wat jy gekies het om toe te laat nie.