Două tuneluri IPsec active au încă nevoie de un plan al căii de întoarcere

Deschideți un terminal pe o stație de lucru într-un site și conectați-vă la un server în celălalt. Acea singură conversație TCP trebuie acum să traverseze patru gateway-uri în loc de două, iar partea interesantă nu este dacă funcționează într-o zi bună. Partea interesantă este ce pereche de gateway-uri a ales direcția de ducere, ce pereche alege răspunsul și cine ține starea fluxului în timp ce se întâmplă asta. Nimic din tabela de rutare nu decide asta pentru dumneavoastră.

Desenați patru gateway-uri înainte de a desena o rută

Un design dublu activ cu două firewall-uri VPN independente pe site, o pereche pe furnizor, vă dă două căi utilizabile și trei moduri de a le rupe. Notați adresele înainte de a configura orice: clientul așa cum se vede înainte și după fiecare gateway, serverul la fel, următorul salt de ducere și următorul salt de întoarcere.

Acea tabelă este designul. Tot ce urmează este o întrebare dacă dispozitivele sunt de acord cu tabela.

Cum este aleasă calea de ducere

Un strat de rutare multipath cu cost egal distribuie fluxurile pe următoarele salturi prin hashingul câmpurilor din antet, ceea ce RFC 2992 descrie în detaliu. Acea selecție poate fi complet fără stare: nu are nevoie de nicio intrare de urmărire a conexiunilor, doar de un hash stabil pe câmpuri neschimbate. Țineți mulțimea căilor și intrările hash constante și fiecare pachet al fluxului va alege același următor salt.

Selecția pe flux evită reordonarea pe care echilibrarea pachet cu pachet ar provoca-o pe legături cu întârzieri diferite. Nu promite că un cost de rutare egal înseamnă o latență măsurată egală, pentru că nu înseamnă. Iar când compoziția căilor se schimbă, fluxurile sunt remapate, așa că supraviețuirea conexiunii în timpul unei defecțiuni este o cerință separată de selecția căii.

De ce are nevoie cu adevărat calea de întoarcere

Aici parcursul încetează să mai fie simetric. Un hash de ducere stabil nu vă spune nimic despre ce va face site-ul îndepărtat cu răspunsul. Dacă un firewall independent trebuie să vadă ambele direcții ale conexiunii pentru a menține o stare utilă, o rută de întoarcere care îl ocolește lasă trafic care nu corespunde nimic. Două cutii cu seturi de reguli similare nu sunt stare partajată.

Confirmați comportamentul bidirecțional implementat sau scrieți o politică explicită care menține limitele necesare coerente. O presupunere aici este descoperită în timpul unei căderi, de oameni cărora nu le place asta.

Unde traducerea decide pentru dumneavoastră

NAT este cealaltă pârghie și este opțională, nu obligatorie. Identitățile traduse specifice căii pot direcționa răspunsurile înapoi spre gateway-ul care ține starea, ceea ce este un design legitim. Dar adaugă mapări, rute de întoarcere și un proprietar al acelei stări, așa că acceptați povara doar pentru o cerință pe care o puteți spune cu voce tare.

Dacă cerința este pur și simplu ca ambele căi să transporte trafic și oricare să supraviețuiască pierderii unui furnizor, multipath-ul simplu pe flux cu rutare de întoarcere coerentă este de obicei designul mai mic.

Parcurgeți acceptarea în ordine

Testați în această secvență și înregistrați adresele la fiecare pas: o conexiune nouă pe calea A și calea ei de răspuns, același lucru pe calea B, apoi pierderea unui furnizor, apoi restabilirea. Pentru fiecare rezultat, notați ce fluxuri stabilite s-au mutat, care au trebuit să se reconecteze și unde au mers fluxurile noi după aceea. Scrieți mai întâi valoarea așteptată, apoi comparați-o cu captura. Două tuneluri stabilite nu dovedesc nimic din toate acestea.

Designul este terminat când tabela pe care ați scris-o corespunde cu ceea ce arată captura, nu când ambele tuneluri sunt ridicate.