Jou VPN-domein in dnsmasq is nie ’n sone-oordrag nie

Jy soek die korporatiewe sone in die kliënt se dnsmasq-konfigurasie, kry dit nie, en maak die gevolgtrekking dat die VPN versuim het om sy domein te stoot. Wat gestoot is, is ’n roete-hint, nie ’n sone nie. Die kliënt teken die domein en die resolveerder aan wat daarop moet antwoord, en die bestuurde backend verander dit in voorwaardelike aanstuur. Om op die verkeerde plek te kyk lewer ’n selfversekerde en heeltemal valse diagnose.

Wat die kliënt aanvaar het, is nie wat die gateway gebied het nie

’n Gateway kan ’n resolveerder, ’n domein en die roete bied wat nodig is om daardie resolveerder te bereik, en die kliënt kan al drie of nie een daarvan aanvaar nie. ’n Ingevoerde profiel, ’n hulpscript of ’n beleid wat gestootde opsies ignoreer, kan die aanvaarde stel leeg laat terwyl die bedienerkant korrek lyk. Begin by die kliënt se aangetekende toestand eerder as by die bediener se konfigurasie, want daardie toestand is wat die resolveerder werklik ontvang. As die aanvaarde domein ontbreek, sal niks daarna saak maak nie. Kontroleer die verbinding se DNS-eienskappe voordat jy enige kas ondersoek.

Daardie onderskeid verklaar die meeste verslae van ’n domein wat nooit opgedaag het nie. Dit is aangebied, en dit is nie toegepas nie.

Twee soorte domeininskrywings

’n Verbinding kan gewone soekdomeine en slegs-roete-domeine dra, en die tweede soort begin met ’n tilde. ’n Soekdomein stuur beide navrae en laat kort name uitbrei, wat gerieflik op ’n werkstasie is en verrassend op ’n bediener. ’n Slegs-roete-domein sê dat navrae vir daardie agtervoegsel na spesifieke bedieners moet gaan sonder om te verander hoe kort name opgelos word. Om dieselfde domein op albei maniere te skryf is nie oorbodig nie, want die twee inskrywings doen verskillende take.

Vir ’n private naamruimte is die slegs-roete-vorm gewoonlik die een wat jy wil hê. Dit hou die korporatiewe agtervoegsel na die korporatiewe resolveerder gerig en laat alles anders alleen.

localhost in resolv.conf is nie ’n fout nie

Wanneer ’n plaaslike kasresolveerder in gebruik is, wys die stelsellêer na die loopback-adres en niks anders nie. Daardie inskrywing identifiseer die plaaslike luisteraar, nie die opstroombedieners wat die bestuurder daaraan gegee het nie. Die korporatiewe adres sal wettiglik afwesig wees uit die lêer.

Om daardie inskrywing met ’n openbare resolveerder te vervang, is die klassieke verkeerde oplossing. Dit herstel openbare naamoplossing en gooi die voorwaardelike beleid in dieselfde wysiging weg.

Moenie die backendse verwar nie

’n Bestuurde dnsmasq-instansie en ’n stelselresolveerder is verskillende programme met verskillende konfigurasie en verskillende status-aansigte. ’n Statusopdrag vir een rapporteer niks nuttigs oor die ander nie.

Identifiseer watter backend die bestuurder gekonfigureer is om te gebruik, en lees dan daardie backend se gegenereerde konfigurasie eerder as ’n distro-wye lêer wat toevallig bestaan. Die bestuurder skryf sy eie instansie-konfigurasie en ondersteun pasgemaakte opsies vir daardie instansie, so om ’n onverwante globale lêer te wysig verander niks en lyk soos ’n verandering met geen effek nie. Om ’n tweede daemon op poort 53 te begin is erger as nutteloos, want nou is twee programme dit oneens oor wie die poort besit. Stel eers die eienaar vas, wysig dan waar daardie eienaar lees.

Toets die naamruimte, nie net die antwoord nie

Vra een toegelate private naam en een openbare kontrole-naam deur die toepassing se normale pad. ’n Direkte navraag teen die korporatiewe bediener bewys die rekord bestaan; dit bewys nie die kliënt het daardie bediener gekies nie. Die tweede navraag is die een wat beleid toets.

Herhaal dan ná ’n herverbinding en ná ’n ontkoppeling. Die assosiasie moet die verbinding se lewensiklus volg, en die private name moet ophou opgelos word wanneer die tonnel weg is, eerder as om terug te val op ’n openbare resolveerder wat vir dieselfde agtervoegsel antwoord. As hulle wel terugval, het jy ’n lek gevind, wat ’n ander defek is as ’n gebroke opsoek. Skryf neer watter backend gehardloop het, watter domeine toegepas is en wat elke navraag teruggegee het.