Čo odhalí odpoveď STUN, keď VPN beží na routeri
Adresa tunela na routeri nie je lokálna adresa prehliadača. Sledujte, ako sa každá požiadavka smeruje a prekladá, skôr než začnete čítať, čo hlási reflektor.
Keď tunel žije na routeri, počítač, na ktorom beží prehliadač, nemá vôbec žiadne rozhranie tunela. Opýtajte sa toho počítača na lokálne adresy a dostanete súkromnú adresu LAN a slučku, nič, čo by pripomínalo adresu VPN. Napriek tomu STUN server na druhej strane môže stále hlásiť niečo zmysluplné o ceste, a to, čo hlási, závisí úplne od toho, ako bola tá konkrétna požiadavka smerovaná a preložená.
Práve na tejto časti sa oplatí spomaliť. „Prehliadač nevlastní adresu VPN“ odpovedá na otázku o rozhraniach, zatiaľ čo odrazená adresa je odpoveďou o ceste cez preklad. Zmiešanie oboch vedie k sebavedomým záverom o odhalení, ktoré dôkazy nepodporujú.
Dve zariadenia, dve sady rozhraní
V usporiadaní s routerom tunel končí na routeri a klient LAN posiela bežnú premávku na svoju predvolenú bránu. Zoznam rozhraní klienta zostáva krátky: jedna súkromná adresa, možno druhá pre inú sieť, a slučka. Riziko nie je v tom, že by jedna z nich bola náhodou adresou tunela; riziko je v tom, že požiadavka vychádza cestou, ktorú ste si nezvolili.
Opýtajte sa klienta akú cestu by konkrétny cieľ zaujal namiesto otázky, aké rozhrania existujú. Odpoveď vymenuje bránu a zdrojovú adresu, ktorú by jadro použilo, a to je už informatívnejšie ako akýkoľvek zoznam adries.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentačné rozsahy sú dobré testovacie ciele, pretože sa nikdy nepreložia na skutočnú službu. Porovnajte, čo hovorí klient, s tým, čo hovorí router, a každý nesúlad berte ako dôkaz, že smerovanie podľa zásad, pravidlo rozdeleného tunela alebo druhá predvolená trasa robí niečo, čo ste nezohľadnili.
Čo smie odpoveď Binding povedať
RFC 8489 definuje požiadavku a odpoveď Binding, pri ktorých server hlási zdrojovú transportnú adresu, ktorú pri tejto požiadavke pozoroval. Je to tvrdenie o jednej pätici v jednom okamihu, nie súpis rozhraní klienta. Všetko zaujímavé sa preto odohráva medzi klientom a bodom pozorovania.
Túto medzeru vypĺňa smerovanie a preklad. Router, ktorý na odchádzajúcej premávke robí zdrojový NAT, nahradí súkromný zdroj klienta vlastnou adresou na odchádzajúcom rozhraní. Ak je tým rozhraním tunel, reflektor vidí adresu tunela. Ak bol paket z tunela vylúčený, reflektor vidí to, čo vytvoril preklad WAN. Ten istý klient, ten istý reflektor, iná odpoveď.
Tri prípady, ktoré vyzerajú rovnako a nie sú
Užitočný rozdiel nie je verejné proti súkromnému, ale to, ktorý vynucovací bod paket spracoval. Prejdite prípady s otvorenými vlastnými tabuľkami routera, pretože jeden prehliadač môže vytvoriť všetky tri podľa pravidla, ktoré ste zabudli, že ste napísali.
| 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 |
Len druhý prípad porušuje požiadavku, aby určitá premávka nikdy nevychádzala priamo, a len prvý a tretí prezrádzajú identifikátor zo strany tunela. Žiadny z troch riadkov nie je tvrdením o správaní konkrétneho poskytovateľa: či je súkromný reflektor vôbec dostupný, závisí od smerovania, povolených IP adries druhej strany a politiky firewallu na oboch koncoch.
Vlastniť účet u toho istého poskytovateľa nič z toho nepreukazuje. Oplatí sa pamätať aj to, že smerovaná požiadavka si môže ponechať zdroj LAN klienta, ak ju nič neprekladá, takže pole zdroja treba vysledovať, nie odhadnúť z diagramu topológie.
Zbieranie nie je výber
WebRTC zhromažďuje kandidátske adresy na vyskúšanie, a kandidát, ktorý sa objaví v diagnostickom zozname, nemusí nikdy prenášať médiá. Čítať zoznam ako „toto sa druhá strana naučila“ preceňuje dôkazy. Vybraná dvojica je to, čo reláciu skutočne prenášalo, a nachádza sa v inom poli.
Kontrola výstupu cez HTTPS odpovedá na ďalšiu otázku: zdrojovú adresu, ktorú webový server pri tejto požiadavke videl. Je to užitočná krížová kontrola práve preto, že používa iný protokol a často iný cieľ než UDP reflektor, a nesúlad medzi nimi zvyčajne ukazuje na pravidlo smerovania, nie na chybu.
Rozhodnite o politike, potom čítajte odpoveď
Zapíšte zámer pred testovaním: ktorá premávka musí používať tunel, ktorá môže vychádzať priamo, ktoré rodiny adries sú v rozsahu a čo sa má stať, keď je tunel mimo prevádzky. Bez tejto základnej línie je každé pozorovanie nejednoznačné, pretože nedokážete oddeliť únik od cesty, ktorú ste vedome povolili.
Potom sa pýtajte po jednej otázke. Akú cestu tento cieľ zaujme. Akú adresu hlási tento reflektor. Ktorú kandidátsku dvojicu relácia zvolila. Odpovede držte vedľa politiky a datujte ich, pretože aktualizácia firmvéru môže zmeniť predvolené správanie spôsobom, ktorý ticho zneplatní minuloročný záver.
Router je stále silný vynucovací bod, pretože vidí premávku, ktorú klient nemôže obísť bez prekonfigurovania seba samého. Nie je to sľub, že každé pole v každom aplikačnom protokole nič neprezradí, a nie je to náhrada za zapísanie ciest, ktoré ste sa rozhodli povoliť.