Interna imena ne rade na VPN-u dok javne stranice rade

Jedan korisnik prijavljuje da se ime hosta s intraneta ne razrješava preko VPN-a. Drugi izvještaj, s istog prijenosnika, kaže da test curenja i dalje pokazuje upite na koje odgovara lokalni resolver. Zvuče kao jedan problem, a dva su, s različitim dokazima, i uobičajeni popravak za prvi pogoršava drugi. Razdvojite ih prije nego što dotaknete bilo koju postavku.

Dva simptoma koja nisu jedan kvar

Neuspjeh da se razriješi interno ime znači da je pitanje otišlo negdje gdje za njega nema odgovora. Upiti koji izlaze iz tunela znače da je pitanje otišlo na pogrešno mjesto čak i kad je odgovor bio dostupan. To su suprotni kvarovi: jedan je odgovor koji nedostaje, drugi je suvišno odredište.

Zamka je u tome što dodavanje uredskog resolvera svuda popravlja prvi i garantuje drugi. Dodavanje javnog resolvera svuda čini obrnuto.

Zapišite oba zapažanja s vremenskom oznakom, pa prođite kroz četiri provjere ispod po redu.

Čiji resolver adaptera dobija pitanje

Na Windowsu DNS klijent bira servere prema redoslijedu povezivanja adaptera, a tunelski adapter nije automatski prvi. Otvorite napredne postavke adaptera i pomjerite vezu za daljinski pristup iznad fizičkog adaptera, pa se ponovo povežite da bi promjena važila u novoj sesiji.

Redoslijed povezivanja je samo prva polovina. Klijent mora znati i koja imena pripadaju tom adapteru, a to je pitanje sufiksa, ne redoslijeda.

Stavite izlaz ipconfig /all s radne mašine pored izlaza s prijenosnika, oba uzeta dok je tunel podignut. Radna mašina će pokazati DNS sufiks specifičan za vezu na svom uredskom adapteru, a prijenosnik možda neće pokazati ništa na tunelu. Ta razlika objašnjava cijelu klasu izvještaja tipa server je tu negdje, a ime i dalje ne radi, jer bez sufiksa kratko ime nikad se ne dopunjuje do zone koju opslužuje uredski resolver.

Kratkom imenu treba sufiks prije nego ruta

Tipkanje nekvalifikovanog imena hosta traži od resolvera da pogodi domenu. Pogodak dolazi s liste sufiksa vezane za vezu, a ako je ta lista prazna, upit izlazi kao jedna oznaka koju nijedna privatna zona neće poklopiti.

Kopirajte sufiks s radne mašine u IPv4 svojstva VPN adaptera na kartici DNS, pa se ponovo povežite. Na Linuxu je ekvivalent domena pretrage na tunelskoj vezi, koju systemd-resolved izlaže po vezi, a ne globalno.

Držite dvije postavke odvojeno u bilješkama. Sufiks mijenja šta se pita; adresa resolvera mijenja koga se pita. Popravak jednog dok je drugo pogrešno daje rezultat koji izgleda slučajno.

Pitajte resolver direktno, pa ime

Direktan upit uredskom resolveru odvaja problem imena od problema puta, jer u potpunosti zaobilazi klijentov izbor resolvera.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prva naredba pita određeni server za potpuno kvalifikovano ime. Ako odgovori, resolver i ruta do njega su u redu i kvar je u izboru ili sufiksu. Ako istekne vrijeme, adresa je pogrešna ili nedostupna i problem je u rutiranju, ne u DNS-u. Druga naredba pokazuje šta se dešava s kratkim imenom, a treća ispisuje konfiguraciju resolvera po vezi na systemd hostu.

Pazite na wildcard odgovore koje neke mreže vraćaju za nepoznata imena. Vjerodostojan odgovor nije dokaz da je odgovorio željeni server, zato uporedite vraćenu adresu s onom koju interna usluga zaista koristi. Ako adresa pripada parkirnoj stranici ili proxyju, resolver je odgovorio, ali odgovor nikad nije bio vaš. Ta razlika štedi sat jurnjave za tunelom koji je cijelo vrijeme radio.

Na Linuxu VPN klijent koji prepisuje /etc/resolv.conf u potpunosti zamjenjuje lokalne resolvere. vpnc izlaže DNSUpdate no da to spriječi, a systemd-resolved može na tunelsku vezu usmjeriti samo navedene domene. Oba pristupa zadržavaju javna imena na lokalnom resolveru i šalju interna imena u ured.

Curenja su pravilo, ne polje za potvrdu

Razrješavanje imena je UDP razmjena na port 53, pa tunel koji nosi web saobraćaj ali ne UDP ostavlja upit na fizičkoj putanji. Dokažite to snimanjem na fizičkoj mrežnoj kartici dok se razrješava javno ime. Upit vidljiv na tom interfejsu u čitljivom obliku znači da ga tunel ne nosi.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ako se upit pojavi na tom interfejsu u čitljivom obliku, tunel ga ne nosi. Popravak je pravilo koje dozvoljava port 53 samo resolveru koji je VPN potisnuo i odbacuje druga odredišta, plus konfiguracija klijenta koja potisnutu opciju ne odbacuje tiho.

Taj zadnji dio je važniji nego što izgleda. Pokrenite OpenVPN s route-nopull i potisnuta DNS opcija nestaje zajedno s rutama, osim ako se filter za povlačenje ne proširi da je zadrži. A klijent koji ignoriše dhcp-option DNS nastavit će koristiti ono što je imao prije. Svaka promjena na strani servera traži novu sesiju, jer se lista resolvera dostavlja kad se tunel podigne, a zastarjela sesija i dalje prikazuje staro stanje.

Zapišite koji ste kvar zaista primijetili prije nego što zatvorite tiket. Interni odgovor koji nedostaje i upit koji bježi iz tunela traže različite popravke, a promjena sufiksa koja popravi prvi može tiho pogoršati drugi. Ko sljedeći preuzme tiket, vjerovat će oznaci, zato oznaku učinite tačnom.