Zajistěte, aby přesměrování IPv4 vydrželo restart VPN brány

Ping na bránu funguje a dosažení čehokoli za ní ne, a to je podoba problému s přesměrováním, nikoli problému s tunelem. Místní doručení na bránu dokazuje, že tunel vznikl a přiřazení adresy fungovalo; neříká nic o tom, zda jádro předá paket z jednoho rozhraní na druhé. Než se dotknete jakéhokoli sysctl, ověřte, že stroj má tento provoz směrovat a najděte síťový kontext, který drží rozhraní obrácené ke klientovi. Potom hodnotu přečtěte tam, ne tam, kam náhodou koukl poslední přečtený návod.

Dosažení brány není totéž jako přesměrování

Uvnitř jádra probíhají dvě oddělená rozhodnutí. Doručení na místní adresu ukončuje cestu paketu; přesměrování ho znovu pošle jiným rozhraním a toto druhé rozhodnutí se řídí pro každý síťový jmenný prostor. Brána může být dokonale dostupná, zatímco přesměrování je vypnuté, a z příkazové řádky ping vypadají obě poruchy stejně.

Zapište, na kterém rozhraní klientský paket přichází a kterým rozhraním další cesta odchází. Obě patří jednomu jmennému prostoru a ten drží nastavení, na kterém záleží.

Přečtěte hodnotu tam, kde pakety skutečně jsou

Na bráně, která směruje v jmenném prostoru hostitele, na otázku odpovídá jediný příkaz: sysctl net.ipv4.ip_forward. Když vstupní a další cesta žijí v pojmenovaném jmenném prostoru, ptejte se jeho: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Hodnota hostitele není náhradou za hodnotu jmenného prostoru a jednička na hostiteli není důkazem ničeho.

Ne každý kontext směrování má štítek, který můžete předat do ip netns. Runtime kontejnerů a služby vytvářejí jmenné prostory, které se nikdy neregistrují pod přátelským jménem, a pro ty používejte nástroje pro inspekci runtime. Nahraďte vpn-gw skutečným jménem nebo mechanismem runtime, který dosáhne stejného kontextu, a přestaňte hádat na úrovni hostitele.

Dejte nastavení jediného vlastníka

Na běžné hostitelské bráně se systemd je trvalou podobou drop-in soubor s administrátorem zvoleným názvem, například /etc/sysctl.d/60-vpn-forwarding.conf, obsahující net.ipv4.ip_forward = 1. Soubor napište a poté načtěte právě tento soubor, aby se změnil i živý stav: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, následované zpětným čtením. Název souboru je příklad, nikoli vyhrazená cesta VPN, a úvodní číslo je důležité, protože soubory seřazené později vyhrávají.

Priorita je místo, kde se trvalost tiše láme. Zkontrolujte jak zavaděč distribuce, tak svůj drop-in, protože procps sysctl --system na konci také čte /etc/sysctl.conf, zatímco pořadí sysctl.d u systemd je zcela jiná posloupnost. Pozdější přiřazení může stejný klíč okamžitě vrátit, takže váš soubor zůstane správný a efektivní hodnota špatná. Nepřepisujte existující administrátorský soubor, abyste ten spor vyhráli; najděte vlastníka a změňte to tam.

Jmenný prostor vytvořený po zavedení se vůbec neřídí hostitelským drop-in souborem. Jeho nastavení patří tomu, co ho vytváří, ať už je to runtime kontejnerů, nebo jednotka pro zajištění jmenného prostoru. Dát kontejneru široká hostitelská oprávnění, aby se otázka obešla, je horší obchod než strávit deset minut hledáním správného vlastníka.

Zjistěte, co přepínač stojí, než ho přepnete

ip_forward není neškodný boolean. Dokumentace jádra uvádí, že jeho změna resetuje několik dalších parametrů IPv4 na výchozí hodnoty hostitele nebo routeru, takže diagnostické přepnutí může zahodit ladění provedené jinde a vůbec se o tom nezmínit. Berte to jako změnu konfigurace s vedlejšími účinky, ne jako sondu, kterou lze bezstarostně spustit.

To také vylučuje vypínání a zapínání při každé příležitosti, kdy se klient nedostane na hostitele. Pokud je hodnota už jednička, závada je jinde na cestě a přepsání stejného klíče potřetí s ním nepohne.

Dokažte trvalost a poté otestujte zbytek cesty

Přečtěte hodnotu zpět ve čtyřech okamžicích: hned po změně, po objevení rozhraní VPN, po opětovném připojení a po plánovaném restartu. Hodnota, která se v kterémkoli z těchto bodů vrátí, má druhého vlastníka, a další jednorázový zápis to jen skryje do příštího restartu.

Zapnuté přesměrování stále nechává tři věci k ověření. Klient potřebuje trasu k cíli, brána potřebuje další trasu plus oprávnění ji použít a cíl potřebuje zpáteční cestu k adrese klientského tunelu. Soukromá směrovaná LAN automaticky nepotřebuje NAT, takže nepřidávejte masquerading, dokud nezjistíte, která ze tří věcí chybí, a testujte z zamýšleného klienta, ne z brány samotné, protože požadavek vzniklý na bráně se nikdy nedotkne cesty přesměrování, kterou jste právě zapnuli. IPv6 má vlastní politiku přesměrování a směrování, takže funkční test IPv4 o ní nic neříká.

Držte cestu drop-in souboru, vlastníka jmenného prostoru a příkaz pro zpětné čtení pohromadě v runbooku. Kdo to převezme dál, má být schopen hodnotu přečíst, vidět, kdo ji vlastní, a během minuty rozhodnout, zda je problém v trvalosti, nebo ve zbytku cesty.