DNS ei ratkea, kun VPN:n kill switch estää portin 53
Kill switch voi estää DNS:n tahallaan. Vertaa ratkaisua vain tunnelin sisällä paikallisen resolverin poikkeukseen ja selvitä sitten, mikä kerros todella petti.
Kun kill switch pudottaa tunnelin, se vie mukanaan myös DNS-reitin, ja jäljelle jäävä resolveri on harvoin se, jota odotat. Kaksi mallia käsittelee tuon hetken hyvin eri tavoin: estä jokainen DNS-paketti, joka ei ole tunnelin sisällä, taijätä yksi resolveri poikkeuksena pystyyn. Molemmat ovat perusteltavissa. Selaimen välilehdeltä oireet näyttävät lähes identtisiltä, joten ensimmäinen tehtävä on selvittää, minkä mallin todella otit käyttöön.
Pidän tuon eron mielessäni, koska korjaus on kummassakin tapauksessa päinvastainen. Toinen malli tarvitsee laajemman poikkeuksen, toinen kapeamman. Arvaaminen maksaa joko yksityisyyden tai iltapäivän.
Kaksi DNS-mallia samaan katkokseen
Malli A kohtelee resolveria kuin mitä tahansa muuta palvelua tunnelin takana. Palomuurisäännöt sallivat UDP:n ja TCP:n portin 53 vain tunnelin liitännässä, ja asiakkaalle annettava osoite on resolveri tunnelin sisällä. Kun tunneli kaatuu, haut pysähtyvät, ja se on tarkoitettu tulos, ei vika.
Malli B pitää resolverin tavoitettavissa paikallisverkossa, yleensä reitittimessä osoitteessa 192.168.1.1 tai käyttöjärjestelmän stubissa osoitteessa 127.0.0.53, sillä perusteella, ettei nimien ratkaisun pitäisi kuolla tunnelin mukana. Se on kätevää kotiverkossa, jossa reititin ratkaisee koko talolle. Hotellin tai lentokentän Wi-Fi-verkossa sama poikkeus osoittaa jonkun toisen palvelimelle, ja jokainen kirjoittamasi nimi paljastuu, vaikka verkkoliikenteesi pysyy estettynä.
Raja on siinä, kuka omistaa resolverin. Jos luotat paikalliseen, poikkeus on pieni ja rehellinen reikä. Jos et, vain tunnelin kautta toimiva malli pitää, ja hintana on, että kaatunut tunneli vie kaikki nimet mukanaan.
Miksi VPN-asiakkaan oma haku toimii yhä
Asiakkaan on ratkaistava yhdyskäytävän isäntänimi ennen kuin tunneli on olemassa, joten tiukka esto ei saa kattaa asiakkaan käynnistyspolkua. Useimmat asiakkaat joko välimuistittavat päätepisteen osoitteen tai toimittavat dokumentoidun käynnistyspoikkeuksen juuri sille yhdelle isännälle. Jos sääntösi estävät tuon haun, tunneli ei koskaan palaa ja lokit näyttävät asiakkaan, joka ei tavoita omaa palvelintaan – se on käytäntövika, ei DNS-vika.
Jaettu DNS on toinen paikka, jossa tämä näkyy. Asiakas työntää sisäisen vyöhykkeen yksityiselle resolverille ja jättää kaiken muun järjestelmän resolverille. Pudotuksen jälkeen julkiset nimet voivat yhä ratketa, kun sisäiset aikakatkaistaan, koska yksityisellä vyöhykkeellä ei ole enää reittiä. Käyttäjälle se on "VPN rikkoi internetin"; resolverin lokille se on kysely, joka ei koskaan saapunut.
systemd-resolvedin alla jaon näkee suoraan.resolvectl statusluettelee linkkikohtaiset DNS-palvelimet ja reititysdomainit, ja tunnelin pudottua sisäinen domain osoittaa yhä palvelimelle linkissä, jota ei enää ole. Osoitteen 127.0.0.53 stubi ottaa kyselyn yhä vastaan ja odottaa sitten ylävirtaa, joka ei vastaa, ja siksi vika kestää sekunteja sen sijaan että palaisi heti.
Salattu DNS ei kierrä pakettisuodatinta
DNS over HTTPS ja DNS over TLS kulkevat porteilla 443 ja 853, joten portin 53 estävä sääntö ei ole sanonut niistä mitään. "DNS:n" estäminen portin perusteella on porttia koskeva käytäntö, ei nimien ratkaisua koskeva. Jos kill switch estää kaiken liikenteen tunnelin ulkopuolella, DoH tulee katetuksi vahingossa. Jos olet varannut poikkeuksen captive-portaalille tai julkiselle resolverille, se ei tule katetuksi.
Asiakaspuolen säätimet ovat halvempi vipu. Firefox luopuu DoH-resolveristaan, kun kanarialinnun nimiuse-application-dns.netei ratkea, ja siksi hallitut verkot julkaisevat kyseisen domainin NXDOMAINina; yrityskäytäntö voi myös kiinnittää sen pois päältä. Android Private DNS:llä ja Chromen suojatulla DNS:llä on omat kytkimensä ja omat oletuksensa. Niiden sammuttaminen on luotettavampaa kuin resolverien osoitteiden perässä juokseminen, koska osoitelista muuttuu eikä sääntösi muutu.
Tästä on versio, joka ei kerro vuodoista lainkaan. Kiinnitetyn resolverin sovellus tarvitsee silti verkkoreitin päästäkseen siihen. Salaus muuttaa sitä, kuka voi lukea kyselyn, ei sitä, voiko paketti lähteä koneesta, joten koko laitteen esto kukistaa asetuksen koskematta siihen.
Sovita oire kerrokseen
Useimmat ilmoitukset tulevat yhtenä lauseena, ja se lause yleensä nimeää kerroksen jo. Alla oleva taulukko on se, minkä käyn läpi ennen kuin kosken sääntöön; tarkoitus on päättää, estettiinkö kysely, ohjattiinko se väärin vai jäikö se lähettämättä.
| 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 |
Kaksi ensimmäistä riviä ovat ne, jotka ihmiset diagnosoivat väärin. Hiljainen pudotus ja hylkäys näyttävät selaimessa molemmat siltä, että "DNS on rikki", mutta vain toinen niistä tarkoittaa, että kill switch tekee työnsä. Hylkäys tarkoittaa, että jokin vastasi, joten esto ei ole siellä, missä luulet.
Palauta resolverikäytäntö ja todista se
Korjaa malli, älä oire. Vain tunnelin kautta tapahtuvaan ratkaisuun salli 53 tunnelin liitännässä, työnnä sisäinen resolveri tunnelin kokoonpanon mukana ja jätä fyysinen linkki ilman mitään DNS-lupaa. wg-quickissa resolverin liitännän kokoonpanoon kirjoittava rivi onDNS =, joten tunneli, joka jättää sen pois, jättää vanhan resolverin paikalleen ja jokaisen kyselyn väärälle reitille.wg-quick-käsikirjadokumentoi tämän käyttäytymisen alustakohtaisesti.
Tarkista sitten tässä järjestyksessä. Linuxissaresolvectl statusnäyttää aktiivisen linkin,dig +short example.comtestaa julkisen nimen,dig @10.8.0.1 internal.example.comtestaa yksityisen, jasudo tcpdump -ni any port 53näyttää, mitä liitäntää paketit käyttävät, kun ajat molemmat. WindowsissaGet-DnsClientServerAddress -AddressFamily IPv4jaResolve-DnsName example.comantavat samat kaksi tosiasiaa: kuka on määritetty ja kuka vastaa.
Lopeta negatiiviseen testiin. Irrota tunneli, varmista että tuore julkinen nimi epäonnistuu, varmista että yksityinen nimi epäonnistuu javarmista, ettei yksikään portin 53 paketti lähtenyt fyysisestä sovittimesta. Esto, joka pitää vain välimuistiin tallennetuille vastauksille, ei pidä lainkaan.
Tarkistuslista ennen tiketin sulkemista:
- Katkoksen aikana käytetty resolveri on se, jota käytäntö tarkoittaa.
- Asiakkaan oma päätepistehaku on yhä sallittu, välimuistin tai poikkeuksen kautta.
- DoH ja DoT joko kuuluvat eston piiriin tai on poistettu käytöstä käytännöllä.
- Yksityiset vyöhykkeet epäonnistuvat suljetusti, eivät avoimesti, kun tunneli on poissa.