VPN DNS radi, ali .local imena i dalje padaju: tko ih razrješava?

Dvije mašine na istom VPN-u, isto ime hosta, a samo jedna od njih ga razrješava: razlika obično nije u tunelu, nego u tome koji je razrješivač odgovorio. Na Linux radnoj površini to ime može proći kroz prekidač imenskih servisa, kroz stub systemd-resolved-a ili kroz razrješivač koji je aplikacija donijela sa sobom, i svaki od njih primjenjuje svoje pravilo na isti sufiks. Upravo se na sufiksu pravila razilaze, jer .local nije neutralna oznaka. Utvrdite koji put zapravo prolazi program koji ne uspijeva prije nego što promijenite redoslijed kojim se bilo šta izvršava.

Dva razrješivača, dva različita odgovora

Tradicionalno glibc traženje prolazi kroz red hosts: u nsswitch.conf i pita svaki modul redom dok jedan ne odgovori. Klijent koji razgovara sa systemd-resolved kroz stub slušač pita umjesto toga jedan proces, a taj proces primjenjuje politiku po linku plus svoje posebne slučajeve. Aplikacija koja donosi vlastiti razrješivač ili linkuje biblioteku koja to čini može zaobići oba. Tako jedno ime hosta može imati tri vlasnika na jednoj mašini, a samo jedan od njih zna što je VPN namjeravao.

Identifikujte vlasnika prije nego što bilo šta promijenite, jer se ispravka razlikuje za svakog od trojice. Pregledač i alat komandne linije na istoj radnoj površini mogu se legitimno ne slagati, a to neslaganje je trag, a ne greška. Ako pregledač razrješava ime a alat ne, vi otklanjate greške na putu razrješivača, a ne na VPN ruti. Potvrdite rutu odvojeno, da se greška rutiranja ne pomiješa sa greškom imenskog servisa. Kada se oba slažu, greška je uzvodno od hosta i konfiguracija razrješivača ovdje nije vrijedna još jedne izmjene.

Koja komanda je zapravo pitala vaš razrješivač

Dvije komande samo za čitanje odgovaraju na povezana pitanja, a njihovo poređenje lokalizuje problem brže od čitanja konfiguracije. Koristite stvarno interno ime i držite izlaz privatnim, jer interni zapisi ostaju interni. Pokrenite obje u istoj sesiji u kojoj radi program koji ne uspijeva:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Prva pita kroz konfigurisane module, što tipičan program doživljava. Druga pita systemd-resolved direktno i izvještava o linku, protokolu i serveru koji je odgovorio. Upit korporativnom serveru po adresi dokazuje samo da server drži zapis, jer ne govori ništa o tome da li ga je aplikacija ikada pitala. Pročitajte link koji nosi VPN i domene koje tvrdi, a zatim uporedite taj spisak sa sufiksom u imenu koje ne uspijeva.

Zašto .local zaobilazi vašu unicast zonu

referenca systemd-resolved-a navodi da višestruko označena imena koja završavaju na .local obično idu u multicast DNS kada je mDNS omogućen, a ne u obični unicast DNS. RFC 6762 odvaja taj imenski prostor za link-local multicast, pa korporativna zona može držati ispravan zapis koji se za taj sufiks nikada ne konsultuje. Tunel može savršeno rutirati razrješivač i ipak izgubiti trku. Uspješan ping iz keša ne govori ništa o traženju koje se upravo dogodilo.

Postoji dokumentovani izuzetak i on rješava većinu ovih slučajeva: kada link proglasi taj sufiks kao domenu za pretragu ili domenu za rutiranje, daemon ga zadržava na unicast putu i preskače poseban slučaj multicast-a. To je politika po linku, a ne globalna preferencija. Dvije mašine sa istim VPN serverom mogu se ponašati različito kada jedan mrežni profil proglašava domenu a drugi ne, zato čitajte aktivni profil, a ne onaj za koji se sjećate da ste ga uređivali.

Uski izuzetak pobjeđuje globalno preuređenje

Za postojeću zonu koju ne možete preimenovati, neka vlasnici razrješivača i VPN-a proglase domenu na vezi koja je nosi. Unos domene za rutiranje za taj jedan sufiks plus predviđena adresa servera je mala promjena sa imenovanim vlasnikom, i živi uz link, a ne u ručno uređenoj datoteci.

Ona također preživljava prekid veze, jer se politika linka ponovo primjenjuje kada se link vrati. Uređivanje zajedničkog nsswitch.conf je primamljiva i skuplja alternativa, jer mijenja ponašanje traženja za svako ime na mašini, uključujući lokalno otkrivanje. Onemogućavanje multicast daemona također nije ekvivalentno: uklanja lokalno ponašanje bez učenja bilo kojeg razrješivača o korporativnoj zoni. Ako je servis nov, a ne naslijeđen, stavite ga pod poddomenu koju kontroliše vaša organizacija i potpuno preskočite natjecanje. Odaberite uski izuzetak kada je ime fiksirano u firmveru ili odštampano na naljepnici, a novu poddomenu kada još kontrolišete klijenta.

Šta dokazati nakon promjene

Dokažite ispravku vlastitim traženjem aplikacije, a ne alatom koji ste instalirali za testiranje, i očistite svaki keš koji bi mogao odgovoriti umjesto nje. Zatim potvrdite put razrješivača i link koji je poslužio odgovor. Na kraju provjerite da se lokalno otkrivanje ponaša kao prije promjene, jer je štampač koji prestane da se pojavljuje dio koji ljudi primijete posljednji. Ove tri komande provjeravaju ime, put i TLS identitet tim redom:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Ispravna adresa sa pogrešnim certifikatom i dalje pada kod strogog klijenta, zato provjerite ime koje aplikacija očekuje kada razrješavanje proradi. Potvrdite da servis prihvata veze sa VPN adrese, a ne samo iz kancelarijskog opsega. Upišite obim domene, server i vlasnika u dokumentaciju veze. U suprotnom, sljedeća osoba koja naiđe na ovaj problem posegnut će za istom globalnom izmjenom koju ste upravo izbjegli.