VPN mezi lokalitami založená na trasách vs. na politikách: co se liší
IPsec založený na politikách vybírá provoz selektorem; ten založený na trasách ho posílá přes rozhraní tunelu. Oba stále potřebují pravidla firewallu a zpětnou trasu.
Oba návrhy chrání stejný provoz stejným strojem IPsec a liší se tím, co rozhoduje, který paket vstoupí do tunelu. Ve spojení založeném na politikách to dělají vyjednané selektory provozu; ve spojení založeném na trasách to dělá trasa ukazující na rozhraní tunelu. Záměna obou vytváří známé vlákno podpory, v němž tunel hlásí, že je zřízen, ale aplikace se nikam nedostane. Rozdíl je nejdůležitější, když přidáváte síť, provozujete směrovací protokol nebo ladíte cestu, která tiše odchází nesprávným výstupem.
Dva způsoby rozhodování, co se dostane do tunelu
VPN založená na politikách sestavuje bezpečnostní politiku odpovídající prefixům zdroje a cíle a poté šifruje vše, co se hodí. Protistrana musí vyjednat kompatibilní selektory, takže efektivní rozsah nakonec tvoří průnik toho, co navrhly obě strany. Nic mimo tento průnik není chráněno, ať tabulka směrování říká cokoli.
VPN založená na trasách vytváří rozhraní, které představuje tunel, a nechává tabulku směrování posílat do něj provoz. Démon IKE stále instaluje stav a politiku pro každé rozhraní, a to je detail, který lidé přeskakují, když usoudí, že trasy nahradily šifrování. Oba návrhy šifrují pomocí IPsec; liší se jen mechanismus výběru.
Čtěte srovnání níže jako soubor příznaků selhání, a ne jako bodovací tabulku, protože žádný sloupec nevyhrává sám o sobě.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
Založený na politikách: selektor je smlouva
Selektory se vyjednávají, ne jen konfigurují. Navrhněte 10.10.0.0/16 na jedné straně a 10.10.1.0/24 na druhé, a asociace pokryje to, na čem se vyjednávání zastavilo, zatímco každý další host zůstane venku.
Čtěte nainstalovaný stav místo konfiguračního souboru. U partnera Linux jsou vlastní tabulky jádra základní pravdou a ukazují, co přežilo vyjednávání. Politika, která pojmenovává správné prefixy bez odpovídajícího stavu, znamená, že asociace nikdy nevznikla. Stav spárovaný s politikou pro nesprávný prefix je opačný problém a vytváří tunel, který vypadá zdravě, zatímco jedna podsíť se nikam nedostane.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasPorovnejte oba výstupy s prefixy, o kterých si myslíte, že je chráníte. To jediné srovnání řeší většinu hlášení o funkčním tunelu s nedostupným serverem. Ukazuje také, kterou stranu změnit, protože neshoda je obvykle viditelná jen v jednom směru.
Založený na trasách: rozhraní je smlouva
Rozhraní XFRM dává tunelu jméno a identitu a provoz se k němu dostane, protože to říká tabulka směrování. Několik vzdálených prefixů se pak stane problémem směrování a ne problému selektoru a směrovací protokol je může oznamovat. To je skutečný zisk, ne šifrování.
Rozhraní neodstraňuje potřebu politiky. Démon instaluje pravidla pro každé rozhraní vázaná na identitu rozhraní, takže paket přicházející na nesprávné rozhraní stále selhává. Selhává i zdrojová adresa, kterou partner nepřijme, a to i s dokonalou trasou. Založený na trasách znamená, že trasa rozhoduje o vstupu, ne že politika zmizela.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10Sledujte počítadla rozhraní, jakmile je trasa na místě. Trasa existuje, ale počítadla zůstávají na nule, což znamená, že se do tunelu nic nepřiřazuje, a to obvykle ukazuje na chybějící stav, a ne na chybějící trasu.
Kde se tyto dva návrhy opravdu rozcházejí
Přidání sítě je nejčistší test, který model vám sedí. Návrh založený na trasách přidá trasu a nanejvýš jednou rozšíří selektor, zatímco návrh založený na politikách upravuje páry prefixů na obou partnerech a znovu vyjednává. Dvě stabilní podsítě činí tuto úpravu triviální a dvacet z ní dělá projekt.
Ani jeden model nenahrazuje firewall a srovnání se obvykle zastaví před tímto bodem. Široký selektor nebo široká trasa rozhodují, co se šifruje, ne co je povoleno.
Chování MTU se v praxi také liší. Zapouzdření snižuje použitelnou zátěž a rozhraní založené na trasách nese vlastní MTU, takže sevření MSS na obou branách zabraňuje symptomu černé díry, kdy přicházejí malé odpovědi a velké mizí. Tunely založené na politikách narážejí na stejnou zeď z druhé strany, protože selektor nic neříká o velikosti paketu. Nastavte sevření záměrně, místo abyste obviňovali partnera.
Migrace bez ztráty zpětné cesty
Zaznamenejte existující páry prefixů, než cokoli změníte, potom přesuňte jednu cestu aplikace a sledujte ji od začátku do konce. Tunel, který se zřídí, není tunel, který předává, a rozdíl se projeví ve směru odpovědi.
Když se partneři připojí, ale hosté LAN ne, zkontrolujte zpětnou trasu a zdrojovou adresu, kterou vzdálený host použije. Host se dvěma rozhraními může odpovědět z nesprávného a žádná změna selektoru to neopraví. Zachyťte provoz na obou koncích, než začnete upravovat algoritmy.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsBěhem práce si ponechte řídicí cestu, která nezávisí na tunelu. Návrat je snazší, když vlastní přístup brány nejede po spojení, které ladíte.