Kāpēc piekļuves punkts pārvirza DNS pirms VPN savienojuma?
Piekļuves punkts pārraksta vaicājumus savā tīklā, un resursdatora nosaukuma galapunkts tiek atrisināts pirms jebkura tuneļa pastāvēšanas. Izsekojiet, kurš atrisinātājs atbildēja uz katru vaicājumu.
Pievienošanās viesnīcas tīklam jūsu priekšā liek divus DNS lēmumus dažādos brīžos: vaicājumus, ko ierīce veic pieteikšanās laikā, un vaicājumus, ko veic pēc tuneļa uzstādīšanas. Piekļuves punkts var ietekmēt pirmos, izmantojot tīklu, ko tas kontrolē. Otrie ir atkarīgi no paša klienta politikas, kas ir atsevišķi pārbaudāma lieta.
Izstaigājiet savienojumu secībā, no pirmās DHCP nomāšanas līdz vaicājumam, kas atrisināja privātu nosaukumu. Tad divi bojājumi, kas atbalsta biļetenā izskatās vienādi, skaidri atdalās: viens notika pirms tuneļa, otrs — tā iekšienē.
Ko piekļuves punkts var un ko nevar aizskart
Piekļuves tīkls DHCP izsniedz atrisinātāja adresi un var pārtvert portu 53 uz šo adresi. Ar to pietiek, lai atbildētu uz katru neaizsargāto vaicājumu ar portāla adresi vai bloķēšanas lapu. Ar to arī pietiek, lai salauztu VPN klientu, kura galapunkts ir rakstīts kā resursdatora nosaukums.
Ko piekļuves punkts nevar, ir lasīt vai pārrakstīt vaicājumu, kad tas jau ceļo izveidotā tunelī, pieņemot, ka tunelis to tiešām nes. Pārtveršana ir atkarīga no jautājuma redzēšanas vienkāršā tekstā.
Vaicājumi tomēr atstāj tuneli tādu iemeslu dēļ, kas nav saistīti ar piekļuves punktu: pārlūka drošā DNS iestatījums, split-DNS noteikums, kas uzņēmuma piedēkli patur vietējā atrisinātājā, vai klients, kas konfigurēts izslēgt DNS no tuneļa. Katrs no tiem ir klienta puses izvēle, un katrs no ārpuses izskatās kā piekļuves punkta iejaukšanās.
| 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 |
Sākotnējais vaicājums notiek pirms tuneļa pastāvēšanas
Klientam, kuram dots resursdatora nosaukums, tas vispirms jāatrisina, un tajā brīdī neviens tunelis neaizsargā vaicājumu. Ja piekļuves punkts atbild ar portāla adresi, sarunas izgāžas vai iestājas. Ja tas neatbild ne ar ko, klients ziņo par nosaukuma kļūdu un tunelis nekad nesākas. Jebkurš no abiem rezultātiem izskaidro tukšu tuneļa žurnālu, kas citādi izskatās nevainīgs.
Operētājsistēmas veic arī savas savienojamības pārbaudes un portāla atklāšanu, kas aprakstītas RFC 8910 un RFC 8952, un šie pieprasījumi iziet pirms jebkura VPN uzstādīšanas. Redzēt tos starpniekservera žurnālā ir gaidīta uzvedība, nevis noplūdes pierādījums.
Praktiskais risinājums ir dot klientam galapunktu, kuram nav vajadzīgs vaicājums. Kad tas nav iespējams, vispirms pabeidziet pieteikšanos un pēc tam savienojieties.
Noskaidrojiet, kurš atrisinātājs atbildēja
Jautājiet sistēmai, nevis pārlūkam, un izpildiet vaicājumu divreiz: vienreiz caur jebkuru atrisinātāju, ko ierīce pašlaik izmanto, un vienreiz pret fiksētu adresi.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Pirmās komandas atbilde, kas atšķiras no trešās, jums saka, ka vietējais atrisinātājs atgriež kaut ko citu, un tieši to dara pārvirzošs piekļuves punkts. Trešās neveiksme kopā ar pirmās panākumu norāda uz portālu: vietējais atrisinātājs pasniedza pieteikšanās adresi, kamēr izejošais ports 53 tika nomests. Abu gadījumā taimauts nozīmē, ka tīkls atmet DNS, līdz autentifikācija ir pabeigta.
Atkārtojiet pēc savienošanās un salīdziniet. Kešatmiņā saglabātā atbilde pārdzīvo pāreju, tāpēc iztīriet kešatmiņu vai otrajam novērojumam vaicājiet jaunu nosaukumu.
Turiet vēlākos vaicājumus paredzētajā ceļā
Pilna tuneļa profils, kas uztver arī DNS, ir vienkāršākais izkārtojums: katrs katras programmas vaicājums iet uz atrisinātāju, ko tunelis virza, un vietējais tīkls redz tikai šifrētu datplūsmu. Pierādiet to, pēc savienošanās atrisinot iekšēju un publisku nosaukumu, un pēc tam salīdzinot abas atbildes ar to, ko tuneļa atrisinātājs atgriež pats.
Split-DNS ir vajadzīgs apzināti rakstīts domēnu saraksts: uzņēmuma piedēkļi caur tuneli, viss pārējais lokāli, un bez pārklāšanās starp abiem.
Pārlūka drošais DNS atrodas ārpus šīs politikas, tāpēc, ja tam jābūt izslēgtam, lai profils uzvestos paredzami, izslēdziet to šim profilam, nevis mašīnai. Dariet to pārlūka iestatījumos, nevis rediģējot sistēmas atrisinātāju, lai izmaiņas būtu redzamas nākamreiz. Pierakstiet atbildi, atrisinātāju un savienojuma posmu vienā rindā katram testam. Ziņojums, ka DNS neizdevās viesnīcas Wi-Fi tīklā, apraksta simptomu ar vismaz trim dažādiem cēloņiem.