Hokker boarneadres sjocht STUN by in router-VPN?
Rûte, boarnekar en oersetting beslisse it adres dat in reflektor meldt. Trije feiten opskriuwe, dan ien query om te befêstigjen hokker paad wint.
De fraach klinkt as ien opsykjen en is eins trije beslissingen. Hokker rûte it binding-request nimt, hokker boarne de kernel foar dy rûte kiest, en oft wat ûnderweis dy boarne oerskriuwt. Feroarje ien fan de trije en it adres dat in STUN-tsjinner meldt feroaret mei. Dêrom seit de bewearing dat de VPN op de router sit op himsels hast neat.
De beslissing berêst op trije feiten
Earst de rûte: beliedsregels en de routingtabel beslisse oft it request troch de tunnel of troch de gewoane WAN nei bûten giet, en in útsletten bestimming nimt it twadde paad sels wylst in tunnel oan stiet. Twad de boarne: de kernel kiest in boarne foar de keazen rûte, en dy kar hinget ôf fan 'e foarkarsboarne fan 'e rûte en fan elke regel dy't matche. Tred de oersetting: NAT ûnderweis ferfangt hokker boarne dan ek keazen is. It wjerkeatste adres is it produkt fan alle trije, net in eigenskip fan 'e tunnel.
Feroarje ien fan de trije en it antwurd feroaret wylst elke komponint yn syn eigen log noch sûn liket. Dat is de gewoane reden wêrom't dizze diagnoaze fêstrint.
Skriuw de trije feiten op foar de flow dy't jo testearje foardat jo begjinne. Ynterface, rûte en oersettingsregel binne genôch om it resultaat te foarsizzen, en krekt dy foarsizzing makket in ferrassing ynformatyf. Kinne jo ien fan de trije net ynfolje, dan is dy leechte de eigentlike befinning.
Folgje ien binding-request troch it paad
In STUN-binding-request freget in tsjinner om it waarnommen boarne-transportadres te melden. It antwurd beskriuwt it paad dat it request nommen hat, net in ynventaris fan ynterfaces op 'e kliïntmasine. Twa requests oer twa paden melde earlik twa ferskillende adressen.
| 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 dy tabel as in set betingsten, net as in menu fan oanbieders. De middelste rigel freget dat de private reflektor berikber is ûnder it eigen routing- en peerbelied fan 'e tunnel; dat is in konfiguraasjefeit dat jo ferifiearje kinne en net eat dat in accountnivo implisearret. De ûnderste rigel is foar belied meastal de wichtichste, want dat ferkear hearde yn 'e tunnel te bliuwen. Tusken beide sit it gewoane gefal, wêryn't de útgong oerset en de reflektor allinnich de útgong sjocht.
Hostkandidaten en tsjinner-refleksive kandidaten komme út ferskillende meganismen, dus in kandidatelist is gjin útspraak oer hokker paad de media wier brûkten. Lês it keazen pear, net it sammellog, as jo witte wolle wêr't de sesje hinne gie.
Wat it tunneladres fan 'e router net is
In tunneladres dat oan 'e router tawiisd is, heart by in ynterface op 'e router. In browser op in LAN-host hat eigen ynterfaceadressen en gjin direkte sicht op 'e tunnelinterface fan 'e router. Beide as útwikselber behannelje jout selsfertroude ferkearde antwurden oer wat in webside leare kin.
Trochstjoeren is wat har ferbynt. It request giet as routed ferkear troch de router, en syn boarne is wat routing en oersetting opsmieten.
As it tunnelpaad de LAN-boarne behâldt, kin in private reflektor dat LAN-adres leare, wat in echte iepenbaring is en in oare as it tunneladres. As it paad nei it tunneladres oerset, leart de reflektor ynstee it tunneladres. Beide útkomsten binne konsekwint mei deselde browser op deselde host, en dêrom moat in waarnimming oan in spesifike flow keppele wurde. Freegje de kernel hokker boarne er brûke soe foardat jo de applikaasje de skuld jouwe.
Iepenbaring tsjin omgong: twa befinningen, twa reparaasjes
In wjerkeatst tunneladres iepenbieret in ynterne identifikaasje oer in paad dat jo tastien hawwe. In request streekrjocht oer de WAN giet om in paad hinne dat jo ferplichtsje woenen. It earste is in ynformaasjefraach, it twadde in hanthaveningsfraach, en se wurde op ferskillende plakken reparaearre. Se yn ien wurd gearfetsje jout in reparaasje dy't gjin fan beide oanpakt.
WebRTC makket dit sichtberder sûnder it ferkeard te meitsjen, want in kandidaat sammelje is net itselde as der ien kieze.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showFier de rûtequery út foar elk reflektoradres dat jo tastean, mei de boarne dy't jo ferwachtsje dat dy flow draacht, en fier him dan nochris út foar de útsletten berikken om te sjen wat de fallback kiest. Fergelykje de twa antwurden mei it belied dat jo opskreaun hawwe. As se ferskille op in manier dy't jo net bedoelden, hawwe jo it reparaasjepunt fûn sûnder ea in kandidatelist fan in browser ynterpretearje te moatten.