IPsec în IPsec: ce adrese trebuie să transporte tunelul exterior

IPsec imbricat este mai ușor de analizat când cele două straturi se termină pe mașini diferite. Patru gateway-uri, două tuneluri și o singură întrebare care decide dacă designul funcționează: ce vede de fapt tunelul exterior când cel interior a terminat cu pachetul? Răspundeți la asta și selectoarele, rutele și ordinea de depanare urmează. Greșiți și veți petrece o zi depanând un tunel care este tehnic activ.

Modelul cu patru gateway-uri

Gateway-urile exterioare A și B construiesc primul tunel între cele două locații. În spatele lui A se află gateway-ul intern C cu adresa de tranzit 10.60.0.2; în spatele lui B se află gateway-ul intern D cu adresa de tranzit 10.70.0.2. Rețelele aplicațiilor trăiesc în spatele lui C și D, iar fiecare adresă din exemplu este în mod deliberat ne suprapusă.

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

Împărțirea straturilor pe patru gazde înseamnă că fiecare mașină impune o singură graniță. O singură gazdă care rulează ambele straturi trebuie să împace două seturi de politici, două tabele de rutare și două moduri de eșec pe o singură mașină, ceea ce este posibil și mult mai greu de observat.

Fiecare strat elimină doar propria protecție

C criptează un pachet de aplicație pentru D. Rezultatul este adresat de la C la D, și asta ajunge la A. Tot ce urmează depinde de rescrierea respectivă.

A îl criptează din nou pentru B. B decriptează stratul exterior, vede un pachet de la C la D și îl transmite mai departe încă criptat. D elimină protecția internă și livrează pachetul de aplicație.

Deci A și B văd punctele finale interne și metadatele lor, dar nu sunt părțile care decriptează încărcătura aplicației. Aceasta este o proprietate reală a designului, nu o afirmație că C, D sau gazdele aplicațiilor sunt de încredere.

Selectoarele exterioare numesc gateway-urile interne

Aici eșuează majoritatea acestor construcții. Pentru un tunel exterior bazat pe politici, selectoarele pe care le negociați trebuie să conțină adresele pe care A și B le tratează efectiv: 10.60.0.2/32 și 10.70.0.2/32, în ordinea locală și la distanță corectă.

Punerea subrețelelor finale ale aplicațiilor în selectoarele exterioare nu funcționează, pentru că atunci când un pachet ajunge la A, încapsularea internă a rescris deja ce trebuie să protejeze A. Politica exterioară nu s-ar mai potrivi atunci cu nimic, iar tunelul ar urca fără să transporte date.

Nu restrângeți permisiunea exterioară la UDP 500. Conexiunea internă are propria cale de date, care folosește ESP sau încapsulare UDP în funcție de ce s-a negociat, iar politica exterioară trebuie să permită acel protocol.

Verificați rezultatul cu swanctl --list-sas pe fiecare gateway și confirmați că asocierile de securitate copil raportează adresele pe care le-ați intenționat, nu pe cele pe care le-ați presupus. Dacă lista arată subrețelele aplicațiilor, politica exterioară a fost scrisă pentru stratul greșit. Corectați selectoarele înainte de a depana rutarea, pentru că rutarea va părea corectă, iar contoarele nu se vor mișca.

Forwardingul și capcana recursiei

Selectoarele nu înlocuiesc rutarea. A și B trebuie să transmită trafic între C și D în ambele direcții, ceea ce înseamnă forwarding IP activat, rute care indică tunelul și o cale de întoarcere care există pe cealaltă parte.

Dacă tunelul exterior folosește interfețe XFRM, rutele selectează interfața, în timp ce politicile negociate încă limitează ce transportă aceasta. O interfață nu lărgește zona protejată; doar schimbă modul în care nucleul preia pachetul.

Capcana este recursia. Ruta lui A către punctul final exterior al lui B trebuie să urmeze rețeaua de bază, nu tunelul pe care A îl construiește, altfel încapsularea încearcă să călătorească în interiorul ei și conexiunea nu se finalizează niciodată.

Inspectați traducerea înainte de a adăuga straturi

Uitați-vă la orice NAT sursă pe A și B înainte de a regla orice altceva. O regulă care rescrie adresa lui C înainte de aplicarea politicii IPsec poate rupe selectoarele convenite și poate schimba și ce primește D pe cealaltă parte.

Mascarea largă nu devine mai sigură pentru că are două straturi. Ascunde ce adresă vede capătul îndepărtat, și exact aceasta este informația de care aveți nevoie când tunelul este activ, iar aplicația nu.

Dacă o regulă NAT este cu adevărat necesară, notați cu ce adresă crede fiecare parte că vorbește. Acea singură linie rezolvă majoritatea discuțiilor despre dacă vinovat este tunelul sau traducerea. Îi spune și următorului inginer unde să se uite când regula va fi eliminată un an mai târziu. Un ping nu va face nimic din toate acestea.

Demonstrați fail-closed și verificați MTU

Dispariția unei rute nu este în sine o politică fail-closed. Un alt tabel, o rută implicită sau o regulă de politică pot oferi în tăcere o alternativă, iar singurul mod de a afla este să coborâți tunelul exterior și să observați ce face traficul aplicațiilor. Faceți asta intenționat, într-o fereastră de mentenanță, în loc să descoperiți lucrul din întâmplare.

Testați trei stări: tunel exterior oprit, tunel interior oprit și recuperarea după ce ambele revin. Folosiți contoare de politică pe fiecare gateway, pentru că două sesiuni IKE stabilite dovedesc doar că negocierea planului de control a reușit.

Bugetați ambele încapsulări. Un IKE funcțional este un rezultat pentru pachete mici, iar pachetele de aplicație de dimensiune completă pot eșua în continuare după adăugarea a două antete; testați cu o dimensiune cunoscută a încărcăturii pe calea reală în loc să presupuneți că numerele se adună. Aritmetica este ușoară, calea nu.