Dva aktivní tunely IPsec stále potřebují plán zpětné cesty

Otevřete terminál na pracovní stanici na jednom místě a připojte se k serveru na druhém. Tato jediná konverzace TCP teď musí projít čtyřmi branami místo dvou a zajímavá část není, jestli to funguje v dobrý den. Zajímavá část je, kterou dvojici bran zvolil směr tam, kterou dvojici volí odpověď a kdo drží stav toku, zatímco se to děje. Nic v routovací tabulce to za vás nerozhodne.

Nakreslete čtyři brány, než nakreslíte trasu

Dvouaktivní návrh se dvěma nezávislými VPN firewally na lokalitu, jedna dvojice na poskytovatele, vám dá dvě použitelné cesty a tři způsoby, jak je rozbít. Zapište si adresy, než cokoli nakonfigurujete: klienta tak, jak je vidět před každou branou a za ní, server stejně, další přeskok tam a další přeskok zpět.

Ta tabulka je návrh. Vše po ní je otázka, zda zařízení s tabulkou souhlasí.

Jak se vybírá cesta tam

Vrstva multipath routingu se stejnými náklady rozděluje toky mezi další přeskoky hašováním polí hlavičky, což RFC 2992 popisuje podrobně. Tato volba může být zcela bezstavová: nepotřebuje záznam o sledování spojení, jen stabilní hash přes nezměněná pole. Udržujte množinu cest i vstupy hashe konstantní a každý paket toku zvolí stejný další přeskok.

Volba na tok zabraňuje přeskupení, které by způsobilo vyvažování paket po paketu na odkazech s různým zpožděním. Neslibuje, že stejné náklady routingu znamenají stejně měřenou latenci, protože neznamenají. A když se změní složení cest, toky se přemapují, takže přežití spojení během výpadku je samostatný požadavek od volby cesty.

Co zpětná cesta skutečně potřebuje

Tady procházka přestává být symetrická. Stabilní hash tam vám nic neřekne o tom, co vzdálené místo udělá s odpovědí. Pokud nezávislý firewall musí vidět oba směry spojení, aby udržel užitečný stav, zpětná trasa, která ho obchází, nechává provoz, který se s ničím neshoduje. Dvě krabice s podobnými sadami pravidel nejsou sdílený stav.

Potvrďte implementované obousměrné chování, nebo napište výslovnou politiku, která udrží požadované hranice soudržné. Domněnka se tu odhalí během výpadku, lidmi, které to nebaví.

Kde za vás rozhoduje překlad

NAT je druhá páka a je volitelný, nikoli povinný. Přeložené identity specifické pro cestu mohou směrovat odpovědi zpět k bráně, která drží stav, což je legitimní návrh. Přidávají ale mapování, zpětné trasy a vlastníka tohoto stavu, takže břemeno přijměte jen kvůli požadavku, který umíte vyslovit nahlas.

Pokud je požadavek prostě ten, aby obě cesty přenášely provoz a kterákoli přežila ztrátu poskytovatele, obvykle je menším návrhem prostý multipath na tok se soudržným zpětným routingem.

Projděte přejímku popořadě

Testujte v tomto pořadí a zaznamenávejte adresy v každém kroku: nové spojení na cestě A a jeho zpětná cesta, totéž na cestě B, pak ztráta jednoho poskytovatele, pak obnovení. U každého výsledku poznamenejte, které zavedené toky se přesunuly, které se musely znovu připojit a kam nové toky potom šly. Nejprve zapište očekávanou hodnotu, pak ji porovnejte se zachycením. Dva zavedené tunely nic z toho nedokazují.

Návrh je hotový, když tabulka, kterou jste napsali, odpovídá tomu, co ukazuje zachycení, ne když jsou oba tunely nahoře.