DNS ez da ebazten VPN kill switch-ek 53 portua blokeatzen duenean
Kill switch-ek DNS nahita blokea dezake. Konparatu tunelaren barruko ebazpena eta tokiko resolver baterako salbuespena, gero zehaztu zein geruza huts egin duen.
Kill switch-ek tunela erortzen duenean, DNS bidea ere eramaten du, eta atzean geratzen den resolverra gutxitan da espero duzuna. Bi diseinuk oso modu ezberdinean heltzen diote une horri: tunelaren barruan ez dagoen DNS pakete guztiak blokeatzea, edoresolver bat salbuespen gisa zutik uztea. Biak defendagarriak dira. Nabigatzaile fitxa batetik sintomak ia berdinak dirudite, beraz lehen lana benetan zein diseinu hedatu duzun argitzea da.
Bereizketa hori begien aurrean izaten dut, konponketa kasu bakoitzean kontrakoa delako. Diseinu batek salbuespen zabalagoa behar du; besteak estuagoa. Asmatzeak pribatutasuna edo arratsalde bat kostatzen dizu.
Bi DNS diseinu eten bererako
A diseinuak resolverra tunelaren atzeko beste zerbitzu bat balitz bezala tratatzen du. Suhormaren arauek UDP eta TCP 53 baimena ematen dute tunelaren interfazean soilik, eta bezeroari ematen zaion helbidea tunelaren barruko resolver bat da. Tunela erortzen denean, kontsultak gelditu egiten dira, eta hori da nahi zen emaitza, ez akats bat.
B diseinuak resolver bat eskura edukitzen du sare lokalean, normalean 192.168.1.1 helbideko routerra edo 127.0.0.53 helbideko sistema eragilearen stub-a, izenen ebazpenak tunelarekin hil behar ez duela argudiatuta. Etxeko LAN batean erosoa da, routerrak etxe osorako ebazten duelako. Hotel edo aireportu bateko Wi-Fi sarean salbuespen bera beste norbaiten zerbitzarira seinalatzen du, eta idazten duzun izen bakoitza agerian geratzen da, zure web trafikoa blokeatuta egon arren.
Muga resolverra nori dagokion da. Lokalari fidatzen bazara, salbuespena zulo txiki eta zintzoa da. Ez bazara fidatzen, tunel-soileko diseinua da eusten duen bakarra, eta prezioa eroritako tunel batek izen guztiak eramaten dituela da.
Zergatik VPN bezeroaren beraren kontsultak oraindik funtzionatzen duen
Bezeroak atebidearen ostalari-izena resolvatu behar du tunela existitu aurretik, beraz blokeo zorrotzak ez du bezeroaren abiarazte-bidea estali behar. Bezero gehienek muturreko helbidea cachean gordetzen dute edo ostalari bakar horretarako abiarazte-salbuespen dokumentatua eskaintzen dute. Zure arau-multzoak kontsulta hori blokeatzen badu, tunela ez da inoiz itzultzen eta erregistzoek bere zerbitzarira iritsi ezin den bezero bat erakusten dute, hau da, politika akatsa da, ez DNS akatsa.
DNS banatua da hori agertzen den beste tokia. Bezeroak barneko zona resolver pribatu batera bultzatzen du eta gainerako guztia sistemako resolverrean uzten du. Eroriz gero, izen publikoek oraindik resolvatu dezakete, barnekoek denbora-muga agortzen duten bitartean, zona pribatuak ez baitu biderik. Erabiltzailearentzat hori "VPN-ak internet hautsi zuen" da; resolverren erregistroarentzat inoiz iritsi ez zen kontsulta bat.
systemd-resolved-en azpian banaketa zuzenean ikus dezakezu.resolvectl statuslotura bakoitzeko DNS zerbitzariak eta bideratze-domeinuak zerrendatzen ditu, eta tunela jaitsi ondoren barneko domeinuak existitzen ez den lotura bateko zerbitzarira seinalatzen jarraitzen du. 127.0.0.53 helbideko stub-ak kontsulta onartzen du oraindik, gero ez du erantzungo goiko zerbitzari baten zain geratzen da, eta horregatik hutsegiteak segundo batzuk behar ditu berehala itzuli beharrean.
DNS zifratuak ez du pakete-iragazkia saihesten
DNS over HTTPS eta DNS over TLS 443 eta 853 portuetan bidaiatzen dute, beraz 53 portua blokeatzen duen arauak ez du haiei buruz ezer esan. "DNS" portuaren arabera blokeatzea portuari buruzko politika da, ez izenen ebazpenari buruzkoa. Zure kill switch-ek tunelaren kanpoko trafiko guztia blokeatzen badu, DoH kasualitatez estalita geratzen da. Captive portal edo resolver publiko baterako baimena atera baduzu, ez dago estalita.
Bezeroaren aldeko kontrolak palanka merkeagoa dira. Firefox-ek bere DoH resolverra uzten du kanariar izenakuse-application-dns.netresolvatzen ez duenean, eta horregatik sare kudeatuek domeinu hori NXDOMAIN gisa argitaratzen dute; enpresako politikak ere itzalita finka dezake. Android Private DNS eta Chrome-ren DNS seguruak beren etengailuak eta beren lehenespenak dituzte. Hori itzaltzea resolver helbideen atzetik ibiltzea baino fidagarriagoa da, helbide-zerrenda aldatzen delako eta zure arau-multzoa ez.
Honen bertsio bat dago isurketekin zerikusirik ez duena. Resolver finkatua duen aplikazio batek sare-bidea behar du hura iristeko. Zifraketak aldatzen du nork irakur dezakeen kontsulta, ez paketeak makina utz dezakeen, beraz gailu osorako blokeo batek ezarpena garaitzen du ukitu gabe.
Lotu sintoma geruzari
Txosten gehienak esaldi bakarrean iristen dira, eta esaldi horrek normalean geruza izendatzen du jada. Beheko taula arauren bat ukitu aurretik berrikusten dudana da; kontua da erabakitzea kontsulta blokeatu, gaizki bideratu edo sekula bidali ez zen.
| 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 |
Lehen bi errenkadak jendeak gaizki diagnostikatzen dituenak dira. Erorketa isilak eta uko-egiteak berdin dirudite nabigatzailean "DNS hondatuta dago" bezala, baina horietako batek soilik esan nahi du zure kill switch-ek bere lana egiten duela. Uko-egiteak zerbait erantzun zuela esan nahi du, beraz blokeoa ez da uste duzun tokian.
Leheneratu resolver politika eta gero frogatu
Konpondu diseinua, ez sintoma. Tunel-soileko ebazpenerako, baimendu 53 tunelaren interfazean, bultzatu barneko resolverra tunelaren konfigurazioarekin eta utzi esteka fisikoa DNS baimenik gabe. wg-quick-ekin resolverra interfazearen konfigurazioan idazten duen lerroaDNS =da, beraz hura saihesten duen tunel batek resolver zaharra bere tokian uzten du eta kontsulta bakoitza bide okerrean.wg-quick eskuliburuakhorrelako jokabidea dokumentatzen du plataforma bakoitzeko.
Gero egiaztatu ordena honetan. Linux-enresolvectl statusaktibatutako esteka erakusten du,dig +short example.comizen publiko bat probatzen du,dig @10.8.0.1 internal.example.compribatua probatzen du, etasudo tcpdump -ni any port 53paketeek zein interfaze erabiltzen duten erakusten du biak exekutatzen dituzun bitartean. Windows-enGet-DnsClientServerAddress -AddressFamily IPv4etaResolve-DnsName example.comberdin ematen dituzte bi datuak: nor dagoen konfiguratuta eta nork erantzuten duen.
Amaitu proba negatiboarekin. Deskonektatu tunela, egiaztatu izen publiko berri batek huts egiten duela, egiaztatu izen pribatuak huts egiten duela, etaegiaztatu 53 portuko paketerik ez zela adaptagailu fisikoetatik irten. Cachean dauden erantzunetarako soilik eusten duen blokeoak ez du batere eusten.
Txartela itxi aurretik egiaztapen-zerrenda:
- Etenduran zehar erabilitako resolverra politikak nahi duena da.
- Bezeroaren muturreko kontsulta baimenduta dago oraindik, cachez edo salbuespenaz.
- DoH eta DoT blokeoak estaltzen ditu edo politikak desgaitzen ditu.
- Zona pribatuek itxita egiten dute huts, ez irekita, tunela desagertzen denean.