DNS ne solvas post kiam VPN kill switch blokas pordon 53

Kiam la kill switch faligas la tunelon, ĝi forprenas ankaŭ la DNS-vojon, kaj la solvilo restanta malofte estas tiu, kiun vi atendas. Du dezajnoj traktas tiun momenton tre malsame: bloki ĉiun DNS-pakaĵon, kiu ne estas ene de la tunelo, aŭlasi unu solvilon stare kiel escepton. Ambaŭ estas defenceblaj. El retumila langeto la simptomoj aspektas preskaŭ idente, do la unua tasko estas eltrovi, kiun dezajnon vi fakte enkondukis.

Mi tenas tiun distingon antaŭ mi, ĉar la korekto estas kontraŭa en ĉiu kazo. Unu dezajno bezonas pli larĝan escepton, la alia pli mallarĝan. Diveni kostas al vi aŭ privatecon aŭ posttagmezon.

Du DNS-dezajnoj por la sama paneo

Dezajno A traktas la solvilon kiel ajnan alian servon malantaŭ la tunelo. Fajroŝirmilaj reguloj permesas UDP kaj TCP 53 nur sur la tunela interfaco, kaj la adreso donita al la kliento estas solvilo ene de la tunelo. Kiam la tunelo falas, serĉoj haltas, kaj tio estas la celita rezulto, ne paneo.

Dezajno B tenas solvilon atingebla en la loka reto, kutime la enkursigilo ĉe 192.168.1.1 aŭ la sistema stumb kun 127.0.0.53, sur la rezonado, ke nomosolvado ne devus morti kun la tunelo. Ĝi estas oportuna en hejma LAN, kie la enkursigilo solvas por la tuta domo. En hotelaj aŭ flughavenaj Wi-Fi-retoj la sama escepto montras al servero de iu alia, kaj ĉiu nomo, kiun vi tajpas, estas malkaŝita, kvankam via reta trafiko restas blokita.

La limo estas, kiu posedas la solvilon. Se vi fidas la lokan, escepto estas malgranda, honesta truo. Se ne, la dezajno nur-per-tunelo estas la sola, kiu teniĝas, kaj la prezo estas, ke falinta tunelo forprenas ĉiun nomon.

Kial la propra serĉo de la VPN-kliento ankoraŭ funkcias

La kliento devas solvi la gastignomon de la pordego antaŭ ol ekzistas tunelo, do strikta blokado ne rajtas kovri la startvojon de la kliento. Plej multaj klientoj aŭ kaŝmemorigas la finpunkton aŭ liveras dokumentitan start-escepton por tiu sola gastiganto. Se via regularo blokas tiun serĉon, la tunelo neniam revenas kaj la protokoloj montras klienton, kiu ne povas atingi sian propran serveron, kio estas difekto de politiko, ne de DNS.

Disigita DNS estas la alia loko, kie tio aperas. La kliento puŝas internan zonon al privata solvilo kaj lasas ĉion alian ĉe la sistema solvilo. Post falo publikaj nomoj eble ankoraŭ solviĝas, dum la internaj tempolimas, ĉar la privata zono ne havas vojon plu. Por la uzanto tio estas "la VPN rompis la interreton"; por la solvila protokolo ĝi estas demando, kiu neniam alvenis.

Sub systemd-resolved vi povas vidi la disigon rekte.resolvectl statuslistigas la DNS-servilojn laŭ ligilo kaj la enkursigajn domajnojn, kaj post kiam la tunelo falas, la interna domajno daŭre montras al servilo sur ligilo, kiu ne plu ekzistas. La stumbo ĉe 127.0.0.53 ankoraŭ akceptas la demandon, poste atendas supran servilon, kiu ne respondos, kaj tial la paneo daŭras sekundojn anstataŭ tuj reveni.

Ĉifrita DNS ne ĉirkaŭiras pakaĵfiltrilon

DNS over HTTPS kaj DNS over TLS veturas sur 443 kaj 853, do regulo, kiu blokas pordon 53, diris nenion pri ili. Bloki "DNS" laŭ pordo estas politiko pri pordo, ne pri nomosolvado. Se via kill switch blokas ĉiun trafikon ekster la tunelo, DoH estas kovrita hazarde. Se vi apartigis permeson por kaptita portalo aŭ publika solvilo, ĝi ne estas.

Regiloj sur la klienta flanko estas la pli malmultekosta levilo. Firefox forlasas sian DoH-solvilon, kiam la kanaria nomouse-application-dns.netne solviĝas, kaj tial administritaj retoj publikigas tiun domajnon kiel NXDOMAIN; entreprena politiko povas ankaŭ fiksi ĝin malŝalta. Android Private DNS kaj sekura DNS de Chrome havas siajn proprajn ŝaltilojn kaj proprajn defaŭltojn. Malŝalti ilin estas pli fidinda ol postkuri solvilajn adresojn, ĉar la adreslisto ŝanĝiĝas kaj via regularo ne.

Estas versio de ĉi tio, kiu tute ne temas pri likoj. Aplikaĵo kun fiksita solvilo ankoraŭ bezonas retan vojon por atingi ĝin. Ĉifrado ŝanĝas, kiu povas legi la demandon, ne ĉu la pakaĵo povas forlasi la maŝinon, do blokado por la tuta aparato venkas la agordon sen tuŝi ĝin.

Parigu la simptomon kun la tavolo

Plej multaj raportoj alvenas kiel unu frazo, kaj tiu frazo kutime jam nomas la tavolon. La tabelo sube estas tio, kion mi tralaboras antaŭ ol tuŝi regulon; la celo estas decidi, ĉu la demando estis blokita, misdirektita aŭ neniam sendita.

La unuaj du vicoj estas tiuj, kiujn homoj misdiagnozas. Silenta falo kaj rifuzo ambaŭ aspektas kiel "DNS estas rompita" en retumilo, sed nur unu el ili signifas, ke via kill switch faras sian laboron. Rifuzo signifas, ke io respondis, do la blokado ne estas tie, kie vi pensas.

Restarigu la solvilan politikon, poste pruvu ĝin

Riparu la dezajnon, ne la simptomon. Por solvado nur ene de la tunelo, permesu 53 sur la tunela interfaco, puŝu la internan solvilon kun la tunela agordo, kaj lasu la fizikan ligilon sen ajna DNS-permeso. Ĉe wg-quick la linioDNS =estas tiu, kiu skribas la solvilon en la interfacan agordon, do tunelo, kiu preterlasas ĝin, lasas la malnovan solvilon surloke kaj ĉiun demandon sur la malĝusta vojo.manlibro de wg-quickdokumentas tiun konduton laŭ platformo.

Poste kontrolu en ĉi tiu ordo. En Linuxresolvectl statusmontras la aktivan ligilon,dig +short example.comtestas publikan nomon,dig @10.8.0.1 internal.example.comtestas la privatan, kajsudo tcpdump -ni any port 53montras, kiun interfacon la pakaĵoj uzas dum vi rulas ambaŭ. En WindowsGet-DnsClientServerAddress -AddressFamily IPv4kajResolve-DnsName example.comdonas la samajn du faktojn: kiu estas agordita kaj kiu respondas.

Finu per la negativa testo. Malkonektu la tunelon, konfirmu, ke freŝa publika nomo fiaskas, konfirmu, ke la privata nomo fiaskas, kajkonfirmu, ke neniu pakaĵo de pordo 53 forlasis la fizikan adaptilon. Blokado, kiu teniĝas nur por kaŝmemoraj respondoj, tute ne teniĝas.

Kontrola listo antaŭ ol fermi la bileton:

• La solvilo uzita dum la paneo estas tiu, kiun la politiko celas.
• La propra finpunkta serĉo de la kliento ankoraŭ permesatas, per kaŝmemoro aŭ escepto.
• DoH kaj DoT aŭ estas kovritaj de la blokado aŭ malŝaltitaj per politiko.
• Privataj zonoj fiaskas fermite, ne malfermite, kiam la tunelo mankas.