Kion malkaŝas STUN-respondo kiam la VPN funkcias sur la enkursigilo
La tunela adreso de la enkursigilo ne estas la loka adreso de la retumilo. Spuru, kiel ĉiu peto estas enkursigita kaj tradukita, antaŭ ol legi, kion raportas reflektilo.
Kiam la tunelo loĝas sur la enkursigilo, la maŝino, kiu rulas la retumilon, tute ne havas tunelan interfacon. Demandu tiun maŝinon pri ĝiaj lokaj adresoj kaj vi ricevas privatan LAN-adreson kaj retron, nenion, kio similus VPN-adreson. Tamen STUN-servilo ĉe la alia flanko ankoraŭ povas raporti ion signifan pri la vojo, kaj tio, kion ĝi raportas, tute dependas de tio, kiel tiu konkreta peto estis enkursigita kaj tradukita.
Ĝuste tiu parto indas malrapidigi. „La retumilo ne posedas la VPN-adreson“ respondas demandon pri interfacoj, dum reflektita adreso estas respondo pri vojo tra tradukado. Konfuzi la du aferojn naskas memfidajn konkludojn pri malkaŝo, kiujn la pruvoj ne subtenas.
Du aparatoj, du aroj da interfacoj
En enkursigila aranĝo la tunelo finiĝas sur la enkursigilo kaj la LAN-kliento sendas ordinaran trafikon al sia defaŭlta pordego. La interfaclisto de la kliento restas mallonga: unu privata adreso, eble dua por alia reto, kaj retron. La risko ne estas, ke unu el ili hazarde estas la tunela adreso; la risko estas, ke la peto eliras per vojo, kiun vi ne elektis.
Demandu la klienton kiun vojon specifa celo prenus anstataŭ demandi, kiuj interfacoj ekzistas. La respondo nomas pordegon kaj la fontadreson, kiun la kerno uzus, kio jam estas pli informa ol ia ajn adreslisto.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips
Dokumentaj gamoj estas bonaj testceloj ĉar ili neniam solviĝas al reala servo. Komparu, kion diras la kliento, kun tio, kion diras la enkursigilo, kaj traktu ĉian malkonsenton kiel pruvon, ke politika enkursigado, regulo de dividita tunelo aŭ dua defaŭlta vojo faras ion, kion vi ne antaŭvidis.
Kion Binding-respondo rajtas diri
RFC 8489 difinas la Binding-peton kaj -respondon, kie la servilo raportas la fontan transportadreson, kiun ĝi observis por tiu peto. Ĝi estas aserto pri unu kvintopo en unu momento, ne censo de la interfacoj de la kliento. Tial ĉio interesa okazas inter la kliento kaj la observejo.
Tiun breĉon plenigas enkursigado kaj tradukado. Enkursigilo, kiu faras fontan NAT sur eliranta trafiko, anstataŭigas la privatan fonton de la kliento per sia propra adreso sur la elira interfaco. Se tiu interfaco estas la tunelo, la reflektilo vidas la tunelan adreson. Se la pako estis ekskludita el la tunelo, la reflektilo vidas tion, kion produktis la WAN-traduko. Sama kliento, sama reflektilo, malsama respondo.
Tri kazoj, kiuj aspektas same kaj ne estas
La utila distingo ne estas publika kontraŭ privata, sed kiu devigpunkto traktis la pakon. Trairu la kazojn kun la propraj tabeloj de la enkursigilo malfermitaj, ĉar unu retumilo povas produkti ĉiujn tri depende de regulo, kiun vi forgesis, ke vi skribis.
| 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 |
Nur la dua kazo rompas postulon, ke certa trafiko neniam eliru rekte, kaj nur la unua kaj la tria malkaŝas identigilon el la tunela flanko. Neniu el la tri linioj estas aserto pri la konduto de specifa provizanto: ĉu privata reflektilo entute atingeblas dependas de enkursigado, de la permesitaj IP-adresoj de la alia flanko kaj de la fajroŝirma politiko ĉe ambaŭ finoj.
Posedi konton ĉe la sama provizanto pruvas nenion el tio. Indas ankaŭ memori, ke enkursigita peto povas konservi la LAN-fonton de la kliento, se nenio tradukas ĝin, do la fonta kampo devas esti spurata kaj ne supozata el la topologia diagramo.
Kolekti ne estas elekti
WebRTC kolektas kandidatajn adresojn por provi, kaj kandidato, kiu aperas en diagnoza listo, eble neniam portos amaskomunikilaron. Legi la liston kiel „jen kion lernis la alia flanko“ troigas la pruvojn. La elektita paro estas tio, kio fakte portis la seancon, kaj ĝi loĝas en alia kampo.
HTTPS-elirkontrolo respondas ankoraŭ alian demandon: la fontadreson, kiun retservilo vidis por tiu peto. Ĝi estas utila kruca kontrolo ĝuste ĉar ĝi uzas alian protokolon kaj ofte alian celon ol UDP-reflektilo, kaj malkonsento inter la du kutime indikas enkursigan regulon, ne cimon.
Decidu la politikon, poste legu la respondon
Skribu la intencon antaŭ la testado: kiu trafiko devas uzi la tunelon, kiu rajtas eliri rekte, kiuj adresfamilioj estas en la amplekso, kaj kio devus okazi, kiam la tunelo estas malsupre. Sen tiu bazlinio ĉiu observo estas dusenca, ĉar vi ne povas apartigi likon de vojo, kiun vi intence permesis.
Poste demandu unu demandon samtempe. Kiun vojon prenas ĉi tiu celo. Kiun adreson raportas ĉi tiu reflektilo. Kiun kandidatan paron elektis la seanco. Tenu la respondojn apud la politiko kaj datu ilin, ĉar firmvara ĝisdatigo povas ŝanĝi la defaŭltan konduton tiel, ke ĝi silente malvalidigas la konkludon de la pasinta jaro.
La enkursigilo restas forta devigpunkto, ĉar ĝi vidas trafikon, kiun kliento ne povas preteriri sen rekondiĝi mem. Ĝi ne estas promeso, ke ĉiu kampo en ĉiu aplikaĵa protokolo malkaŝas nenion, kaj ĝi ne anstataŭas skribi la vojojn, kiujn vi decidis permesi.