Kodėl viešosios prieigos taškas peradresuoja DNS prieš prisijungiant VPN?
Viešosios prieigos taškas perrašo užklausas savo tinkle, o prieglobos pavadinimo galutinis taškas išsprendžiamas dar prieš atsirandant bet kokiam tuneliui. Atsekite, kuris sprendėjas atsakė į kiekvieną užklausą.
Prisijungimas prie viešbučio tinklo prieš jus pastato du DNS sprendimus skirtingais momentais: užklausas, kurias įrenginys atlieka prisijungdamas, ir užklausas, atliekamas po to, kai tunelis pakyla. Prieigos taškas gali paveikti pirmąsias per savo valdomą tinklą. Antrosios priklauso nuo paties kliento politikos, kurią reikia tirti atskirai.
Peržiūrėkite ryšį iš eilės, nuo pirmosios DHCP nuomos iki užklausos, kuri išsprendė privatų vardą. Tada du gedimai, kurie pagalbos biliete atrodo vienodi, aiškiai atsiskiria: vienas įvyko prieš tunelį, kitas — jo viduje.
Ką prieigos taškas gali ir ko negali liesti
Prieigos tinklas DHCP būdu išduoda sprendėjo adresą ir gali perimti 53 prievadą to adreso link. To pakanka atsakyti į kiekvieną neapsaugotą užklausą portalo adresu ar blokavimo puslapiu. To taip pat pakanka sugadinti VPN klientą, kurio galutinis taškas parašytas kaip prieglobos pavadinimas.
Ko prieigos taškas negali, tai skaityti ar perrašyti užklausos, kai ji keliauja jau sukurto tunelio viduje, darant prielaidą, kad tunelis ją tikrai neša. Perėmimas priklauso nuo to, ar matomas klausimas atviru tekstu.
Užklausos vis tiek palieka tunelį dėl priežasčių, nesusijusių su prieigos tašku: naršyklės saugaus DNS nustatymas, split-DNS taisyklė, paliekanti įmonės priesagą vietiniame sprendėje, arba klientas, sukonfigūruotas išskirti DNS iš tunelio. Kiekviena jų yra kliento pusės pasirinkimas, ir kiekviena iš išorės atrodo kaip prieigos taško trukdymas.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Pradinė užklausa įvyksta dar prieš atsirandant tuneliui
Klientas, kuriam duotas prieglobos pavadinimas, pirmiausia turi jį išspręsti, ir tuo metu joks tunelis neapsaugo užklausos. Jei prieigos taškas atsako portalo adresu, derybos nepavyksta arba pakimba. Jei jis neatsako niekuo, klientas praneša apie vardo klaidą ir tunelis niekada neprasideda. Bet kuris iš dviejų rezultatų paaiškina tuščią tunelio žurnalą, kuris kitaip atrodo nekaltas.
Operacinės sistemos taip pat atlieka savo ryšio patikras ir portalo aptikimą, aprašytus RFC 8910 ir RFC 8952, ir tie prašymai išeina dar prieš pakylant bet kuriam VPN. Matyti juos tarpinio serverio žurnale yra laukiamas elgesys, o ne nutekėjimo įrodymas.
Praktinis sprendimas yra duoti klientui galutinį tašką, kuriam nereikia užklausos. Kai tai neįmanoma, pirmiausia užbaikite prisijungimą, o tada prisijunkite.
Išsiaiškinkite, kuris sprendėjas atsakė
Klauskite sistemos, o ne naršyklės, ir paleiskite užklausą du kartus: vieną kartą per bet kurį sprendėją, kurį įrenginys dabar naudoja, vieną kartą į fiksuotą adresą.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Pirmosios komandos atsakymas, besiskiriantis nuo trečiosios, pasako, kad vietinis sprendėjas grąžina ką nors kita, ką būtent ir daro peradresuojantis prieigos taškas. Trečiosios gedimas kartu su pirmosios sėkme nurodo portalą: vietinis sprendėjas aptarnavo prisijungimo adresą, o išeinantis 53 prievadas buvo numestas. Abiejų laikas pasibaigia, o tai reiškia, kad tinklas atmeta DNS, kol autentifikavimas nebaigtas.
Pakartokite prisijungę ir palyginkite. Podėlyje laikomas atsakymas išgyvena perėjimą, todėl išvalykite podėlį arba antram stebėjimui užklauskite naują vardą.
Laikykite vėlesnes užklausas numatytame kelyje
Viso tunelio profilis, kuris taip pat pagauna DNS, yra paprasčiausia tvarka: kiekviena kiekvienos programos užklausa eina į sprendėją, kurį stumia tunelis, o vietinis tinklas mato tik šifruotą srautą. Įrodykite tai prisijungę išsprendę vidinį ir viešą vardą, o paskui palyginę abu atsakymus su tuo, ką tunelio sprendėjas grąžina pats.
Split-DNS reikia sąmoningai parašyto domenų sąrašo: įmonės priesagos per tunelį, visa kita vietoje, ir jokio persidengimo tarp jų.
Naršyklės saugus DNS yra už šios politikos ribų, todėl jei jis turi būti išjungtas, kad profilis elgtųsi nuspėjamai, išjunkite jį tam profiliui, o ne mašinai. Darykite tai naršyklės nustatymuose, o ne redaguodami sistemos sprendėją, kad pakeitimas būtų matomas kitą kartą. Užrašykite atsakymą, sprendėją ir ryšio etapą vienoje eilutėje kiekvienam testui. Ataskaita, kad DNS nepavyko viešbučio Wi-Fi, aprašo simptomą, turintį bent tris skirtingas priežastis.