DNS los nie op wanneer die VPN-kill switch poort 53 blokkeer
Die kill switch kan DNS doelbewus blokkeer. Vergelyk ontleding net binne die tonnel met 'n uitsondering vir 'n plaaslike oplosser, en bepaal dan watter laag werklik gefaal het.
Wanneer die kill switch die tonnel laat val, neem dit die DNS-pad saam, en die oplosser wat agterbly is selde die een wat jy verwag. Twee ontwerpe hanteer daardie oomblik baie verskillend: blokkeer elke DNS-pakkie wat nie binne die tonnel is nie, oflaat een oplosser as 'n uitsondering staan. Albei is verdedigbaar. Vanuit 'n blaaier-oortjie lyk die simptome byna identies, so die eerste taak is om uit te werk watter ontwerp jy werklik ontplooi het.
Ek hou daardie onderskeid voor oë, want die regstelling is in elke geval die teenoorgestelde. Die een ontwerp het 'n wyer uitsondering nodig; die ander een 'n nouer een. Om te raai kos jou of jou privaatheid of 'n middag.
Twee DNS-ontwerpe vir dieselfde onderbreking
Ontwerp A behandel die oplosser as net nog 'n diens agter die tonnel. Vuurreëlreëls laat UDP en TCP 53 net op die tonnel-koppelvlak toe, en die adres wat aan die kliënt gegee word, is 'n oplosser binne die tonnel. Wanneer die tonnel val, stop die opsoek, en dit is die bedoelde uitkoms, nie 'n fout nie.
Ontwerp B hou 'n oplosser bereikbaar op die plaaslike netwerk, gewoonlik die roeteerder by 192.168.1.1 of die bedryfstelsel-stub by 127.0.0.53, op die redenasie dat naamresolusie nie saam met die tonnel moet sterf nie. Dit is gerieflik op 'n tuis-LAN waar die roeteerder vir die hele huis oplos. Op hotel- of lughawe-Wi-Fi wys dieselfde uitsondering na iemand anders se bediener, en elke naam wat jy tik, word bekend gemaak, selfs al bly jou webverkeer geblokkeer.
Die grens is wie die oplosser besit. As jy die plaaslike een vertrou, is 'n uitsondering 'n klein, eerlike gaatjie. As jy dit nie doen nie, is die ontwerp wat net die tonnel gebruik die enigste een wat hou, en die prys is dat 'n gevalle tonnel elke naam saamneem.
Waarom die VPN-kliënt se eie opsoek steeds werk
Die kliënt moet die gasheernaam van die poort oplos voordat 'n tonnel bestaan, so 'n streng blokkade mag nie die kliënt se opstartpad dek nie. Die meeste kliënte kas die eindpuntadres of lewer 'n gedokumenteerde opstart-uitsondering vir daardie enkele gasheer. As jou reëlstel daardie opsoek blokkeer, kom die tonnel nooit terug nie en die logboeke wys 'n kliënt wat nie sy eie bediener kan bereik nie, wat 'n beleidsfout eerder as 'n DNS-fout is.
Split-DNS is die ander plek waar dit opduik. Die kliënt stoot 'n interne sone na 'n private oplosser en laat alles anders by die stelseloplosser. Na 'n val kan publieke name steeds oplos terwyl interne name uittyd, want die private sone het geen roete oor nie. Vir die gebruiker is dit "die VPN het die internet gebreek"; vir die oplosser-log is dit 'n navraag wat nooit arriveer het nie.
Onder systemd-resolved kan jy die splitsing direk sien.resolvectl statuswys die DNS-bedieners per skakel en die routeringsdomeine, en nadat die tonnel afgaan, bly die interne domein wys na 'n bediener op 'n skakel wat nie meer bestaan nie. Die stub by 127.0.0.53 aanvaar steeds die navraag, wag dan op 'n opstroom wat nie sal antwoord nie, en daarom neem die faling sekondes in plaas daarvan om dadelik terug te keer.
Geënkripteerde DNS kom nie om 'n pakkiefilter nie
DNS oor HTTPS en DNS oor TLS reis op 443 en 853, so 'n reël wat poort 53 blokkeer, het niks oor hulle gesê nie. Om "DNS" volgens poort te blokkeer is 'n beleid oor 'n poort, nie oor naamresolusie nie. As jou kill switch alle verkeer buite die tonnel blokkeer, word DoH per ongeluk gedek. As jy 'n toelating gemaak het vir 'n captive portal of 'n publieke oplosser, is dit nie.
Kliëntkant-beheermaatreëls is die goedkoper hefboom. Firefox laat vaar sy DoH-oplosser wanneer die kanarie-naamuse-application-dns.netnie oplos nie, en daarom publiseer bestuurde netwerke daardie domein as NXDOMAIN; ondernemingsbeleid kan dit ook afpen. Android Private DNS en Chrome se secure DNS het hul eie skakelaars en hul eie verstekke. Om dit af te skakel is betroubaarder as om oplosseradresse na te jaag, want die adreslys verander en jou reëlstel sal nie.
Daar is 'n weergawe hiervan wat glad nie oor lekke gaan nie. 'n Toepassing met 'n vasgepende oplosser het steeds 'n netwerkpad nodig om dit te bereik. Enkripsie verander wie die navraag kan lees, nie of die pakkie die masjien kan verlaat nie, so 'n blokkade vir die hele toestel verydel die instelling sonder om dit aan te raak.
Pas die simptoom by die laag
Die meeste verslae bereik jou as een sin, en daardie sin noem gewoonlik al die laag. Die tabel hieronder is wat ek deurgaan voordat ek 'n reël aanraak; die punt is om te besluit of die navraag geblokkeer, verkeerd gerig of nooit gestuur is nie.
| 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 |
Die eerste twee rye is dié wat mense verkeerd diagnostiseer. 'n Stille val en 'n weiering lyk albei soos "DNS is stukkend" in 'n blaaier, maar net een van hulle beteken jou kill switch doen sy werk. 'n Weiering beteken iets het geantwoord, so die blokkade is nie waar jy dink dit is nie.
Herstel die oplosserbeleid en bewys dit dan
Maak die ontwerp reg, nie die simptoom nie. Vir ontleding net binne die tonnel, laat 53 op die tonnel-koppelvlak toe, stoot die interne oplosser saam met die tonnelkonfigurasie, en laat die fisiese skakel sonder enige DNS-toelating. Met wg-quick is dit dieDNS =-reël wat die oplosser in die koppelvlakkonfigurasie skryf, so 'n tonnel wat dit weglaat, laat die ou oplosser in plek en elke navraag op die verkeerde pad. Diewg-quick-handleidingdokumenteer daardie gedrag per platform.
Verifieer dan in hierdie volgorde. Op Linux wysresolvectl statusdie aktiewe skakel,dig +short example.comtoets 'n publieke naam,dig @10.8.0.1 internal.example.comtoets die private een, ensudo tcpdump -ni any port 53wys watter koppelvlak die pakkies gebruik terwyl jy albei uitvoer. Op Windows geeGet-DnsClientServerAddress -AddressFamily IPv4enResolve-DnsName example.comdieselfde twee feite: wie is opgestel, en wie antwoord.
Sluit af met die negatiewe toets. Ontkoppel die tonnel, bevestig dat 'n vars publieke naam faal, bevestig dat die private naam faal, enbevestig dat geen poort 53-pakkie die fisiese adapter verlaat het nie. 'n Blokkade wat net vir gekaste antwoorde hou, hou glad nie.
Kontrolelys voordat jy die kaartjie sluit:
- Die oplosser wat tydens die onderbreking gebruik word, is die een wat die beleid bedoel.
- Die kliënt se eie eindpunt-opsoek word steeds toegelaat, deur kas of deur uitsondering.
- DoH en DoT word of deur die blokkade gedek of deur beleid gedeaktiveer.
- Private sones faal geslote, nie oop nie, sodra die tonnel weg is.