Systemd-resolvd funguje mizerne s VPN, protoze smicha originalni a VPN konfiguraci. Pokud chci vytvorit nekolik jmennych sitovych prostoru, kazdy s vlastni VPN, tak staci pred vytvorenim nakopirovat resolv.conf z initnet do /etc/netns/jmeno_prostoru/resolv.conf a kazdy jmenny prostor ziska nezavislou konfiguraci DNS. U systemd-resolvd je toto temer nemozne zaridit, protoze neni nikde popsane, co vsechno je treba duplikovat a navic ip podporuje pouze nahradu souboru v /etc, takze by to clovek musel resit vlastni konfiguraci mount jmeneho prostoru.
Prave naopak, systemd-resolved je jediny lokalny resolver, ktory funguje korektne s local-specific a zone-specific upstream resolvermi.
To, ze pomiesa "originalnu" a VPN "konfiguraciu" by default je v poriadku. Globalne DNS resolvery maju vracat rovnake odpovede. System sa moze spytat hociktoreho z nich a musi dostat rovnaku odpoved, takze pomiesanie nevadi. V tomto robi vacsina ludi chybu, ze si myslia, ze lokalny resolver sa bude pytat kazdeho z nich v poradi, az kym nedostane vysledok. Nebude.
Poznamka: toto je vytka k clanku. Medzi najvacsimi benefitmi systemd-resolved malo byt spomenute prave moznost link-specific a zone-specific resolverov. Linux v tom konecne dobehol... Windows. (macOS vie zone-specific, ale nie link-specific; takze kludne sa bude pytat resolvera na zonu, ku ktoremu je linka dole).
Takze ak ma VPN nejaku specificku zonu, treba ju nastavit. Napr. v NetworkManageri vlastnost "ipv4.dns-search" a zadat tam zony, ktore ma extra voci globalnemu resolveru.
`resolvectl query` zase zobrazi pre kazdy link a) "Current DNS Server", b) "DNS Servers" a c) "DNS Domain". A c) je presne to, ze na tuto zonu sa cez tento link sa bude pytat serverov v b), pricom zacne serverom a) - toho sa bude pytat dovtedy, kym query nebude mat timeout. Potom preskoci na dalsi v poradi.
Zkuste si to a pak napiste, jak jste byl uspesny. Nikde totiz neni popsano jak provozovat nekolik instanci najednou a podle me to ani nejde. Musel by se spustit plnohodnotny kontejner i se systemd, dbusem a tak. Pritom z normalnim resolverem je tento scenar trivialni, jak pisu ve svem prvnim prispevku na toto tema.
systemd-resolved umožňuje nadefinovat search domain a routy. Pokud je netns dostupný z systemd-resolved služby (což předpokládám), nic tomu nebrání to řídit přes routy, tak to i děláme.
Popsané to je třeba tdy https://systemd.io/RESOLVED-VPNS/
Musím říct, že naopak s systemd-resolved hromadu problémů ubylo, zejména na stanicích, kde uživatelé přeskakují mezi více sítěmi a chodí všude možně. Na serverech nám to je jedno, tam je konfigurace sejně řízená a spíše statická, dotazy jsou cachované v infra tak nebo tak
Nepopisoval jsem problem s preskakovanim mezi VPN, ale s provozem nekolika VPN najednou. Momentalne mam pro kazdou VPN vlastni jmenny prostor a pres /etc/netns/ ma kazda VPN "svuj" resolv conf. Kdyz chci pote prohlizet stranky pres VPN1, udelam ip netns exec VPN1 firefox. Firefox pote prohlizi stranky a pouziva DNS, ktere nastavilo DHCP z VPN1 (takze mi funguje intranet). Ve stejnou chvili chci udelat ssh na stroj ve VPN2, tak udelam ip netns exec VPN2 bash a v nem pak treba ssh interni_jmeno a interni_jmeno se mi prelozi na DNS, ktere nakonfigurovale dhcp na VPN2. Delat to stejne se systemd-resolved, je asi tak pohodlne, jako drbat se za uchem skrz zadek.
Takže máš postavené něco vlastního?
Pokud ti nevadí, že o všech překladech bude vědět systémový systemd-resolved, tak přes domain search a routy můžeš nasměrovat překlady z VPN1 do nameserverů v netns pro VPN1 (samozřejmě si musíš buď přidat routování nebo překlad do netns). Firefox si pak adresy přeloží a jen on bude v síti, kde budou dané IP adresy.
Pokud to chceš úplně odstínit nebo je tam takový chaos v doménách, že domain search nelze aplikovat, tak pro tebe systemd-resolved není a prostě si v udržuj upravený resolv.conf uvnitř netns a nic se ti nemění nebo si můžeš provozovat jinou službu v netns, která ti ten překlad zajistí. Tak to dělám na svém počítači pro více VPN já, každá má svůj snadbox a nechci to míchat.