Kdo vlastní adresu, trasu, DNS a firewall na linuxovém VPN?

Dva skripty, které se přou o stejnou trasu, jsou obvyklou podobou problému s linuxovým VPN, který se eviduje jako chyba směrování. Jedna komponenta vytvoří tunelové zařízení, druhá přidá výchozí trasu, třetí přepíše konfiguraci resolveru a čtvrtá znovu načte pravidla firewallu. Kterákoli z nich může zrušit práci jiné a vítězem je prostě ta, která se spustila poslední. Otázka, na kterou stojí za to odpovědět, není který balíček nainstalovat, ale která komponenta je autoritativní pro každou část stavu.

Zapište tu mapu jednou a většina selhání při opětovném připojení přestane být záhadná. Na čem záleží, jsou čtyři objekty: zařízení a jeho adresy, trasy a pravidla zásad, konfigurace DNS a firewall.

Zařízení a jeho adresy

Tunelové zařízení vytváří buď správce, který zná profil, nebo démon, kterého někdo spustil ručně. Obě uspořádání fungují sama o sobě; jejich míchání ne. Pokud profil vlastní NetworkManager, ať vlastní i zařízení, a nespouštějte neřízený OpenVPN proces proti stejnému názvu tunelu.

Zaznamenejte, kdo zařízení odstraní, když relace skončí. Zařízení, které přežije svou relaci, je nejčastějším zdrojem zastaralých adres a zmatku, který je následuje.

Trasy a pravidla zásad

Právě na trasách působí konflikty vlastnictví viditelné škody. Správce připojení nainstaluje výchozí trasu pro tunel plus konkrétnější trasu pro vzdálenou síť; ručně psaný skript pak přidá svou vlastní výchozí trasu s jinou metrikou a tiše vyhraje nebo prohraje podle načasování. Rozhodněte, které položky jsou vázané na připojení, které jsou trvalou zásadou a která komponenta je po opětovném připojení obnoví. Pak držte ostatní komponenty mimo tuto tabulku.

Pravidla zásad si zaslouží stejnou jasnost, protože pravidlo ukazující na tabulku, kterou nikdo neplní, vytváří černou díru, která vypadá přesně jako mrtvý tunel. Pokud pravidlo existuje proto, aby někam dotlačilo provoz, musí tabulku, kterou vybírá, udržovat stejný vlastník.

DNS má vždy samostatného vlastníka

Démon resolveru běží jako vlastní proces pod vlastní identitou, takže nedědí směrovací rozhodnutí tunelu omylem. Když VPN protlačí servery DNS, něco to musí přeložit do konfigurace pro každé spojení, kterou resolver respektuje, a něco to potom musí zase odebrat.

Mýtus zde je, že zápis jmenného serveru do profilu mění, kam dotazy jdou. Mění, co se resolveru řekne, ne který socket resolver používá směrem ven. Testujte dotazem plus vyhledáním trasy místo důvěry v soubor.

Stav firewallu a kdo ho obnovuje

Pravidla firewallu jsou nejčastěji přepisovaným objektem na hostiteli VPN. Správce může přidávat pravidla NAT nebo přesměrování pro každé připojení, zatímco služba firewallu při startu znovu načte uloženou sadu pravidel a smaže je. Zvolte jednu autoritu pro zásady a udělejte z druhé jejího spotřebitele, nebo přijměte, že restart tiše mění chování. Výjimky vázané na připojení patří do souboru, který načítá stejný vlastník, ne do příkazu iptables napsaného při řešení potíží.

Pokud pravidla musí přežít opětovné připojení, řekněte to výslovně. Pokud ne, řekněte to také, protože další inženýr předpokládá pohodlnější odpověď.

Životní cyklus: start, opětovné připojení, rozebrání

Dejte každému z těch tří okamžiků vlastníka. Při startu rozhodněte, co připravuje předpoklady a v jakém pořadí. Při měkkém restartu si pamatujte, že zařízení může přežít, zatímco stav relace ne, takže musí běžet validátor, ne tvůrce. Při rozebrání odstraňte jen to, co vytvořilo toto připojení, protože resetování všech tras nebo vyčištění celého firewallu není totéž jako vyřazení jednoho tunelu.

Pro pozorování ip monitor link address route ukazuje změny jádra, jak se dějí, ale hlásí události, nikoli záměr: smazaná trasa nic neříká o tom, který proces ji smazal. Spojte to s mapou vlastnictví a matoucí vypnutí se změní v krátký seznam kandidátů.

Výjimky mají také svou cenu. Označení celé třídy zařízení jako neřízené, abyste unikli konfliktu, předá tento stav nikomu, což je rozhodnutí, nikoli oprava.