DNS nuk zgjidhet kur kill switch i VPN bllokon portën 53
Një kill switch mund ta bllokojë DNS-në me qëllim. Krahasoni zgjidhjen vetëm brenda tunelit me një përjashtim për një resolver lokal, pastaj përcaktoni cila shtresë dështoi vërtet.
Kur kill switch e rrëzon tunelin, merr me vete edhe rrugën e DNS-së, dhe resolver-i që mbetet rrallë është ai që prisni. Dy modele e trajtojnë atë moment shumë ndryshe: të bllokosh çdo paketë DNS që nuk është brenda tunelit, ose të lësh një resolver në këmbë si përjashtim. Të dyja janë të mbrojtshme. Nga një skedë e shfletuesit simptomat duken pothuajse njësoj, prandaj detyra e parë është të zbuloni cilin model keni vendosur në të vërtetë.
E mbaj atë dallim para syve sepse rregullimi është i kundërt në secilin rast. Një model kërkon një përjashtim më të gjerë, tjetri më të ngushtë. Hamendja ju kushton ose privatësinë ose një pasdite.
Dy modele DNS për të njëjtin ndërprerje
Modeli A e trajton resolver-in si një shërbim tjetër pas tunelit. Rregullat e firewall-it lejojnë UDP dhe TCP 53 vetëm në ndërfaqen e tunelit, dhe adresa që i jepet klientit është një resolver brenda tunelit. Kur tuneli bie, kërkimet ndalen, dhe ky është rezultati i synuar, jo një defekt.
Modeli B mban një resolver të arritshëm në rrjetin lokal, zakonisht router-in në 192.168.1.1 ose stub-in e sistemit operativ në 127.0.0.53, me arsyetimin se zgjidhja e emrave nuk duhet të vdesë me tunelin. Është i përshtatshëm në një LAN shtëpiak ku router-i zgjidh për gjithë shtëpinë. Në Wi-Fi të një hoteli ose aeroporti i njëjti përjashtim tregon drejt serverit të dikujt tjetër, dhe çdo emër që shkruani zbulohet, edhe pse trafiku juaj web mbetet i bllokuar.
Kufiri është kush e zotëron resolver-in. Nëse i besoni atij lokal, përjashtimi është një vrimë e vogël dhe e ndershme. Nëse nuk i besoni, modeli vetëm-tunel është i vetmi që mbahet, dhe çmimi është që një tunel i rënë merr të gjithë emrat me vete.
Pse kërkimi i vetë klientit të VPN-së vazhdon të funksionojë
Klienti duhet të zgjidhë emrin e hostit të gateway-it përpara se të ekzistojë një tunel, prandaj një bllokim i rreptë nuk duhet të mbulojë rrugën e nisjes së klientit. Shumica e klientëve ose e ruajnë adresën e pikës fundore në cache, ose ofrojnë një përjashtim të dokumentuar nisjeje për atë host të vetëm. Nëse grupi juaj i rregullave e bllokon atë kërkim, tuneli nuk kthehet kurrë dhe regjistrat tregojnë një klient që nuk arrin dot serverin e vet, që është defekt politike dhe jo DNS.
DNS i ndarë është vendi tjetër ku kjo shfaqet. Klienti e shtyn një zonë të brendshme drejt një resolver-i privat dhe lë gjithçka tjetër te resolver-i i sistemit. Pas një rënieje, emrat publikë mund të zgjidhen ende, ndërsa ata të brendshëm skadojnë, sepse zona private nuk ka më rrugë. Për përdoruesin kjo është "VPN-ja prishi internetin"; për regjistrin e resolver-it është një kërkesë që nuk mbërriti kurrë.
Nën systemd-resolved e shihni ndarjen drejtpërdrejt. resolvectl status liston serverët DNS për çdo lidhje dhe domenet e rrugëzimit, dhe pasi tuneli bie, domeni i brendshëm vazhdon të tregojë drejt një serveri në një lidhje që nuk ekziston më. Stub-i në 127.0.0.53 e pranon ende kërkesën, pastaj pret një rrjedhë sipërme që nuk do të përgjigjet, dhe prandaj dështimi zgjat sekonda në vend që të kthehet menjëherë.
DNS i enkriptuar nuk e anashkalon një filtër paketash
DNS over HTTPS dhe DNS over TLS udhëtojnë në 443 dhe 853, prandaj një rregull që bllokon portën 53 nuk ka thënë asgjë për to. Të bllokosh "DNS" sipas portës është politikë për një port, jo për zgjidhjen e emrave. Nëse kill switch-i juaj bllokon gjithë trafikun jashtë tunelit, DoH mbulohet rastësisht. Nëse keni hapur një leje për një portal captiv ose një resolver publik, nuk mbulohet.
Kontrollet nga ana e klientit janë levë më e lirë. Firefox e braktis resolver-in e vet DoH kur emri kanarinë use-application-dns.net nuk zgjidhet, dhe prandaj rrjetet e menaxhuara e publikojnë atë domen si NXDOMAIN; politika e ndërmarrjes mund ta fiksojë edhe të fikur. Android Private DNS dhe DNS i sigurt i Chrome kanë çelësat e tyre dhe vlerat e tyre të paracaktuara. Fikja e tyre është më e besueshme sesa të vraposh pas adresave të resolver-ëve, sepse lista e adresave ndryshon dhe grupi juaj i rregullave jo.
Ekziston një version i kësaj që nuk flet fare për rrjedhje. Një aplikacion me resolver të fiksuar ka ende nevojë për një rrugë rrjeti për ta arritur. Enkriptimi ndryshon kush mund ta lexojë kërkesën, jo nëse paketa mund të dalë nga makina, prandaj një bllokim për gjithë pajisjen e mund atë rregullim pa e prekur.
Përputhni simptomën me shtresën
Shumica e raporteve vijnë si një fjali, dhe ajo fjali zakonisht e emërton shtresën tashmë. Tabela më poshtë është ajo që kaloj përpara se të prek një rregull; qëllimi është të vendos nëse kërkesa u bllokua, u drejtua gabimisht apo nuk u dërgua kurrë.
| 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 |
Dy rreshtat e parë janë ata që njerëzit i diagnostikojnë gabimisht. Një rënie e heshtur dhe një refuzim duken njësoj si "DNS-ja u prish" në shfletues, por vetëm njëri prej tyre do të thotë që kill switch-i juaj po bën punën e vet. Refuzimi do të thotë që diçka u përgjigj, prandaj bllokimi nuk është aty ku mendoni.
Riktheni politikën e resolver-it, pastaj provojeni
Rregulloni modelin, jo simptomën. Për zgjidhje vetëm brenda tunelit, lejoni 53 në ndërfaqen e tunelit, shtyni resolver-in e brendshëm bashkë me konfigurimin e tunelit dhe lini lidhjen fizike pa asnjë leje DNS. Në wg-quick, rreshti DNS = është ai që e shkruan resolver-in në konfigurimin e ndërfaqes, prandaj një tunel që e lë mënjanë e lë resolver-in e vjetër në vend dhe çdo kërkesë në rrugën e gabuar. manuali i wg-quick dokumenton atë sjellje për çdo platformë.
Pastaj verifikoni në këtë rend. Në Linux, resolvectl status tregon lidhjen aktive, dig +short example.com teston një emër publik, dig @10.8.0.1 internal.example.com teston atë privat, dhe sudo tcpdump -ni any port 53 tregon cilën ndërfaqe përdorin paketat ndërsa i ekzekutoni të dyja. Në Windows, Get-DnsClientServerAddress -AddressFamily IPv4 dhe Resolve-DnsName example.com japin të njëjtat dy fakte: kush është konfiguruar dhe kush përgjigjet.
Përfundoni me testin negativ. Shkëputni tunelin, konfirmoni që një emër publik i ri dështon, konfirmoni që emri privat dështon, dhe konfirmoni që asnjë paketë e portës 53 nuk doli nga përshtatësi fizik. Një bllokim që mbahet vetëm për përgjigje të ruajtura në cache nuk mbahet aspak.
Listë kontrolli para se ta mbyllni tiketën:
- Resolver-i i përdorur gjatë ndërprerjes është ai që synon politika.
- Kërkimi i vetë pikës fundore nga klienti lejohet ende, përmes cache ose përjashtimi.
- DoH dhe DoT ose mbulohen nga bllokimi ose janë çaktivizuar nga politika.
- Zonat private dështojnë të mbyllura, jo të hapura, sapo tuneli zhduket.