Ce dezvăluie un răspuns STUN când VPN-ul rulează pe router

Când tunelul locuiește pe router, mașina care rulează browserul nu are deloc interfață de tunel. Cereți acelei mașini adresele locale și obțineți o adresă LAN privată și una de buclă, nimic care să semene cu o adresă VPN. Totuși, un server STUN din partea cealaltă poate raporta în continuare ceva semnificativ despre cale, iar ce raportează depinde în întregime de modul în care acea cerere anume a fost rutată și tradusă.

Aceasta este partea care merită încetinit. „Browserul nu deține adresa VPN“ răspunde la o întrebare despre interfețe, în timp ce o adresă reflectată este un răspuns despre o cale prin traducere. Confundarea celor două produce concluzii încrezătoare despre dezvăluire pe care dovezile nu le susțin.

Două dispozitive, două seturi de interfețe

Într-o configurație bazată pe router, tunelul se termină pe router, iar clientul LAN trimite trafic obișnuit către gateway-ul său implicit. Lista de interfețe a clientului rămâne scurtă: o adresă privată, poate una secundară pentru altă rețea, și bucla. Riscul nu este că una dintre ele este din întâmplare adresa tunelului; riscul este că cererea iese pe o cale pe care nu ați ales-o.

Întrebați clientul ce cale ar lua o destinație anume în loc să întrebați ce interfețe există. Răspunsul numește un gateway și adresa sursă pe care ar folosi-o nucleul, iar asta este deja mai informativ decât orice inventar de adrese.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Intervalele de documentare sunt ținte bune de test pentru că nu se rezolvă niciodată într-un serviciu real. Comparați ce spune clientul cu ce spune routerul și tratați orice nepotrivire ca dovadă că rutarea pe politici, o regulă de tunel divizat sau o a doua rută implicită face ceva ce nu ați luat în calcul.

Ce are voie să spună un răspuns Binding

RFC 8489 definește cererea și răspunsul Binding, în care serverul raportează adresa de transport sursă observată pentru acea cerere. Este o afirmație despre un singur cvintuplu la un moment dat, nu un recensământ al interfețelor clientului. Prin urmare tot ce este interesant se întâmplă între client și punctul de observare.

Acest gol este umplut de rutare și traducere. Un router care face NAT sursă pe traficul de ieșire înlocuiește sursa privată a clientului cu propria adresă pe interfața de ieșire. Dacă acea interfață este tunelul, reflectorul vede adresa tunelului. Dacă pachetul a fost exclus din tunel, reflectorul vede ce a produs traducerea WAN. Același client, același reflector, răspuns diferit.

Trei cazuri care seamănă și nu sunt

Distincția utilă nu este public versus privat, ci care punct de aplicare a tratat pachetul. Parcurgeți cazurile cu tabelele routerului deschise, pentru că un singur browser poate produce toate trei în funcție de o regulă pe care ați uitat că ați scris-o.

Doar al doilea caz încalcă cerința ca anumit trafic să nu iasă niciodată direct, și doar primul și al treilea dezvăluie un identificator din partea tunelului. Niciunul dintre cele trei rânduri nu este o afirmație despre comportamentul unui furnizor anume: dacă un reflector privat este accesibil depinde de rutare, de adresele IP permise ale celeilalte părți și de politica firewall-ului la ambele capete.

Deținerea unui cont la același furnizor nu stabilește nimic din toate acestea. Merită reținut și că o cerere rutată poate păstra sursa LAN a clientului dacă nimic nu o traduce, așa că câmpul sursă trebuie urmărit, nu presupus din diagrama topologiei.

Colectarea nu este selecție

WebRTC colectează adrese candidate pentru încercare, iar un candidat care apare într-o listă de diagnostic poate să nu transporte niciodată media. Citirea listei ca „iată ce a învățat cealaltă parte“ supraestimează dovada. Perechea selectată este cea care a transportat efectiv sesiunea și se află într-un alt câmp.

Un verificator de ieșire HTTPS răspunde la încă o întrebare: adresa sursă pe care un server web a văzut-o pentru acea cerere. Este o verificare încrucișată utilă tocmai pentru că folosește alt protocol și adesea altă destinație decât un reflector UDP, iar dezacordul dintre cele două indică de obicei o regulă de rutare, nu un defect.

Decideți politica, apoi citiți răspunsul

Scrieți intenția înainte de testare: ce trafic trebuie să folosească tunelul, care poate ieși direct, ce familii de adrese sunt în scop și ce ar trebui să se întâmple când tunelul este căzut. Fără acea linie de bază fiecare observație este ambiguă, pentru că nu puteți separa o scurgere de o cale pe care ați permis-o deliberat.

Apoi puneți o singură întrebare o dată. Ce cale ia această destinație. Ce adresă raportează acest reflector. Ce pereche candidată a selectat sesiunea. Păstrați răspunsurile lângă politică și datați-le, pentru că o actualizare de firmware poate schimba comportamentul implicit în feluri care invalidează în tăcere concluzia de anul trecut.

Routerul rămâne un punct de aplicare solid, pentru că vede trafic pe care un client nu îl poate ocoli fără a se reconfigura pe sine. Nu este o promisiune că fiecare câmp din fiecare protocol de aplicație nu dezvăluie nimic și nu înlocuiește scrierea căilor pe care ați ales să le permiteți.