Oddělený výstup: VPN pool na usb0, provoz brány na eth0

Klienti se připojí a ověří, a pak jejich provoz odchází špatným uplinkem, protože jediná výchozí cesta na stroji patří samotné bráně. Nahrazení této výchozí cesty by rozbilo vlastní aktualizace stroje a přístup pro správu, takže výběr musí být užší než „veškerý provoz“. Fungující podoba je pravidlo politiky navázané na vnitřní zdrojovou adresu klientského poolu, které ukazuje na druhou směrovací tabulku, jež vlastní alternativní WAN. Odtud dál je kontrolní seznam o úplnosti a chování při poruše, ne o pravidlu samotném.

Ověřte, že zdrojová adresa přežije až do rozhodnutí o směrování

Pravidlo politiky, které odpovídá rozsahu zdroje, se aktivuje jen tehdy, když paket v okamžiku vyhledávání ještě nese tento zdroj. Přesměrovaný klientský provoz to splňuje, dokud ho nic výš po cestě nepřepsalo před směrováním. Provoz, který generuje brána, to nesplňuje, a právě proto může její vlastní výchozí cesta zůstat tam, kde je.

Tady lokální testy svádějí. Spuštění curl na bráně je lokálně vytvořený tok s adresou brány, takže vezme hlavní tabulku a o klientské cestě nic nedokazuje. Testujte z připojeného klienta, nebo generujte provoz se zdrojem, který do poolu skutečně patří.

Začněte tím, že zapíšete skutečné hodnoty: prefix poolu, tunelové rozhraní, které ho nese, adresu a další skok druhého WAN a číslo tabulky, kterou chcete použít. Před přidáním nových pravidel vyčistěte stará pravidla z každého předchozího pokusu, protože duplikovaná pravidla s různými prioritami vytvářejí poruchy, které vypadají náhodně.

Sestavte vybranou tabulku, která je úplná

Tabulka není výchozí cesta s kamarádem. Potřebuje dost cest, aby se každé vyhledávání vyřešilo uvnitř ní, včetně připojené cesty pro podsíť WAN, aby byl další skok dosažitelný. Pro pool 10.77.0.0/24 na tun1, adresu WAN 203.0.113.20/24 s dalším skokem 203.0.113.1 a tabulku 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Pravidlo stojí na prioritě pod jakýmkoli existujícím pravidlem chytajícím vše, takže odpovídající klienti nejdřív trefí tabulku 600 a všechno ostatní propadne do hlavní tabulky. Reference ip-rule úplně popisuje model řazeného vyhledávání a syntaxi selektoru.

Pak popřemýšlejte, co tabulka neobsahuje. Cíl, který má cestu jen v hlavní tabulce, třeba podsíť pro správu dostupná přes eth0, se v tabulce 600 nenajde a nevrátí se do hlavní, jakmile tam výchozí cesta existuje. Pokud na těch cestách záleží, přidejte je do vybrané tabulky výslovně, což je obvykle správná odpověď pro tabulku výstupu VPN.

Držte vlastní provoz naslouchače mimo politiku

Naslouchač OpenVPN má vlastní vnější spojení, nesené tím uplinkem, kterým se k němu klient dostal. Tento provoz si musí zachovat zpětnou cestu, se kterou přišel, a široké pravidlo pokrývající veřejnou adresu serveru nebo celé tunelové rozhraní ho může stáhnout do alternativní tabulky. Omezte pravidlo na vnitřní pool a nic jiného.

Filtrování zpětné cesty si zaslouží pohled ze stejného důvodu. Když odpovědi klientům odcházejí přes usb0, zatímco požadavek přišel jiným spojem, přísné nastavení rp_filter může zahodit pakety, které směrovací politika považuje za platné. Než usoudíte, že pravidlo selhalo, zkontrolujte platné hodnoty sysctl na obou rozhraních.

Pořadí je důležité i vůči všemu ostatnímu na stroji. Docker mosty, druhý VPN a jakákoli dřívější pravidla z image poskytovatele přidávají priority, takže přečtěte si celý seznam pravidel, místo abyste předpokládali, že priorita 100 je sama.

Slaďte předávání a překlad s cestou

Směrování vybírá uplink; nedává povolení k předávání. Jádro musí mít zapnuté předávání IPv4 a firewall musí přijímat směr od klienta k WAN i zpětný provoz. Správná tabulka s řetězem FORWARD, který tok zahodí, dává stejný příznak jako chybějící cesta, a proto se obojí kontroluje v jednom průchodu.

Pokud druhý WAN nebude směrovat soukromý pool zpět k vám, přeložte zdroj na tomto výstupu. Pro rozhraní s dynamickou adresou je obvyklou volbou úzké pravidlo masquerade omezené na pool a rozhraní:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Rozsah je tu důležitější než cíl. Pravidlo masquerade odpovídající jakémukoli odchozímu rozhraní přepíše i provoz, který správně odchází přes eth0, a to skrývá chyby směrování místo toho, aby je opravilo. Překlad běží až po rozhodnutí o směrování, takže nikdy nemůže opravit paket odeslaný špatným uplinkem.

Režie tunelu si také žádá pozornost, jakmile se cesty liší. Pokud si klienti vyjednají velký TCP MSS a alternativní WAN má nižší MTU nebo v sobě tunel, velké segmenty se zaseknou, zatímco malé fungují. Oříznutí MSS na cestě předávání z toho udělá předvídatelné chování místo občasného zaseknutí.

Rozhodněte, co se stane, když usb0 zmizí

Prázdná tabulka není stav zavření při poruše. Pokud odpovídající cesta zmizí, vyhledávání pokračuje na další pravidlo, dostane se do hlavní tabulky a vezme výchozí cestu eth0. Provoz, který měl odejít druhým WAN, tiše odejde prvním, což je u nasazení se směrováním podle politiky obvykle výsledek, který chcete nejméně.

Kde je tento návrat nepřijatelný, přidejte do tabulky 600 výslovnou terminální cestu, třeba výchozí cestu blackhole, nebo zahoďte pool ve firewallu, dokud je rozhraní dole. Každá z těch voleb je rozhodnutí, které můžete zapsat; mlčení není.

Trvalost je poslední položka. Kdo vlastní obě linky, ať je to správce sítě, dispatcher skript nebo životní cyklus připojení, musí při každém opětovném připojení znovu vytvořit cesty a pravidlo, aniž by přidával duplikáty. Ověřte požadavkem z reálného klienta a samostatným požadavkem z brány, potvrďte pozorovaný výstup u obou, pak vytáhněte druhý WAN a sledujte, který ze dvou navržených výsledků skutečně nastane. IPv6 potřebuje vlastní tabulku, pravidlo a překlad; pravidlo pro IPv4 výše o něm nic neříká.