Které spojení odpovídá: směrovací domény pro DNS VPN se split tunnelem

Ponechte běžné prohlížení na lokálním spojení, zatímco jména firmy se překládají přes DNS server, který dodává tunel. Vypnutí výchozí trasy VPN vám dá první polovinu a druhou nechá nepostavenou. Následuje chybějící nastavení, interpunkce, která mění jeho význam, a jediný příkaz, který ukáže, které spojení skutečně odpovědělo. NetworkManager a systemd-resolved se předpokládají v celém textu, protože právě v této dvojici zmatení obvykle začíná.

Krok první: oddělte trasu od překladače

ipv4.never-default odpovídá na otázku směrování a brání NetworkManageru nainstalovat toto připojení jako cestu pro všechen provoz IPv4. Směrovací doména DNS odpovídá na jinou otázku: které jmenné servery kterého spojení dostávají dotaz pro odpovídající suffix. Ani jedno neznamená druhé a profil může roky nést jedno, zatímco mu chybí druhé. Jen trasa znamená, že tunel nese podsítě firmy a jeho překladač odpovídá na jména firmy, zatímco vše ostatní zůstává nedotčené.

Nastavte jen vlastnost trasy a interní jména selžou, obvykle s časovým limitem, který vypadá jako rozbitý tunel. Nastavte jen doménu a tiše jste přidali vyhledávací suffix ke každému krátkému jménu na stroji. Obě chyby posílají tiket na VPN server, který je málokdy tou částí, jež je špatně.

Krok druhý: přidejte do profilu doménu jen pro směrování

Předpokládejte, že se připojení jmenuje corp-vpn, suffix firmy je internal.example a překladač tunelu je už dostupný. Nejprve si přečtěte aktuální hodnoty, protože příkazy níže mění vlastnosti, které už mohou mít 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 yes

Dosaďte své jméno připojení a suffix, protože hodnoty výše jsou ilustrativní. Znaménko plus je důležitější, než vypadá: s ním se hodnota připojí k existujícímu seznamu, zatímco bez něj se vlastnost nahradí a nesouvisející domény zmizí z profilu, který včera fungoval. Tilda mění chování, ne styl, a odstavec níže popisuje, co vybírá. Ponechte čtení před zápisem, aby vás forma nahrazení nikdy nepřekvapila.

Vedoucí tilda označuje doménu jen pro směrování, takže odpovídající dotazy jdou na servery tohoto spojení a suffix se ke krátkým jménům nepřipojuje. Odeberte tildu a stejný řetězec se stane i vyhledávacím suffixem, což je jiný výsledek, který lidé málokdy zamýšlejí. Obě nastavení výše jsou IPv4, takže profil s dvěma zásobníky potřebuje ipv6.never-default a stejnou směrovací doménu v ipv6.dns-search, jinak strana IPv6 dál používá výchozí trasu a interní jména tam selhávají.

Krok třetí: zeptejte se resolvectl, které spojení odpovědělo

Spusťte resolvectl status a přečtěte si DNS servery a domény každého spojení, pak spusťte resolvectl query host.internal.example na skutečné interní jméno, které smíte dotazovat. Druhý příkaz je jediný přímý důkaz, že směrovací doména dělá svou práci, protože pojmenovává spojení, které odpovědělo. Samotný výpis stavu dokazuje konfiguraci; dotaz dokazuje překlad.

systemd-resolved vybírá nejlépe odpovídající směrovací doménu, takže konkrétnější doména na jiném spojení může závod ještě vyhrát. Pokud dotaz přijde ze spojení, které jste nečekali, přečtěte si seznamy domén, než sáhnete na DNS server VPN. Kořenová doména ~. odpovídá všemu, a pokud už je přítomná, vaše konkrétní doména pro svá jména stejně vyhraje, zatímco spojení odpovídá na mnohem víc, než jste žádali. Odstraňte nebo zužte tento kořenový záznam, když byl záměr jen jména firmy.

Pokud spojení VPN vůbec neuvádí DNS server, klient žádný nikdy nezaregistroval. Směrovací doména bez serveru za sebou selhává jinak než chybějící doména, takže nejprve opravte registraci.

Krok čtvrtý: když se jméno přeloží, ale služba nefunguje

Správná odpověď dokazuje jen to, že překlad fungoval, a aplikace stále potřebuje trasu k adrese, kterou dostala. Tato trasa musí přežít rozdělenou výchozí trasu, kterou jste právě nastavili, takže ji zkontrolujte, než znovu obviníte DNS. Potom zkontrolujte dostupnost na portu služby, protože sdílení souborů nebo adresářová služba selhává při překladu, směrování nebo autentizaci a v každém případě dává velmi podobné zprávy. Držte tyto tři vrstvy oddělené, když hlásíte výsledek, jinak další člověk znovu kontroluje DNS, které už bylo správné.

Změna Samby, která koluje vedle této otázky, se týká vrstvy přístupu, ne volby DNS. Aplikovat ji na poruchu překladu jmen je způsob, jak malý problém získá druhý.

Krok pátý: nenahrazujte překladač, abyste opravili chybějící doménu

Rada, která přepíše soubor překladače nebo nainstaluje jiného správce překladače, řeší jiný problém. To jsou změny systémové integrace s vlastními režimy selhání a žádná z nich nepřidá směrovací doménu, která nikdy nebyla nakonfigurována. Určete, která komponenta vlastní překlad jmen na stroji, než ji nahradíte, protože na pracovní ploše s NetworkManagerem a systemd-resolved je toto vlastnictví už definované. Boj s ním je způsob, jak se fungující nastavení změní v něco, co nikdo nedokáže reprodukovat.

Pořadí práce: potvrďte, že tunel dodává překladač, přidejte doménu jen pro směrování, připojte se znovu přes ovládací prvky profilu, ověřte odpovídající spojení a potom otestujte službu na jejím portu. Tato posloupnost zanechá výsledek, který můžete předat dalšímu člověku bez druhého pohovoru.