Politica de firewall în EVPN: gateway centralizat versus IRB distribuit

Două proiecte EVPN plasează gateway-ul chiriașului în locuri diferite, iar firewall-ul vede trafic diferit în fiecare. Cu un gateway centralizat, traficul între subrețele ajunge la firewall pentru că acolo are loc rutarea. Cu IRB distribuit, switch-urile leaf rutează local și firewall-ul nu vede nimic dacă nu îl inserați intenționat. Niciunul dintre modele nu este greșit. Greșit este să conectați un firewall la margine și să presupuneți că fabric îi va livra traficul.

Două modele, două puncte de inspecție diferite

Numiți mai întâi fluxurile care necesită inspecție, pentru că cele două modele le tratează diferit.

Traficul din cadrul aceleiași subrețele este rândul pe care oamenii îl uită. Două gazde dintr-un VLAN comunică prin punte, iar pe acea cale nu stă niciun firewall rutat dacă un proiect separat de inspecție de nivel 2 nu îl interceptează. Acest lucru este valabil în ambele modele, deci este o lipsă de proiectare și nu o comparație între ele.

Celelalte trei rânduri sunt locul unde modelele chiar diverg.

Gateway centralizat: inspecție simplă, cost real de tranzit

Păstrați VLAN-urile chiriașului ca servicii de nivel 2 și plasați gateway-urile lor de rutare pe firewall. Traficul între subrețele călătorește apoi la acel gateway și înapoi, posibil chiar și când ambele gazde sunt pe același leaf. Punctul de inspecție este neechivoc și acesta este întregul argument al proiectului. Costul este sarcina de tranzit pe firewall plus o dependență centrală de capacitate și disponibilitate pe care acum trebuie să o proiectați.

Limitați schimbarea la gateway-urile de chiriaș pe care le intenționați. Eliminarea fiecărei adrese VLAN este prea largă când managementul, underlay-ul și interfețele platformei au sarcini separate. Verificați și un al doilea gateway activ, pentru că unul care încă rutează în jurul firewall-ului anulează discret proiectul.

Acest model este mai ușor de explicat unui auditor. Nu este automat mai ieftin de operat.

IRB distribuit: cale rapidă, nicio inspecție implicită

Cu gateway-uri anycast distribuite, fiecare leaf rutează local traficul chiriașului, iar RFC 9135 descrie de ce asta evită returul printr-un gateway centralizat. Beneficiul este real și are o consecință directă: inspecția nu poate fi dedusă din locul unde este conectat firewall-ul. Un firewall conectat la un leaf de margine vede traficul extern și tot ce redirecționați explicit către el.

Inserați serviciul cu un mecanism pe care platforma îl suportă cu adevărat: redirecționare bazată pe politici, un nod de serviciu sau rutare controlată între VRF prin firewall. Potriviți traficul dorit în punctul său real de intrare. O politică scrisă pe o interfață orientată spre gazde nu acoperă un pachet care vine din overlay.

Citiți rutele instalate, nu ruta implicită intenționată. Un prefix de chiriaș mai specific importat direct poate ocoli ruta implicită care indică spre firewall, și nimic din configurație nu va părea greșit.

Simetria este o proprietate de rutare, nu o garanție de inspecție

IRB simetric descrie modul în care nodurile provider edge de intrare și ieșire gestionează rutarea și puntea pentru un flux. Nu spune nimic despre dacă ambele direcții ajung la același dispozitiv cu stare. ECMP, anycast și disponibilitatea ridicată a firewall-ului influențează toate care nod vede traficul de retur, iar modelul de stare suportat al clusterului decide dacă acest lucru este acceptabil.

Urmați explicit calea de retur pentru fiecare flux care vă interesează. NAT nu este un substitut universal pentru acea muncă, iar proiectele care se bazează pe el găsesc de obicei lipsa în timpul unui failover și nu în timpul construcției.

Parcurgeți un flux obligatoriu și un flux exclus deliberat, în ambele direcții, înainte de a aproba proiectul.

Cum să alegeți și ce să testați în ambele cazuri

Alegeți gateway-ul centralizat când acoperirea inspecției contează mai mult decât capacitatea de tranzit și vă permiteți dependența centrală. Alegeți IRB distribuit când rutarea locală este punctul principal, și bugetați inserarea explicită de serviciu în loc să o presupuneți.

Apoi testați rutarea pe care ați instalat-o efectiv, pentru că acolo diferă cel mai mult cele două proiecte:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Includeți în test defecțiunea și recuperarea nodului de serviciu. O rută de rezervă care ocolește discret inspecția este o decizie diferită de o politică fail-open planificată, și de obicei doar una dintre ele este intenționată. Proiectul final precizează unde rutează fiecare clasă de trafic, unde este inspectat și ce se întâmplă când acea cale de inspecție nu este disponibilă.