Vaša VPN domena u dnsmasq-u nije prijenos zone

Tražite korporativnu zonu u dnsmasq konfiguraciji klijenta, ne nalazite je i zaključujete da VPN nije poslao svoju domenu. Ono što je poslano je smjernica za usmjeravanje, a ne zona. Klijent bilježi domenu i resolver koji na nju treba odgovoriti, a upravljani backend to pretvara u uvjetno prosljeđivanje. Traženje na pogrešnom mjestu daje sigurnu i potpuno lažnu dijagnozu.

Ono što je klijent prihvatio nije ono što je gateway ponudio

Gateway može ponuditi resolver, domenu i rutu potrebnu da se do tog resolvera dođe, a klijent može prihvatiti sve tri ili nijednu od njih. Uvezeni profil, pomoćna skripta ili pravilo koje ignorira poslane opcije mogu ostaviti prihvaćeni skup praznim dok serverska strana izgleda ispravno. Pođite od zabilježenog stanja klijenta, a ne od konfiguracije servera, jer to stanje je ono što resolver zapravo prima. Ako prihvaćena domena nedostaje, ništa dalje niz lanac neće biti važno. Provjerite DNS svojstva veze prije nego što pregledate bilo koji cache.

Ta razlika objašnjava većinu izvještaja o domeni koja nikada nije stigla. Bila je ponuđena i nije primijenjena.

Dvije vrste unosa domene

Veza može nositi obične domene za pretragu i domene samo za rutiranje, a druga vrsta počinje tildom. Domena za pretragu i usmjerava upite i dopušta širenje kratkih imena, što je zgodno na radnoj stanici i iznenađujuće na serveru. Domena samo za rutiranje kaže da upiti za taj sufiks trebaju ići na određene servere bez promjene načina na koji se kratka imena rješavaju. Pisanje iste domene na oba načina nije suvišno, jer dva unosa obavljaju različite poslove.

Za privatni prostor imena oblik samo za rutiranje je obično onaj koji želite. On drži korporativni sufiks usmjeren na korporativni resolver i ostavlja sve ostalo na miru.

localhost u resolv.conf nije greška

Kada se koristi lokalni keširajući resolver, sistemska datoteka pokazuje na loopback adresu i ništa drugo. Taj unos označava lokalnog slušatelja, a ne uzvodne servere koje mu je upravitelj predao. Korporativna adresa će opravdano nedostajati u datoteci.

Zamjena tog unosa javnim resolverom klasična je pogrešna popravka. Ona vraća javno razrješavanje imena i odbacuje uvjetno pravilo u istoj izmjeni.

Ne miješajte backendove

Upravljana dnsmasq instanca i sistemski resolver različiti su programi s različitom konfiguracijom i različitim prikazima statusa. Statusna naredba za jedan ne govori ništa korisno o drugom.

Utvrdite koji backend je upravitelj konfiguriran da koristi, pa pročitajte generiranu konfiguraciju tog backenda umjesto distribucijske datoteke koja slučajno postoji. Upravitelj piše vlastitu konfiguraciju instance i podržava prilagođene opcije za tu instancu, pa uređivanje nepovezane globalne datoteke ne mijenja ništa i izgleda kao promjena bez učinka. Pokretanje drugog daemona na portu 53 gore je od beskorisnog, jer se sada dva programa ne slažu oko toga kome pripada port. Prvo utvrdite vlasnika, a zatim uređujte tamo gdje taj vlasnik čita.

Testirajte prostor imena, ne samo odgovor

Upitajte jedno dopušteno privatno ime i jedno javno kontrolno ime kroz uobičajeni put aplikacije. Izravan upit prema korporativnom serveru dokazuje da zapis postoji; ne dokazuje da je klijent odabrao taj server. Drugi upit je onaj koji testira pravilo.

Zatim ponovite nakon ponovnog spajanja i nakon prekida veze. Povezivanje treba slijediti životni ciklus veze, a privatna imena trebaju prestati rješavati kada tunel nestane, umjesto da se vraćaju na javni resolver koji odgovara za isti sufiks. Ako se ipak vraćaju, pronašli ste curenje, što je druga greška od pokvarenog pretraživanja. Zapišite koji je backend radio, koje su domene primijenjene i što je svaki upit vratio.