Interna imena ne rade preko VPN-a dok javni sajtovi rade

Jedan korisnik prijavljuje da se ime hosta sa intraneta ne razrešava preko VPN-a. Drugi izveštaj, sa istog laptopa, kaže da test curenja i dalje pokazuje upite na koje odgovara lokalni resolver. Zvuče kao jedan problem, a dva su, sa različitim dokazima, i uobičajena popravka prvog pogoršava drugi. Razdvojite ih pre nego što dirnete bilo koje podešavanje.

Dva simptoma koja nisu jedan kvar

Neuspeh da se razreši interno ime znači da je pitanje otišlo negde gde nema odgovora za njega. Upiti koji napuštaju tunel znače da je pitanje otišlo na pogrešno mesto čak i kada je odgovor bio dostupan. To su suprotni kvarovi: jedan je odgovor koji nedostaje, drugi je dodatno odredište.

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

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

Resolver kog adaptera dobija pitanje

Na Windows-u DNS klijent bira servere prema redosledu povezivanja adaptera, a adapter tunela nije automatski prvi. Otvorite napredna podešavanja adaptera i premestite vezu za daljinski pristup iznad fizičkog adaptera, pa se ponovo povežite da bi promena važila za novu sesiju.

Redosled povezivanja je samo prva polovina. Klijent takođe mora da zna koja imena pripadaju tom adapteru, a to je pitanje sufiksa, ne redosleda.

Stavite ipconfig /all radne mašine pored onog sa laptopa, oba snimljena dok je tunel podignut. Radna mašina će pokazati DNS sufiks specifičan za vezu na svom kancelarijskom adapteru, a laptop možda neće pokazati nijedan na tunelu. Ta razlika objašnjava čitavu klasu prijava u kojima je server tu, a ime i dalje ne radi, jer bez sufiksa kratko ime nikada nije dopunjeno do zone koju opslužuje kancelarijski resolver.

Kratkom imenu treba sufiks pre nego ruta

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

Kopirajte sufiks radne mašine u IPv4 svojstva VPN adaptera na kartici DNS, pa se ponovo povežite. Na Linux-u ekvivalent je domen pretrage na linku tunela, koji systemd-resolved izlaže po linku, a ne globalno.

Držite dve postavke odvojeno u beleškama. Sufiks menja šta se pita; adresa resolvera menja koga se pita. Popravka jedne dok je druga pogrešna daje rezultat koji izgleda slučajno.

Pitajte resolver direktno, pa ime

Direktan upit kancelarijskom resolveru razdvaja problem imena od problema putanje, jer potpuno zaobilazi izbor resolvera na klijentu.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prva komanda 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, adresa je pogrešna ili nedostupna i problem je u rutiranju, ne u DNS-u. Druga komanda pokazuje šta se dešava sa kratkim imenom, a treća ispisuje konfiguraciju resolvera po linku na systemd hostu.

Pazite na džoker odgovore, koje neke mreže vraćaju za nepoznata imena. Verodostojan odgovor nije dokaz da je odgovorio željeni server, zato uporedite vraćenu adresu sa onom koju interni servis zaista koristi. Ako adresa pripada parkiranoj stranici ili proxy-ju, resolver je odgovorio, ali odgovor nikada nije bio vaš. Ta razlika štedi sat vremena jurnjave za tunelom koji je sve vreme radio.

Na Linux-u, VPN klijent koji prepisuje /etc/resolv.conf potpuno zamenjuje lokalne resolvere. vpnc izlaže DNSUpdate no da to zaustavi, a systemd-resolved može da usmeri samo navedene domene na link tunela. Oba pristupa zadržavaju javna imena na lokalnom resolveru dok interna imena šalju u kancelariju.

Curenja su pravilo, ne polje za štikliranje

Razrešavanje imena je UDP razmena na port 53, pa tunel koji nosi veb saobraćaj ali ne UDP ostavlja upit na fizičkoj putanji. Dokažite to hvatanjem na fizičkoj mrežnoj kartici dok se razreš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 prenosi. Popravka je pravilo koje dozvoljava port 53 samo resolveru koji je VPN potisnuo i odbacuje ostala odredišta, uz konfiguraciju klijenta koja tiho ne odbacuje potisnutu opciju.

Poslednji deo je važniji nego što izgleda. Pokrenite OpenVPN sa route-nopull i potisnuta DNS opcija nestaje zajedno sa rutama, osim ako se pull filter proširi da je zadrži. A klijent koji ignoriše dhcp-option DNS nastaviće da koristi ono što je imao pre. Svaka promena na strani servera zahteva novu sesiju da bi delovala, jer se lista resolvera dostavlja kada se tunel podigne, a zastarela sesija i dalje pokazuje staro stanje.

Zapišite koji ste kvar zaista primetili pre nego što zatvorite tiket. Interni odgovor koji nedostaje i upit koji beži iz tunela traže različite popravke, a promena sufiksa koja popravlja prvo može tiho pogoršati drugo. Sledeći koji preuzme tiket verovaće oznaci, zato neka oznaka bude tačna.