DNS netiek atrisināts, ja VPN kill switch bloķē 53. portu
Kill switch var apzināti bloķēt DNS. Salīdziniet atrisināšanu tikai tunelī ar izņēmumu vietējam resolverim un pēc tam noskaidrojiet, kura slāne patiešām neizdevās.
Kad kill switch nomet tuneli, tas paņem līdzi arī DNS ceļu, un palikušais resolveris reti ir tas, ko gaidāt. Divi risinājumi šo brīdi uztver ļoti atšķirīgi: bloķēt katru DNS paketi, kas neatrodas tunelī, vaiatstāt vienu resolveri kā izņēmumu. Abi ir aizstāvami. Pārlūka cilnē simptomi izskatās gandrīz vienādi, tāpēc pirmais uzdevums ir noskaidrot, kuru risinājumu jūs patiešām ieviesāt.
Es turu šo atšķirību acu priekšā, jo labojums abos gadījumos ir pretējs. Vienam risinājumam vajag plašāku izņēmumu, otram šaurāku. Minēšana jums maksā vai nu privātumu, vai pusi dienas.
Divi DNS risinājumi vienam un tam pašam pārtraukumam
Risinājums A uzskata resolveri par vēl vienu pakalpojumu aiz tuneļa. Ugunsmūra noteikumi atļauj UDP un TCP 53 tikai tuneļa saskarnē, un klientam dotā adrese ir resolveris tuneļa iekšienē. Kad tunelis nokrīt, meklēšana apstājas, un tas ir paredzētais rezultāts, nevis defekts.
Risinājums B tur resolveri sasniedzamu vietējā tīklā, parasti maršrutētāju adresē 192.168.1.1 vai operētājsistēmas stub adresē 127.0.0.53, pamatojoties uz to, ka vārdu atrisināšanai nevajadzētu mirt kopā ar tuneli. Tas ir ērti mājas LAN, kur maršrutētājs atrisina visai mājai. Viesnīcas vai lidostas Wi-Fi tas pats izņēmums rāda uz kāda cita serveri, un katrs ievadītais vārds tiek atklāts, lai gan jūsu tīmekļa trafiks paliek bloķēts.
Robeža ir tas, kam pieder resolveris. Ja uzticaties vietējam, izņēmums ir maza un godīga bedre. Ja ne, risinājums tikai caur tuneli ir vienīgais, kas noturas, un cena ir tā, ka nokritis tunelis paņem līdzi visus vārdus.
Kāpēc paša VPN klienta meklēšana joprojām darbojas
Klientam ir jāatrisina vārtejas resursdatora vārds pirms tuneļa pastāvēšanas, tāpēc stingram bloķējumam nevajadzētu aptvert klienta ielādes ceļu. Lielākā daļa klientu vai nu kešo galapunkta adresi, vai nodrošina dokumentētu ielādes izņēmumu tieši šim vienam resursdatoram. Ja jūsu noteikumu kopa bloķē šo meklēšanu, tunelis nekad neatgriezīsies un žurnāli rādīs klientu, kas nevar sasniegt savu serveri; tas ir politikas, nevis DNS defekts.
Sadalītais DNS ir otra vieta, kur tas parādās. Klients iegrūž iekšējo zonu privātā resolverī un visu pārējo atstāj sistēmas resolverim. Pēc nokrišanas publiskie vārdi vēl var atrisināties, kamēr iekšējie beidzas ar taimautu, jo privātajai zonai vairs nav maršruta. Lietotājam tas ir "VPN salauza internetu"; resolvera žurnālam tas ir vaicājums, kas tā arī neatnāca.
Zem systemd-resolved sadalījumu redzat tieši.resolvectl statusuzskaita DNS serverus katram savienojumam un maršrutēšanas domēnus, un pēc tuneļa nokrišanas iekšējais domēns joprojām rāda uz serveri savienojumā, kura vairs nav. Stub adresē 127.0.0.53 joprojām pieņem vaicājumu, pēc tam gaida augšupēju, kas neatbildēs, un tāpēc kļūme aizņem sekundes, nevis atgriežas uzreiz.
Šifrētais DNS neapiet pakešu filtru
DNS over HTTPS un DNS over TLS ceļo pa 443 un 853, tāpēc noteikums, kas bloķē 53. portu, par tiem nav neko teicis. Bloķēt "DNS" pēc porta ir politika par portu, nevis par vārdu atrisināšanu. Ja jūsu kill switch bloķē visu trafiku ārpus tuneļa, DoH tiek segts nejauši. Ja atvēlējāt atļauju captive portal vai publiskam resolverim, tas netiek segts.
Klienta puses vadīklas ir lētākā svira. Firefox atsakās no sava DoH resolvera, kad kanārijputna vārdsuse-application-dns.netneatrisinās, tāpēc pārvaldītie tīkli publicē šo domēnu kā NXDOMAIN; uzņēmuma politika to var arī nofiksēt izslēgtu. Android Private DNS un Chrome drošajam DNS ir savi slēdži un savas noklusējuma vērtības. Tos izslēgt ir uzticamāk nekā dzīties pakaļ resolveru adresēm, jo adrešu saraksts mainās, bet jūsu noteikumu kopa ne.
Ir šī versija, kas nemaz nav par noplūdēm. Lietotnei ar fiksētu resolveri joprojām vajag tīkla ceļu, lai to sasniegtu. Šifrēšana maina to, kas var nolasīt vaicājumu, nevis to, vai pakete var atstāt mašīnu, tāpēc visas ierīces bloķējums pārspēj iestatījumu, tam nepieskaroties.
Saskaņojiet simptomu ar slāni
Lielākā daļa ziņojumu pienāk kā viens teikums, un šis teikums parasti jau nosauc slāni. Zemāk esošā tabula ir tas, ko es pārskatu pirms pieskaros noteikumam; mērķis ir izlemt, vai vaicājums tika bloķēts, novirzīts nepareizi vai vispār netika nosūtīts.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Pirmās divas rindas ir tās, ko cilvēki diagnosticē nepareizi. Klusa nokrišana un atteikums pārlūkā izskatās vienādi kā "DNS ir salūzis", bet tikai viens no tiem nozīmē, ka jūsu kill switch dara savu darbu. Atteikums nozīmē, ka kaut kas atbildēja, tāpēc bloķējums nav tur, kur jūs domājat.
Atjaunojiet resolvera politiku un pēc tam pierādiet to
Labojiet risinājumu, nevis simptomu. Atrisināšanai tikai tunelī atļaujiet 53 tuneļa saskarnē, iegrūdiet iekšējo resolveri kopā ar tuneļa konfigurāciju un atstājiet fizisko savienojumu bez jebkādas DNS atļaujas. wg-quick gadījumā resolveri saskarnes konfigurācijā ieraksta rindaDNS =, tāpēc tunelis, kas to izlaiž, atstāj veco resolveri vietā, un katrs vaicājums iet nepareizajā ceļā.wg-quick rokasgrāmatadokumentē šo uzvedību katrai platformai.
Pēc tam pārbaudiet šādā secībā. Linuxresolvectl statusrāda aktīvo savienojumu,dig +short example.compārbauda publisku vārdu,dig @10.8.0.1 internal.example.compārbauda privāto, unsudo tcpdump -ni any port 53rāda, kuru saskarni paketes izmanto, kamēr izpildāt abus. WindowsGet-DnsClientServerAddress -AddressFamily IPv4unResolve-DnsName example.comdod tos pašus divus faktus: kas ir konfigurēts un kas atbild.
Pabeidziet ar negatīvo testu. Atvienojiet tuneli, pārliecinieties, ka svaigs publiskais vārds neizdodas, pārliecinieties, ka privātais vārds neizdodas, unpārliecinieties, ka neviena 53. porta pakete nav atstājusi fizisko adapteri. Bloķējums, kas noturas tikai kešotām atbildēm, nenoturas nemaz.
Kontrolsaraksts pirms biļetes aizvēršanas:
- Pārtraukuma laikā izmantotais resolveris ir tas, ko politika paredz.
- Klienta paša galapunkta meklēšana joprojām ir atļauta, ar kešu vai izņēmumu.
- DoH un DoT vai nu ir bloķējuma segti, vai politikas izslēgti.
- Privātās zonas neizdodas aizvērti, nevis atvērti, tiklīdz tunelis ir prom.