Wat in STUN-antwurd ferriedt as de VPN op de router draait
It tunneladres fan de router is net it lokale adres fan de browser. Folgje hoe’t elk fersyk rûte en oerset wurdt foar’t jo lêze wat in reflektor rapportearret.
As de tunnel op de router wennet, hat de masine dy’t de browser draait hielendal gjin tunnelinterface. Freegje dy masine om har lokale adressen en jo krije in privee LAN-adres en in loopback, neat dat op in VPN-adres liket. Dochs kin in STUN-tsjinner oan de oare kant noch wat sinfols oer it paad rapportearje, en wat dy rapportearret hinget folslein ôf fan hoe’t dat spesifike fersyk rûte en oerset is.
Dat is it diel dêr’t it wurdich is om stadiger te dwaan. “De browser besit it VPN-adres net” beantwurdet in fraach oer ynterfaces, wylst in weromkeard adres in antwurd is oer in paad troch oersetting. It trochinoar heljen fan dy twa jout selsfoldiene konklúzjes oer iepenbaring dy’t it bewiis net stypje.
Twa apparaten, twa sets ynterfaces
Yn in routerbasearre opset einiget de tunnel op de router en de LAN-klant stjoert gewoane ferkear nei syn standertgateway. De ynterfacelist fan de klant bliuwt koart: ien privee adres, miskien in twadde foar in oar netwurk, en loopback. It risiko is net dat ien fan dy tafallich it tunneladres is; it is dat it fersyk fia in paad fuortgiet dat jo net keazen hawwe.
Freegje de klant hokker rûte in beskaat doel nimme soe ynstee fan te freegjen hokker ynterfaces besteane. It antwurd neamt in gateway en it boarneadres dat de kearn brûke soe, en dat is al mear ynformatyf as hokker adresoersjoch dan ek.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips
Dokumintaasjeberikken binne goede testdoelen om’t se nea nei in echte tsjinst oplosse. Ferlykje wat de klant seit mei wat de router seit, en behannelje elk ûnienigens as bewiis dat beliedsrûtering, in split-tunnelregel of in twadde standertrûte eat docht dêr’t jo gjin rekken mei hâlden hawwe.
Wat in Binding-antwurd sizze mei
RFC 8489 definiearret it Binding-fersyk en -antwurd, wêrby’t de tsjinner it boarnetransportadres rapportearret dat er foar dat fersyk waarnommen hat. It is in bewearing oer ien fiifling op ien momint, net in folkstelling fan de ynterfaces fan de klant. Dat alle nijsgjirrige bart tusken de klant en it waarnimmingspunt.
Dat gat wurdt fold troch rûtering en oersetting. In router dy’t útgeand ferkear boarne-NAT, ferfangt de privee boarne fan de klant troch syn eigen adres op de útgeande ynterface. As dy ynterface de tunnel is, sjocht de reflektor it tunneladres. As it pakket fan de tunnel útsletten is, sjocht de reflektor wat de WAN-oersetting makke hat. Deselde klant, deselde reflektor, oar antwurd.
Trije gefallen dy’t opinoar lykje en it net binne
It nuttige ûnderskie is net publiek tsjin privee, mar hokker hanthaveningspunt it pakket behannele hat. Wurkje de gefallen troch mei de eigen tabellen fan de router iepen, om’t ien browser alle trije meitsje kin ôfhinklik fan in regel dy’t jo fergetten binne te skriuwen.
| 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 |
Allinnich it twadde gefal brekt de eask dat beskate ferkear nea direkt fuortgiet, en allinnich it earste en it tredde iepenje in identifikator fan de tunnelside. Gjin fan de trije rigen is in bewearing oer it gedrach fan in beskaat leveransier: oft in privee reflektor berikber is, hinget ôf fan rûtering, de tastiene IP-adressen fan de oare kant en it firewallbelied oan beide kanten.
In akkount hawwe by deselde leveransier bewiist dêr neat fan. It is ek wurdich te ûnthâlden dat in rûte fersyk de LAN-boarne fan de klant hâlde kin as neat dy oerset, dus it boarnefjild moat folge wurde ynstee fan ôflaat fan it topologydiagram.
Sammele is net selektearje
WebRTC sammelet kandidaatadressen om te besykjen, en in kandidaat dy’t yn in diagnostyske list opkomt, draacht miskien nea media. De list lêze as “dit is wat de oare kant leard hat” oerskat it bewiis. It keazen pear is wat de sesje wier droegen hat, en it wennet yn in oar fjild.
In HTTPS-útgongskontrôle beantwurdet noch in fraach: it boarneadres dat in webserver foar dat fersyk seach. It is in nuttige krúskontrôle krekt om’t it in oar protokol en faaks in oar doel brûkt as in UDP-reflektor, en ûnienigens tusken dy twa wiist meastentiids op in rûteringsregel ynstee fan op in bug.
Bepale it belied, lês dan it antwurd
Skriuw it foarnimmen op foar’t jo teste: hokker ferkear de tunnel brûke moat, hokker direkt fuort meie, hokker adresfamyljes yn berik binne, en wat barre moat as de tunnel del is. Sûnder dy basisline is elke waarnimming dûbelsinnich, om’t jo in lek net skiede kinne fan in paad dat jo bewust tastien hawwe.
Freegje dan ien fraach tagelyk. Hokker rûte nimt dit doel. Hokker adres rapportearret dizze reflektor. Hokker kandidaatpear hat de sesje keazen. Hâld de antwurden njonken it belied en datearje se, om’t in firmwarefernijing it standertgedrach feroarje kin op manieren dy’t de konklúzje fan ferline jier stil útskeakelje.
De router is noch altyd in sterk hanthaveningspunt, om’t er ferkear sjocht dat in klant net omgean kin sûnder de klant sels op ’e nij te konfigurearjen. It is gjin belofte dat elk fjild yn elk tapassingsprotokol neat iepenbieret, en it is gjin ferfanging foar it opskriuwen fan de paden dy’t jo keazen hawwe ta te stean.