Unutarnja imena padaju na VPN-u dok se javne stranice razrješavaju

Jedan korisnik javlja da se intranet ime hosta ne razrješava preko VPN-a. Drugo izvješće, s istog prijenosnika, kaže da test curenja i dalje pokazuje da upite odgovara lokalni razrješivač. Zvuče kao jedan problem, a dva su, s različitim dokazima, i uobičajeni popravak prvoga pogoršava drugi. Razdvojite ih prije nego dotaknete bilo koju postavku.

Dva simptoma koji nisu jedna greška

Neuspjeh razrješavanja unutarnjeg imena 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 suprotne greške: u jednoj nedostaje odgovor, u drugoj postoji dodatno odredište.

Zamka je u tome što dodavanje uredskog razrješivača posvuda popravlja prvo i jamči drugo. Dodavanje javnog razrješivača posvuda čini obrnuto.

Zapišite oba opažanja s vremenskom oznakom, zatim redom prođite četiri provjere ispod.

Koji adapterov razrješivač dobiva pitanje

Na Windowsima DNS klijent bira poslužitelje prema redoslijedu povezivanja adaptera, a tunelski adapter nije automatski prvi. Otvorite napredne postavke adaptera i pomaknite vezu daljinskog pristupa iznad fizičkog adaptera, zatim se ponovno povežite kako bi se promjena primijenila na novu sesiju.

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

Stavite ipconfig /all s radnog računala uz onaj s prijenosnika, oba snimljena dok je tunel aktivan. Radno računalo pokazat će DNS sufiks specifičan za vezu na svom uredskom adapteru, a prijenosnik na tunelu možda ništa. Ta razlika objašnjava cijelu klasu izvješća u kojima se kaže da je poslužitelj tamo, a ime ipak pada, jer bez sufiksa kratko ime nikad se ne dopunjava u zonu koju uredski razrješivač poslužuje.

Kratko ime treba sufiks prije nego što treba rutu

Upisivanje hostnamea bez kvalifikacije traži od razrješivača da pogodi domenu. Pogodak dolazi s popisa sufiksa vezanog uz vezu, a ako je taj popis prazan, upit izlazi kao jedna oznaka koju nijedna privatna zona neće prepoznati.

Kopirajte sufiks radnog računala u IPv4 svojstva VPN adaptera na kartici DNS, zatim se ponovno povežite. Na Linuxu je ekvivalent domena pretraživanja na tunelskoj vezi, koju systemd-resolved izlaže po vezi, a ne globalno.

Držite te dvije postavke odvojeno u bilješkama. Sufiks mijenja što se pita; adresa razrješivača mijenja koga se pita. Popravljanje jednoga dok je drugo pogrešno daje rezultat koji izgleda slučajno.

Pitajte razrješivač izravno, pa ime

Izravan upit uredskom razrješivaču odvaja problem imena od problema puta, jer u potpunosti zaobilazi klijentov odabir razrješivača.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prva naredba pita određeni poslužitelj za potpuno kvalificirano ime. Ako odgovori, razrješivač i put do njega su u redu, a greška je u odabiru ili sufiksu. Ako istekne, adresa je pogrešna ili nedostupna i problem je u usmjeravanju, a ne u DNS-u. Druga naredba pokazuje što se događa s kratkim imenom, a treća ispisuje konfiguraciju razrješivača po vezi na systemd računalu.

Pazite na zamjenske odgovore, koje neke mreže vraćaju za nepoznata imena. Odgovor koji izgleda uvjerljivo nije dokaz da je odgovorio namjeravani poslužitelj, pa usporedite vraćenu adresu s onom koju unutarnja usluga stvarno koristi. Ako adresa pripada parkirnoj stranici ili proxyju, razrješivač je odgovorio, ali odgovor nikada nije bio vaš. Ta razlika štedi sat vremena jurnjave za tunelom koji je cijelo vrijeme radio.

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

Curenja su pravilo, a ne potvrdni okvir

Razrješavanje imena je UDP razmjena na portu 53, pa tunel koji nosi web promet ali ne UDP ostavlja upit na fizičkom putu. Dokažite to snimanjem na fizičkoj mrežnoj kartici dok se razrješava javno ime. Upit vidljiv na tom sučelju 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 sučelju u čitljivom obliku, tunel ga ne nosi. Popravak je pravilo koje dopušta port 53 samo razrješivaču koji je VPN gurnuo i odbacuje ostala odredišta, uz konfiguraciju klijenta koja tiho ne odbacuje gurnutu opciju.

Taj zadnji dio važniji je nego što izgleda. Pokrenite OpenVPN s route-nopull i gurnuta DNS opcija nestaje zajedno s rutama, osim ako se filtar povlačenja proširi da je zadrži. a klijent koji ignorira dhcp-option DNS nastavit će koristiti ono što je imao prije. Svaka promjena na strani poslužitelja treba novu sesiju da bi djelovala, jer se popis razrješivača dostavlja kad se tunel podiže, a zastarjela sesija nastavlja pokazivati staro stanje.

Zapišite koju ste grešku doista primijetili prije zatvaranja zahtjeva. Nedostatak unutarnjeg odgovora i upit koji bježi iz tunela traže različite popravke, a promjena sufiksa koja popravlja prvo može tiho pogoršati drugo. Sljedeća osoba koja preuzme zahtjev vjerovat će oznaci, zato oznaku učinite točnom.