VPN brána potřebuje IP forwarding: co zkontrolovat

Váš klient může pingnout adresu brány, zatímco všechny prostředky za ní zůstávají nedostupné. Tato dvojice pozorování popisuje hostitele, který s vámi mluví, a router, který neroutuje, což jsou různé role na stejném stroji. Forwarding je přepínač mezi nimi.

Obě role jsou nezávislé, a stejně tak obě rodiny adres.

Odpověď na vlastní adresu nic nedokazuje

Když je paket adresován samotné bráně, místní zásobník ho spotřebuje a žádné rozhodnutí o forwardingu neproběhne. Proto úspěšný ping na adresu tunelu nebo na správní rozhraní říká, že démon žije a tunel je nahoře, ale nic neříká o provozu určeném síti za krabicí. Jádro se na svou cestu forwardingu obrací jen u paketů, které nejsou adresovány jemu.

Čtěte požadavek jako roli, ne jako nastavení: tento hostitel musí přenášet pakety mezi dvěma rozhraními. Notebook, který potřebuje jen dosáhnout vzdálené sítě, tuto roli nikdy nepřebírá, a koncový bod site-to-site ji přebírá vždy. Takové čtení požadavku vysvětluje, proč funkční klientská konfigurace selže, když se přesune na bránu.

Totéž platí pro firewall před rozhodnutím o forwardingu, který má vlastní politiku o tom, co se smí forwardovat.

Zkontrolujte každou rodinu adres zvlášť

IPv4 forwarding je jeden přepínač a IPv6 forwarding je jiný, s vlastním chováním pro každé rozhraní. Zapnutí prvního nic neříká o druhém a klient s duálním zásobníkem může dosáhnout poloviny sítě, zatímco zbytek zůstává temný. Dva klienti různých rodin se proto mohou o stejné bráně neshodnout. Než upravíte kterékoli nastavení, zeptejte se, kterou rodinu selhávající klient použil. Potvrďte obě, než usoudíte, že návrh routingu je špatný.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

V mnoha distribucích hodnotu, kterou čtete za běhu, umístila služba nebo konfigurační soubor, takže změna provedená jednorázovým příkazem může při restartu zmizet. Než upravíte hodnotu za běhu, najděte soubor, který nastavení vlastní.

Forwarding je jeden ze čtyř požadavků

Funkční forwardovaný tok potřebuje čtyři věci najednou: klient musí vědět, že cíl je za tunelem, brána musí mít cestu dál, odpovědi musí mít cestu zpět a firewall musí provoz povolit. Překlad zdroje patří do tohoto návrhu jako volba, nikoli jako pravidlo, protože privátní routovaná síť se symetrickými cestami ho nepotřebuje a asymetrická obvykle ano. Každá ze čtyř selhává nezávisle, a proto oprava jedné jen zřídka pohne příznakem. Než kteroukoli změníte, zapište všechny čtyři.

Cloudové platformy přidávají pátý aspekt. Některé na instancích vynucují kontroly zdroje a cíle, což zahazuje forwardované pakety bez ohledu na to, co je kernel hosta nakonfigurován dělat. Autoritou je tam vlastní dokumentace platformy k síti, ne výstup sysctl uvnitř VM.

Testujte z klienta, ne z brány

Test spuštěný v samotném shellu brány neprojde žádnou částí cesty forwardingu, kterou jste právě povolili. Generujte provoz z klienta, který má problém, a potvrďte, že dosáhne něčeho za bránou, a ne brány samotné. To je jediný test, který procvičuje roli, kterou jste změnili.

Držte pravidla naslouchání a pravidla forwardingu odděleně v hlavě i v záznamu změn. Otevření portu VPN pustí klienty ke službě; v síti za ní jim nedává nic, a v seznamu firewallu, který roste roky, vypadají obě stejně.

Pokud pakety dorazí a služba pak uživatele odmítne, už jste za hranicí sítí. Pokračujte autorizací aplikace místo dalšího rozšiřování politiky forwardingu.