A DNS nem old fel, ha a VPN kill switch blokkolja az 53-as portot
A kill switch szándékosan blokkolhatja a DNS-t. Hasonlítsa össze a csak az alagúton belüli feloldást egy helyi feloldó kivételével, majd derítse ki, melyik réteg hibázott valójában.
Amikor a kill switch ledobja az alagutat, magával viszi a DNS útvonalát is, és a hátramaradó feloldó ritkán az, amelyre számít. Két terv nagyon különbözőképpen kezeli ezt a pillanatot: blokkolni minden DNS-csomagot, amely nincs az alagúton belül, vagyegy feloldót kivételként talpon hagyni. Mindkettő védhető. Egy böngészőfülről a tünetek szinte azonosnak látszanak, ezért az első feladat kideríteni, melyik tervet telepítette valójában.
Szem előtt tartom ezt a különbséget, mert a javítás mindkét esetben ellentétes. Az egyik terv szélesebb kivételt kíván, a másik szűkebbet. A találgatás vagy a magánéletébe, vagy egy délutánba kerül.
Két DNS-terv ugyanarra a kiesésre
Az A terv a feloldót az alagút mögötti szolgáltatásként kezeli. A tűzfal-szabályok csak az alagút interfészén engedélyezik az UDP és TCP 53-at, és az ügyfélnek adott cím az alagúton belüli feloldó. Amikor az alagút leesik, a keresések leállnak, és ez a szándékolt eredmény, nem hiba.
A B terv elérhetőn tart egy feloldót a helyi hálózaton, általában a routert a 192.168.1.1 címen vagy az operációs rendszer stubját a 127.0.0.53 címen, azzal az indoklással, hogy a névfeloldásnak nem kellene meghalnia az alagúttal. Kényelmes otthoni LAN-on, ahol a router az egész ház helyett old fel. Szállodai vagy repteres Wi-Fi-n ugyanez a kivétel valaki más szerverére mutat, és minden beírt név nyilvánosságra kerül, még akkor is, ha a webtorgalma blokkolva marad.
A határ az, hogy kié a feloldó. Ha megbízik a helyiben, a kivétel kicsi és őszinte lyuk. Ha nem, a csak alagút terv az egyetlen, amely tartja magát, és az ára az, hogy a leesett alagút minden nevet magával visz.
Miért működik mégis a VPN-kliens saját keresése
Az ügyfélnek az alagút létezése előtt fel kell oldania az átjáró hosztnevét, ezért a szigorú blokknak nem szabad lefednie az ügyfél indítási útvonalát. A legtöbb ügyfél vagy gyorsítótárazza a végpont címét, vagy dokumentált indítási kivételt ad arra az egyetlen hosztra. Ha a szabálykészlete blokkolja ezt a keresést, az alagút soha nem jön vissza, és a naplók olyan ügyfelet mutatnak, amely nem éri el a saját szerverét; ez szabályzati hiba, nem DNS-hiba.
Az osztott DNS a másik hely, ahol ez megjelenik. Az ügyfél egy belső zónát egy privát feloldóhoz tol, minden mást pedig a rendszer feloldójánál hagy. Kiesés után a nyilvános nevek esetleg még feloldódnak, a belsők viszont időtúllépéssel elhalnak, mert a privát zónának nincs több útvonala. A felhasználónak ez "a VPN elrontotta az internetet"; a feloldó naplójának ez egy soha meg nem érkezett lekérdezés.
systemd-resolved alatt közvetlenül láthatja a felosztást.resolvectl statuslistázza a linkenkénti DNS-kiszolgálókat és az útválasztási tartományokat, és miután az alagút leesik, a belső tartomány továbbra is egy olyan linken lévő kiszolgálóra mutat, amely már nem létezik. A 127.0.0.53 címen lévő stub még elfogadja a lekérdezést, aztán olyan felsőbb szerverre vár, amely nem fog válaszolni, és ezért tart másodpercekig a hiba ahelyett, hogy azonnal visszatérne.
A titkosított DNS nem kerüli meg a csomagszűrőt
A DNS over HTTPS és a DNS over TLS a 443-as és 853-as porton utazik, tehát az 53-as portot blokkoló szabály semmit nem mond róluk. A "DNS" port szerinti blokkolása portról szóló szabályzat, nem névfeloldásról szóló. Ha a kill switch az alagúton kívüli összes forgalmat blokkolja, a DoH véletlenül le van fedve. Ha engedményt adott egy captive portal vagy egy nyilvános feloldó számára, akkor nem.
Az ügyféloldali vezérlők az olcsóbb eszköz. A Firefox akkor adja fel a DoH-feloldóját, amikor a kanárinévuse-application-dns.netnem oldódik fel, és ezért teszik közzé a kezelt hálózatok ezt a tartományt NXDOMAIN-ként; vállalati szabályzat is kikapcsolva rögzítheti. Az Android Private DNS és a Chrome biztonságos DNS-e saját kapcsolókkal és saját alapértékekkel rendelkezik. Kikapcsolásuk megbízhatóbb, mint a feloldócímek után rohangálni, mert a címek listája változik, a szabálykészlete pedig nem.
Van ennek egy olyan változata, amely egyáltalán nem szivárgásról szól. A rögzített feloldóval rendelkező alkalmazásnak továbbra is hálózati útvonalra van szüksége, hogy elérje. A titkosítás megváltoztatja, ki olvashatja a lekérdezést, nem azt, hogy a csomag elhagyhatja-e a gépet, ezért az egész eszközre vonatkozó blokk legyőzi a beállítást anélkül, hogy hozzányúlna.
Párosítsa a tünetet a réteggel
A legtöbb bejelentés egyetlen mondatként érkezik, és az a mondat általában már megnevezi a réteget. Az alábbi táblázat az, amit végigveszek, mielőtt bármelyik szabályhoz nyúlok; a cél eldönteni, hogy a lekérdezés blokkolódott-e, rossz irányba ment-e, vagy el sem indult.
| 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 |
Az első két sor az, amit az emberek rosszul diagnosztizálnak. A csendes leesés és az elutasítás egyaránt úgy néz ki a böngészőben, hogy "a DNS elromlott", de csak az egyikük jelenti azt, hogy a kill switch végzi a dolgát. Az elutasítás azt jelenti, hogy valami válaszolt, tehát a blokk nem ott van, ahol hiszi.
Állítsa helyre a feloldó szabályzatát, aztán bizonyítsa
A tervet javítsa, ne a tünetet. A csak alagúton belüli feloldáshoz engedélyezze az 53-at az alagút interfészén, tolja ki a belső feloldót az alagút konfigurációjával, és hagyja a fizikai linket DNS-engedély nélkül. A wg-quicknél a sorDNS =az, amely beírja a feloldót az interfész konfigurációjába, ezért az azt kihagyó alagút a régi feloldót hagyja a helyén, és minden lekérdezés rossz útvonalra kerül.wg-quick kézikönyvdokumentálja ezt a viselkedést platformonként.
Ezután ebben a sorrendben ellenőrizze. Linuxon aresolvectl statusaz aktív linket mutatja, adig +short example.comnyilvános nevet tesztel, adig @10.8.0.1 internal.example.coma privátot teszteli, és asudo tcpdump -ni any port 53megmutatja, melyik interfészt használják a csomagok, miközben mindkettőt futtatja. Windowson aGet-DnsClientServerAddress -AddressFamily IPv4és aResolve-DnsName example.comugyanazt a két tényt adja: ki van beállítva, és ki válaszol.
Fejezze be a negatív teszttel. Bontsa az alagutat, erősítse meg, hogy egy friss nyilvános név elhal, erősítse meg, hogy a privát név elhal, éserősítse meg, hogy egyetlen 53-as portú csomag sem hagyta el a fizikai adaptert. Az a blokk, amely csak gyorsítótárazott válaszokra tart, egyáltalán nem tart.
Ellenőrzőlista a jegy lezárása előtt:
- A kiesés alatt használt feloldó az, amelyet a szabályzat szán.
- Az ügyfél saját végpontkeresése továbbra is engedélyezett, gyorsítótár vagy kivétel révén.
- A DoH és a DoT vagy a blokk alá esik, vagy szabályzat tiltja.
- A privát zónák zártan hibáznak, nem nyitottan, amint az alagút eltűnik.