Ĉu la DNS de via VPN estas vere uzata? Kaptu pordon 53 kaj rigardu
Puŝita DNS-opcio ne estas vojo de demando. Kontrolu, kion tenas la interfaco, observu la demandon eliri, kaj ĉesu fidi paĝon de lika testo kiel pruvon.
Demandu la plej multajn homojn, kion VPN-kliento faras kun DNS, kaj ili diros, ke ĝi agordas la solvilon, do demandoj vojaĝas ene de la tunelo. La puŝo estas reala; la supozo, ke ĝi fariĝas demando, ne. Inter puŝita opcio kaj pako sur la drato staras tri etapoj, kaj ĉiu malsukcesas sendepende tiel, ke ĉio aspektas kiel difektita DNS-servilo. Tial paĝo de lika testo kaj funkcianta retumilo povas malkonsenti pri la sama maŝino en la sama momento.
Puŝita opcio ne estas demando
La unua etapo estas, ke la servilo proponas agordojn, ekzemple puŝitan DNS-opcion nomantan solvilon ene de la tunelo. La dua etapo estas, ke la kliento aplikas tiujn agordojn al interfaco. La tria etapo estas, ke programo efektive sendas demandon al tiu adreso. Malsukceso en la dua etapo lasas la opcion videbla en la konekta protokolo dum la solvila listo restas senŝanĝa, kaj malsukceso en la tria etapo lasas tute ĝustan solvilan liston neuzata.
Plej multa sensolvado kunfandas tiujn tri en unu kaj kulpigas la VPN-servilon, kiu kutime estas la sola partio kapabla pruvi, ke ĝi faris sian parton. Legu anstataŭe la realan solvilan staton de la kliento, poste observu unu demandon eliri. Tiuj du observoj apartigas agordon de enkursigo kaj de politiko, kaj ili kostas ĉirkaŭ kvin minutojn. Konservu la kaptaĵojn, ĉar la sekva inĝeniero volas la antaŭan kaj postan statojn, ne priskribon de ili.
Kontrolu, kion la interfaco vere tenas
En Linux la sistema solvilo povas esti la simpla dosiero, NetworkManager aŭ systemd-resolved, kaj kiu el ili posedas ĝin decidas, kie puŝita servilo alteriĝas. Komandlinia procezo OpenVPN ne ĝisdatigas la sisteman solvilon memstare, do la dokumentita integriĝo estas skripto up/down aŭ konekta administrilo, kiu jam scias apliki la agordojn. Ruli ambaŭ estas efika maniero krei konkuradon.
resolvectl status
cat /etc/resolv.conf
En Windows la listo estas laŭ adaptilo, do la tunela adaptilo povas teni la internajn servilojn dum la fizika adaptilo retenas la lokajn kaj venkas por iuj nomoj. Komparu ambaŭ adaptilojn anstataŭ tiun, kiun vi supozas aktiva.
Spuru unu demandon ekster la maŝinon
Kaptu ambaŭ interfacojn samtempe, poste solvu unu nomon, kiu devus uzi la internan solvilon. Tiu paro da kaptaĵoj respondas tion, kion neniu agorda eligo povas.
sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53
Demando, kiu aperas sur la fizika interfaco kaj neniam en la tunelo, signifas, ke la kliento elektis la malĝustan solvilon. Demando sur neniu el ili signifas, ke la programo respondis el kaŝmemoro, demandis stub-on aŭskultantan sur loopback, aŭ uzis ĉifritan solvilon, kies trafiko tute ne aperas kiel pordo 53. Kaptu ankaŭ respondojn, ne nur demandojn, ĉar demando eliranta tra la tunelo kun respondo de publika adreso estas alia misfunkcio ol neniu alvenanta respondo.
La fajroŝirmilo, kiu akceptas nur sian propran DNS
Komercaj klientoj foje instalas proprajn filtrajn ĉenojn. Unu dokumentita ŝablono permesas DNS al la propra solvilo de la kliento kaj forĵetas ĉion restantan UDP-trafikon sur pordo 53, kiu provas forlasi interfacon ne loopback, inkluzive trafikon, kiun la uzanto intence enkursigis aliloken. Demandoj de demono malaperas sen spuro, kio legiĝas kiel solvila misfunkcio anstataŭ kiel filtrilo.
sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'
Se forĵeta regulo estas prijuĝata antaŭ via escepto, aldonita regulo neniam atingiĝas, do enigu ĝin ĉe la unua pozicio kaj limigu la celon al la solvilo, kiun vi vere celas.
sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT
Tiu escepto estas diagnoza, ne politika. Se la regulo de la vendisto estas intenca, la subtenata riparo estas agordi la klienton permesi tiun solvilon kaj registri la decidon, ĉar enigita regulo ne postvivos la sekvan klientan ĝisdatigon.
Kial lika paĝo pruvas malpli, ol ĝi ŝajnas
Kion montras lika testpaĝo, estas la solvilo, kiu parolis kun la testa operatoro, ne tiu, kiun konsultis via maŝino. Loka plusendilo, kiu ripetas eksteren, metas sian propran eliran adreson sur tiun paĝon, kaj ĉifritaj demandoj povas lasi la paĝon tute malplena. Ambaŭ rezultoj estas mislegataj, unu kiel liko kaj la alia kiel garantio, kaj neniu el la du legadoj sekvas el la observo.
La defendebla pruvo estas la kaptaĵo: interfaco, cela adreso, respondo kaj tempindiko. Prenu unu antaŭ ol la tunelo leviĝas kaj unu poste, kaj komparu ilin la sekvan fojon, kiam nomo malsukcesos. Tiu paro ankaŭ diras al la sekva persono, ĉu la misfunkcio estis en solvado, enkursigo aŭ la propra alirpolitiko de la solvilo.