IPsec v IPsec: ktoré adresy musí niesť vonkajší tunel
Dajte vonkajšiemu tunelu adresy vnútorných brán, nie podsiete aplikácií. Potom dokážte preposielanie, preklad a MTU na každej vrstve, kým to nazvete vnoreným.
Vnorený IPsec sa ľahšie premýšľa, keď obe vrstvy končia na rôznych strojoch. Štyri brány, dva tunely a jediná otázka, ktorá rozhoduje, či návrh funguje: čo vonkajší tunel skutočne vidí, keď vnútorný skončí s packetom? Odpovedzte na ňu a selektory, trasy i poradie riešenia problémov vyplynú. Pomýlite sa a strávite deň ladením tunela, ktorý je technicky aktívny.
Model štyroch brán
Vonkajšie brány A a B stavajú prvý tunel medzi oboma lokalitami. Za A stojí vnútorná brána C s tranzitnou adresou 10.60.0.2; za B stojí vnútorná brána D s tranzitnou adresou 10.70.0.2. Aplikačné siete žijú za C a D a každá adresa v príklade sa zámerne neprekrýva.
application net -> C -> A == outer IPsec == B -> D -> application net
\---------- inner IPsec ----------/
C transit: 10.60.0.2 D transit: 10.70.0.2
A and B: underlay addresses only
Rozdelenie vrstiev na štyri hostiteľe znamená, že každý stroj vynucuje jednu hranicu. Jeden hostiteľ prevádzkujúci obe vrstvy musí zladiť dve sady politík, dve routovacie tabuľky a dva režimy zlyhania na jednom stroji, čo je možné a oveľa ťažšie pozorovateľné.
Každá vrstva odstraňuje len svoju vlastnú ochranu
C šifruje aplikačný packet pre D. Výsledok je adresovaný z C do D a to je to, čo dorazí k A. Všetko nižšie závisí od tohto prepisu.
A ho znova zašifruje pre B. B dešifruje vonkajšiu vrstvu, vidí packet z C do D a preposiela ho stále zašifrovaný. D odstráni vnútornú ochranu a doručí aplikačný packet.
A a B teda vidia vnútorné koncové body a ich metadáta, ale nie sú stranami, ktoré dešifrujú aplikačný payload. To je skutočná vlastnosť návrhu, nie tvrdenie, že C, D alebo aplikačné hostiteľe sú dôveryhodné.
Vonkajšie selektory pomenúvajú vnútorné brány
Tu zlyháva väčšina týchto stavieb. Pri vonkajšom tuneli založenom na politikách musia selektory, ktoré vyjednávate, obsahovať adresy, s ktorými A a B skutočne pracujú: 10.60.0.2/32 a 10.70.0.2/32, v správnom lokálnom a vzdialenom poradí.
Umiestnenie konečných aplikačných podsietí do vonkajších selektorov nefunguje, pretože kým packet dorazí k A, vnútorné zapuzdrenie už prepísalo to, čo A musí chrániť. Vonkajšia politika by potom ničomu nezodpovedala a tunel by sa zdvihol bez prenosu dát.
Nezužujte vonkajšie povolenie na UDP 500. Vnútorné spojenie má vlastnú dátovú cestu, ktorá používa ESP alebo UDP zapuzdrenie podľa toho, čo vyjednalo, a vonkajšia politika musí tento protokol povoliť.
Výsledok overte pomocou swanctl --list-sas na každej bráne a potvrďte, že podriadené bezpečnostné asociácie hlásia adresy, ktoré ste zamýšľali, nie tie, ktoré ste predpokladali. Ak zoznam ukazuje aplikačné podsiete, vonkajšia politika bola napísaná pre nesprávnu vrstvu. Opravte selektory skôr, než začnete ladiť routing, pretože routing bude vyzerať dobre a počítadlá sa nepohnú.
Preposielanie a pasca rekurzie
Selektory nenahrádzajú routing. A a B musia preposielať prevádzku medzi C a D v oboch smeroch, čo znamená zapnuté preposielanie IP, trasy ukazujúce na tunel a spätnú cestu, ktorá na druhej strane existuje.
Ak vonkajší tunel používa rozhrania XFRM, trasy vyberajú rozhranie, zatiaľ čo vyjednané politiky stále obmedzujú, čo prenáša. Rozhranie nerozširuje chránené; len mení, ako kernel packet zachytí.
Pascou je rekurzia. Trasa A k vonkajšiemu koncovému bodu B musí nasledovať underlay, nie tunel, ktorý A stavia, inak sa zapuzdrenie pokúsi cestovať vnútri seba a spojenie sa nikdy nedokončí.
Preskúmajte preklad skôr, než pridáte vrstvy
Pozrite sa na akýkoľvek source NAT na A a B skôr, než čokoľvek iné vyladíte. Pravidlo, ktoré prepíše adresu C pred aplikovaním politiky IPsec, môže rozbiť dohodnuté selektory a môže tiež zmeniť, čo D na druhej strane dostane.
Široké maskovanie nie je bezpečnejšie tým, že má dve vrstvy. Skrýva, ktorú adresu vzdialená strana vidí, a to je presne informácia, ktorú potrebujete, keď je tunel aktívny a aplikácia nefunguje.
Ak je pravidlo NAT skutočne potrebné, zapíšte, s ktorou adresou si každá strana myslí, že hovorí. Ten jeden riadok vyrieši väčšinu sporov o to, či je na vine tunel alebo preklad. Tiež povie ďalšiemu inženýrovi, kam sa pozrieť, keď bude pravidlo o rok odstránené. Ping nič z toho neurobí.
Dokážte fail-closed a skontrolujte MTU
Zmiznutie trasy samo o sebe nie je politika fail-closed. Iná tabuľka, predvolená trasa alebo pravidlo politiky môžu ticho poskytnúť záložnú cestu a jediný spôsob, ako to zistiť, je zhodiť vonkajší tunel a pozorovať, čo aplikačná prevádzka robí. Urobte to zámerne, v okne, namiesto toho, aby ste to objavili náhodou.
Otestujte tri stavy: vonkajší tunel dole, vnútorný tunel dole a obnovu po návrate oboch. Použite počítadlá politík na každej bráne, pretože dve nadviazané IKE relácie dokazujú len to, že vyjednávanie riadiacej roviny uspelo.
Naplánujte rozpočet pre obe zapuzdrenia. Fungujúci IKE je výsledok malých packetov a plnohodnotné aplikačné packety môžu stále zlyhať po pridaní dvoch hlavičiek; testujte so známou veľkosťou payloadu na skutočnej ceste, namiesto predpokladu, že čísla sedia. Aritmetika je ľahká, cesta nie.