Proč net.ipv4.conf.default.forwarding nechává tun0 na pokoji

Nastavili jste net.ipv4.conf.default.forwarding=1, restartovali VPN a tunel přesto zahazuje pakety, které by brána měla směrovat. Nastavení v souboru vypadá správně a rozhraní stále hlásí, že přeposílání je vypnuté. Nic není rozbité: změnili jste hodnotu, kterou dědí budoucí rozhraní, ne tu, kterou používá živý tunel.

Projděte to na hostiteli, který tunel vlastní, v síťovém namespace, kde tunel skutečně existuje. Kontejner nebo síťový namespace může rozhraní držet, zatímco hostitel ukazuje jiná čísla.

Čtěte tři hodnoty společně

Začněte porovnáním přepínače platného pro celou bránu, šablony pro nová rozhraní a rozhraní, které vás zajímá. Nahraďte tun0 skutečným vstupním rozhraním a přečtěte si i návratové rozhraní, protože přeposílání se vyhodnocuje v místě, kde paket dorazí.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Častý výsledek je ip_forward = 0, default.forwarding = 1 a tun0.forwarding = 0. První dvě se neshodují v tom, jakou roli hostitel má, a třetí ukazuje, co rozhraní skutečně dělá. Taková kombinace odpovídá hostiteli, který nebyl nikdy nakonfigurován jako router a dostal jen hodnotu ze šablony. Tři čísla si neodporují; odpovídají na tři různé otázky. Ani zápis hodnoty šablony nerozhoduje o roli hostitele.

Proč se hýbe právě globální přepínač

net.ipv4.ip_forward je ovládání platné pro celou bránu. Jeho změna aktualizuje nastavení přeposílání pro jednotlivá rozhraní jako součást stejné operace, a proto může jediný zápis přimět existující tunel začít přeposílat. default.forwarding osévá jen rozhraní, která se inicializují až potom, takže tunel, který už existoval, si drží hodnotu, se kterou se narodil.

Dokumentace jádra označuje ip_forward jako zvláštní z příbuzného důvodu: jeho změna resetuje sadu dalších parametrů IPv4 na výchozí hodnoty pro hostitele nebo router. Dělá z něj to tupý nástroj. Nastavit ho jednou v rámci zavedení role brány je v pořádku; přepínat ho opakovaně jako ladicí trik může tiše přepsat konfiguraci, kterou jste pracně ladili.

Hodnoty pro jednotlivá rozhraní mají také svůj důvod. Záměrně řízená brána může držet přeposílání vypnuté na rozhraní, které by nikdy nemělo směrovat, i když hostitel přeposílá jinde. Proto je důležité číst živé rozhraní a proto samotná globální hodnota není celá odpověď. Takovou výjimku čtěte jako vědomé rozhodnutí a zapište, čím se to rozhraní liší. Jinak ho příští inženýr ochotně "opraví".

Udělejte nastavení trvalým na správném místě

Úspěšný jednorázový sysctl -w dokazuje, že jádro hodnotu přijímá. Nepřežije restart ani síťového správce, který při opětovném připojení znovu uplatní svou představu o konfiguraci rozhraní. Dejte roli brány do konfiguračního souboru sysctl nebo do síťového správce, který hostitele vlastní a potom restartujte službu, která ji uplatňuje.

U tunelů záleží na pořadí. Pokud správce vytvoří rozhraní při startu a přeposílání uplatní až potom, může rozhraní zdědit starý default. Restart služby, která tunel znovu vytvoří, je také událostí vytvoření a snadno se přehlédne, když unit vypadá zdravě. Kontrolujte sled, ne jen konečný obsah souboru.

Přečtěte si stejné tři hodnoty znovu po opětovném připojení VPN a ještě jednou po restartu. Nově vytvořený tunel je nové rozhraní a nové rozhraní přebírá default platný v okamžiku vytvoření. Pokud se čísla mezi těmito událostmi mění, konfiguraci uplatňuje něco, co jste ještě neidentifikovali.

Neopravujte to špatným nástrojem

Když přeposílání vypadalo rozbité, láká to vyprázdnit firewall nebo přidat masquerading. Ani jedno se netýká přepínače přeposílání. Stav přeposílání, oprávnění přeposílat, trasa k cíli a zpětná cesta jsou čtyři samostatné požadavky a jen první z nich je sysctl.

Testujte také správným tokem. Požadavek zadaný na samotné bráně přeposílání vůbec necvičí; je to lokálně generovaný provoz. Otázka je, zda je paket přicházející z klienta VPN nebo z hostitele v LAN přijat a dále směrován, takže test musí vzniknout za bránou.

Držte případ IPv6 stranou

Tady je všechno IPv4. Přeposílání IPv6, oznámení routeru a chování accept_ra mají vlastní ovládání a zkopírování cesty ipv4 do nastavení ipv6 vytvoří soubor, který vypadá uvěřitelně a nedělá nic užitečného. Brána s duálním stackem potřebuje obě sady vědomě nakonfigurované.

Poslední kontrola: až se hodnoty shodnou, ověřte, že se pro cíl vybírá trasa tunelu a že zpětná cesta existuje. Přeposílání zapnuté na rozhraní bez trasy je pořád černá díra a toto selhání vypadá z pohledu klienta stejně.