Ce adresă sursă vede STUN cu un VPN pe router?
Ruta, selecția sursei și traducerea decid adresa pe care o raportează un reflector. Trei fapte de notat, apoi o interogare pentru a confirma ce cale câștigă.
Întrebarea pare o singură căutare și în realitate sunt trei decizii. Ce rută ia binding request-ul, ce sursă alege kernelul pentru acea rută și dacă ceva pe drum rescrie acea sursă. Schimbi una dintre cele trei și adresa pe care o raportează un server STUN se schimbă odată cu ea. De aceea afirmația că VPN-ul stă pe router nu îți spune aproape nimic în sine.
Decizia se sprijină pe trei fapte
Mai întâi ruta: regulile de politică și tabela de rutare decid dacă cererea iese prin tunel sau prin WAN-ul obișnuit, iar o destinație exclusă ia a doua cale chiar și cu un tunel activ. Apoi sursa: kernelul alege o sursă pentru ruta aleasă, iar acea alegere depinde de sursa preferată a rutei și de orice regulă care s-a potrivit. În al treilea rând traducerea: NAT pe drum înlocuiește sursa care a fost aleasă. Adresa reflectată este produsul tuturor trei, nu o proprietate a tunelului.
Schimbă una dintre cele trei și răspunsul se schimbă în timp ce fiecare componentă încă pare sănătoasă în propriul jurnal. Acesta este motivul obișnuit pentru care acest diagnostic se blochează.
Notează cele trei fapte pentru fluxul pe care îl testezi înainte de a începe. Interfață, rută și regulă de traducere sunt suficiente pentru a prezice rezultatul, iar tocmai predicția face o surpriză informativă. Dacă nu poți completa unul dintre cele trei, acea lacună este constatarea reală.
Urmărește un binding request de-a lungul căii
Un binding request STUN cere unui server să raporteze adresa de transport sursă pe care a observat-o. Răspunsul descrie calea pe care a luat-o cererea, nu un inventar al interfețelor de pe mașina client. Două cereri pe două căi vor raporta cinstit două adrese diferite.
| 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 |
Citește tabelul ca un set de condiții, nu ca un meniu de furnizori. Rândul din mijloc cere ca reflectorul privat să fie accesibil sub rutarea și politica de parteneri proprii tunelului; este un fapt de configurare pe care îl poți verifica, nu ceva ce implică un nivel de cont. Rândul de jos este de obicei cel care contează pentru politică, pentru că acel trafic trebuia să rămână în tunel. Între ele se află cazul obișnuit, în care ieșirea traduce și reflectorul vede doar ieșirea.
Candidații host și candidații reflexivi de server provin din mecanisme diferite, așa că o listă de candidați nu spune ce cale au folosit efectiv media. Citește perechea selectată, nu jurnalul de colectare, când vrei să știi unde a mers sesiunea.
Ce nu este adresa de tunel a routerului
O adresă de tunel atribuită routerului aparține unei interfețe de pe router. Un browser pe un host din LAN are propriile adrese de interfață și nicio vedere directă asupra interfeței de tunel a routerului. Dacă le tratezi ca interschimbabile, obții răspunsuri sigure și greșite despre ce poate afla o pagină web.
Forwardarea este ce le leagă. Cererea traversează routerul ca trafic rutat, iar sursa ei este ceea ce au produs rutarea și traducerea.
Dacă calea tunelului păstrează sursa LAN, un reflector privat poate afla acea adresă LAN, ceea ce este o divulgare reală și diferită de adresa de tunel. Dacă calea traduce spre adresa de tunel, reflectorul află în schimb adresa de tunel. Ambele rezultate sunt compatibile cu același browser pe același host, de aceea o observație trebuie legată de un flux anume. Întreabă kernelul ce sursă ar folosi înainte de a da vina pe aplicație.
Divulgare versus ocolire: două constatări, două reparații
O adresă de tunel reflectată divulgă un identificator intern pe o cale pe care ai permis-o. O cerere directă prin WAN ocolește o cale pe care voiai să o impui. Prima este o chestiune de informare, a doua de aplicare a regulilor, și se corectează în locuri diferite. Dacă le topi într-un singur cuvânt, obții o reparație care nu rezolvă niciuna.
WebRTC face asta mai vizibil fără a o face greșită, fiindcă a colecta un candidat nu este același lucru cu a-l selecta.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showRulează interogarea de rută pentru fiecare adresă de reflector pe care o permiți, cu sursa pe care te aștepți să o poarte acel flux, apoi rulează-o din nou pentru intervalele excluse ca să vezi ce selectează varianta de rezervă. Compară cele două răspunsuri cu politica pe care ai notat-o. Când diferă într-un mod pe care nu l-ai intenționat, ai găsit punctul de reparație fără să fie nevoie să interpretezi deloc lista de candidați a unui browser.