Ktoré pripojenie odpovedá: smerovacie domény pre DNS split-tunnel VPN
Predvolená trasa a smerovacia doména DNS sú rôzne nastavenia. Pridajte suffix firmy s tildou, potom sa resolvectl opýtajte, ktoré pripojenie skutočne odpovedalo.
Bežné prehliadanie nechajte na lokálnom pripojení, kým sa názvy firmy prekladajú cez DNS server, ktorý dodáva tunel. Vypnutie predvolenej trasy VPN vám dá prvú polovicu a druhú nechá nepostavenú. Nasleduje chýbajúce nastavenie, interpunkcia, ktorá mení jeho význam, a jediný príkaz, ktorý ukáže, ktoré pripojenie skutočne odpovedalo. NetworkManager a systemd-resolved sa predpokladajú v celom texte, pretože práve táto dvojica býva začiatkom zmätku.
Prvý krok: oddeľte trasu od prekladača
ipv4.never-default odpovedá na otázku smerovania a bráni NetworkManageru nainštalovať toto pripojenie ako cestu pre všetku prevádzku IPv4. Smerovacia doména DNS odpovedá na inú otázku: ktoré názvové servery ktorého pripojenia dostanú dopyt pre zodpovedajúci suffix. Ani jedno neznamená druhé a profil môže roky niesť jedno, kým mu chýba druhé. Iba trasa znamená, že tunel nesie podsiete firmy a jeho prekladač odpovedá na názvy firmy, zatiaľ čo všetko ostatné zostáva nedotknuté.
Nastavte iba vlastnosť trasy a interné názvy zlyhajú, zvyčajne s časovým limitom, ktorý znie ako pokazený tunel. Nastavte iba doménu a ticho ste pridali vyhľadávací suffix ku každému krátkemu názvu na stroji. Obe chyby posielajú tiket na VPN server, ktorý je málokedy tou časťou, ktorá je zlá.
Druhý krok: pridajte do profilu doménu iba pre smerovanie
Predpokladajme, že pripojenie sa volá corp-vpn, suffix firmy je internal.example a prekladač tunela je už dostupný. Najprv si prečítajte aktuálne hodnoty, pretože príkazy nižšie menia vlastnosti, ktoré už môžu mať záznamy.
nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yesNahraďte vlastným názvom pripojenia a suffixom, pretože hodnoty vyššie sú ilustračné. Znamienko plus je dôležitejšie, než vyzerá: s ním sa hodnota pridá k existujúcemu zoznamu, bez neho sa vlastnosť nahradí a nesúvisiace domény zmiznú z profilu, ktorý včera fungoval. Tilda mení správanie, nie štýl, a odsek nižšie vysvetľuje, čo vyberá. Zachovajte čítanie pred zápisom, aby vás forma nahradenia nikdy neprekvapila.
Úvodná tilda označuje doménu iba pre smerovanie, takže zodpovedajúce dopyty idú na servery tohto pripojenia a suffix sa ku krátkym názvom nepridáva. Odstráňte tildu a ten istý reťazec sa stane aj vyhľadávacím suffixom, čo je iný výsledok, ktorý ľudia málokedy zamýšľajú. Obe nastavenia vyššie sú IPv4, takže profil s dvoma zásobníkmi potrebuje ipv6.never-default a rovnakú smerovaciu doménu v ipv6.dns-search, inak strana IPv6 ďalej používa predvolenú trasu a interné názvy tam zlyhávajú.
Tretí krok: opýtajte sa resolvectl, ktoré pripojenie odpovedalo
Spustite resolvectl status a prečítajte DNS servery a domény každého pripojenia, potom spustite resolvectl query host.internal.example na skutočné interné meno, ktoré smiete dopytovať. Druhý príkaz je jediný priamy dôkaz, že smerovacia doména robí svoju prácu, pretože pomenúva pripojenie, ktoré odpovedalo. Samotný zoznam stavu dokazuje konfiguráciu; dopyt dokazuje preklad.
systemd-resolved vyberá najlepšie zodpovedajúcu smerovaciu doménu, takže konkrétnejšia doména na inom pripojení môže preteky ešte vyhrať. Ak dopyt príde z pripojenia, ktoré ste nečakali, prečítajte si zoznamy domén, než sa dotknete DNS servera VPN. Koreňová doména ~. zodpovedá všetkému, a ak už existuje, vaša konkrétna doména pre svoje názvy stále vyhráva, kým pripojenie odpovedá na oveľa viac, než ste žiadali. Odstráňte alebo zúžte ten koreňový záznam, keď bolo zámerom iba názvy firmy.
Ak pripojenie VPN vôbec neuvádza DNS server, klient ho nikdy nezaregistroval. Smerovacia doména bez servera za sebou zlyháva inak ako chýbajúca doména, preto najprv opravte registráciu.
Štvrtý krok: keď sa názov preloží, ale služba nefunguje
Správna odpoveď dokazuje iba to, že preklad fungoval, a aplikácia stále potrebuje trasu k adrese, ktorú dostala. Táto trasa musí prežiť práve nastavenú rozdelenú predvolenú trasu, takže ju skontrolujte, než znova obviníte DNS. Potom skontrolujte dostupnosť na porte služby, pretože zdieľanie súborov alebo adresárová služba zlyháva pri preklade, smerovaní alebo autentifikácii a v každom prípade dáva veľmi podobné správy. Držte tieto tri vrstvy oddelené, keď hlásite výsledok, inak ďalší človek znova kontroluje DNS, ktoré už bolo správne.
Zmena v Sambe, ktorá koluje popri tejto otázke, sa týka prístupovej vrstvy, nie voľby DNS. Aplikovať ju na poruchu prekladu názvov je spôsob, akým malý problém získa druhý.
Piaty krok: nenahrádzajte prekladač, aby ste opravili chýbajúcu doménu
Rada, ktorá prepíše súbor prekladača alebo nainštaluje iného správcu prekladača, rieši iný problém. Sú to zmeny systémovej integrácie s vlastnými režimami zlyhania a žiadna z nich nepridáva smerovaciu doménu, ktorá nikdy nebola nakonfigurovaná. Určite, ktorý komponent vlastní preklad názvov na stroji, než ho nahradíte, pretože na pracovnej ploche s NetworkManagerom a systemd-resolved je toto vlastníctvo už definované. Boj proti nemu je spôsob, akým sa fungujúce nastavenie zmení na niečo, čo nikto nedokáže zopakovať.
Poradie práce: potvrďte, že tunel dodáva prekladač, pridajte doménu iba pre smerovanie, pripojte sa znova cez ovládacie prvky profilu, overte pripojenie, ktoré odpovedá, a potom otestujte službu na jej porte. Táto postupnosť zanechá výsledok, ktorý môžete odovzdať ďalšiemu človeku bez druhého rozhovoru.