Vaša VPN doména v dnsmasq nie je prenos zóny

Hľadáte firemnú zónu v konfigurácii dnsmasq klienta, nenájdete ju a usúdite, že VPN svoju doménu neposlala. To, čo bolo odoslané, je náznak smerovania, nie zóna. Klient zaznamená doménu a resolver, ktorý za ňu má odpovedať, a spravovaný backend z toho urobí podmienené preposielanie. Hľadanie na nesprávnom mieste dáva sebavedomú a úplne falošnú diagnózu.

To, čo klient prijal, nie je to, čo brána ponúkla

Brána môže ponúknuť resolver, doménu a trasu potrebnú na dosiahnutie tohto resolvera, a klient môže prijať všetky tri alebo žiadny z nich. Importovaný profil, pomocný skript alebo pravidlo, ktoré ignoruje odoslané voľby, môžu nechať prijatú množinu prázdnu, zatiaľ čo strana servera vyzerá správne. Začnite pri zaznamenanom stave klienta, nie pri konfigurácii servera, pretože tento stav je to, čo resolver skutočne dostáva. Ak prijatá doména chýba, nič ďalšie už nebude záležať. Pred preskúmaním akejkoľvek medzipamäte skontrolujte vlastnosti DNS pripojenia.

Tento rozdiel vysvetľuje väčšinu hlásení o doméne, ktorá nikdy nedorazila. Bola ponúknutá a nebola použitá.

Dva druhy položiek domény

Pripojenie môže niesť bežné vyhľadávacie domény a domény iba na smerovanie, pričom druhý druh začína vlnovkou. Vyhľadávacia doména smeruje dopyty a umožňuje rozbaľovanie krátkych mien, čo je pohodlné na pracovnej stanici a prekvapivé na serveri. Doména iba na smerovanie hovorí, že dopyty na túto príponu majú ísť na určité servery bez toho, aby sa menilo, ako sa krátke mená prekladajú. Písať rovnakú doménu oboma spôsobmi nie je nadbytočné, pretože obe položky robia rozdielne veci.

Pre súkromný menný priestor je zvyčajne žiaduca forma iba na smerovanie. Udržiava firemnú príponu nasmerovanú na firemný resolver a všetko ostatné necháva na pokoji.

localhost v resolv.conf nie je chyba

Keď sa používa miestny kešujúci resolver, systémový súbor ukazuje na adresu loopback a nič iné. Táto položka označuje miestneho počúvajúceho, nie upstream servery, ktoré mu správca odovzdal. Firemná adresa bude v súbore oprávnene chýbať.

Nahradiť túto položku verejným resolverom je klasická chybná oprava. Obnoví verejné prekladanie mien a v tej istej úprave zahodí podmienené pravidlo.

Nezamieňajte backendy

Spravovaná inštancia dnsmasq a systémový resolver sú rôzne programy s rôznou konfiguráciou a rôznymi pohľadmi na stav. Stavový príkaz pre jeden nehovorí nič užitočné o druhom.

Zistite, ktorý backend má správca používať, a potom čítajte vygenerovanú konfiguráciu tohto backendu, nie distribučný súbor, ktorý náhodou existuje. Správca zapisuje vlastnú konfiguráciu inštancie a podporuje vlastné voľby pre túto inštanciu, takže úprava nesúvisiaceho globálneho súboru nič nezmení a vyzerá ako zmena bez účinku. Spustenie druhého daemona na porte 53 je horšie ako zbytočné, pretože teraz sa dva programy nezhodujú, komu port patrí. Najprv určite vlastníka, potom upravujte tam, kde tento vlastník číta.

Testujte menný priestor, nielen odpoveď

Dotazujte sa na jedno povolené súkromné meno a jedno verejné kontrolné meno bežnou cestou aplikácie. Priamy dotaz na firemný server dokazuje, že záznam existuje; nedokazuje, že klient tento server vybral. Druhý dotaz je ten, ktorý testuje pravidlo.

Potom to zopakujte po opätovnom pripojení a po odpojení. Priradenie by malo sledovať životný cyklus pripojenia a súkromné mená by sa mali prestať prekladať, keď tunel zmizne, namiesto toho, aby sa vrátili k verejnému resolveru, ktorý odpovedá za rovnakú príponu. Ak sa predsa vrátia, našli ste únik, čo je iná chyba než pokazené vyhľadávanie. Zapíšte, ktorý backend bežal, ktoré domény boli použité a čo každý dotaz vrátil.