# ArhitecturăPattern-urile care țin firewallul funcțional: HA, zone, securitate transparentă, inspecție SSL. ## Privire de ansamblu ``` ┌──────────────────────────────┐ ISP A ──────────────┤ │ │ Sovereign Edge Firewall ├── Zonă: Clienți ISP B ──────────────┤ (failover active / passive)│── Zonă: VPN │ │── Zonă: Anonimizare │ • Filtru stateful │── Zonă: Privacy │ • NAT (per uplink) │── Zonă: DMZ │ • SSL offload transparent │ │ • Monitor de failover │ └──────────────────────────────┘ ``` Firewallul stă la marginea rețelei cu două uplink-uri paralele de internet. Intern, prezintă câte un interfață logică per zonă izolată. ## Înaltă disponibilitate dual-provider Două uplink-uri (de exemplu fibră + LTE/5G sau doi carrieri) sunt conectate în paralel. Un monitor de failover observă starea linkului, accesibilitatea gateway-ului și latența și comută ruta default **în mai puțin de cinci secunde** la cădere pe al doilea uplink. Puncte cheie: - **Set de reguli simetric.** Ambele uplink-uri împart regulile de filtru, NAT și scrub. Fără cale „bună" și „proastă". - **NAT dinamic.** Source NAT-ul ia IP-ul de egress dinamic de la interfața activă — fără hardcoding, fără stale mappings la failover. - **Control selectiv.** Anumite clase de trafic pot fi pinned țintit pe al doilea uplink (de exemplu o cale de proxy de anonimizare sau echilibrare de sarcină pentru servicii cu download greu). - **Failback automat.** Imediat ce uplinkul primar e iar sănătos, monitorul aduce ruta default înapoi automat. - **Drill-uri de failover.** O rutină definită de drill (vezi [Operare](../operations/)) verifică trimestrial că failoverul chiar funcționează — nu doar în teorie. ## Segmentare pe zone În loc de o topologie plată „înăuntru/afară", firewallul operează pe un model de zone pe niveluri. Mișcările laterale între zone sunt blocate implicit. | Zonă | Scop | Profil de egress | |---|---|---| | Clienți | Stații de lucru ale angajaților | Proxy HTTP/HTTPS transparent cu content inspection | | VPN | Tuneluri remote access și site-to-site | Profil de egress per tunel | | Anonimizare | Workloads sensibile (cercetare, canale whistleblower) | Tot traficul prin Tor, inclusiv DNS | | Privacy | Workloads de protecție maximă | Anonimizare + strat suplimentar | | DMZ | Servicii accesibile extern | Reverse proxy hardened în fața serviciilor | Fiecare zonă are propria: - **Logică de reguli de filtru** — ce intră, ce iese. - **Politică NAT** — ce IP de egress, ce uplink preferat. - **Strat de inspecție** — dacă HTTPS este rupt, ce este logat. - **Tabele de whitelist/blocklist** — alimentate din output-urile daemonilor (vezi documentația [Abusive HTTP Watch](../../abusive-http-watch/)). ## Niveluri transparente de securitate Dispozitivele finale din zona Clienți primesc următoarele straturi de protecție fără configurare locală: ### SSL offloading ca protecție antivirus Stratul cel mai valoros operațional. Motivul: - Peste 90 % din amenințările web moderne — descărcări de malware, payloads de phishing, exploit-uri drive-by — sunt livrate prin TLS. - Antivirusul de pe dispozitiv (Defender, Bitdefender, …) pe stația de lucru vede doar streamul criptat. Poate recunoaște fișierul infectat abia **după** ce dispozitivul l-a despachetat. - În acest moment, dispozitivul a executat deja primele etape ale payloadului. Containment-ul devine incident response. Firewallul terminează în loc TLS la gateway, predă plaintext-ul unui motor antivirus și abia apoi rutează conținutul la dispozitiv. Dispozitivul vede un stream deja scanat. Malware-ul este blocat **înainte să ajungă la dispozitiv**. CA-ul pentru acest bump este [Sovereign Certificate Authority](../../sovereign-certificate-authority/) — clienții au încredere în certificatele gateway-ului pentru că root-ul intern de CA este instalat prin configuration management standard. ### Content filter Rețelele de publicitate, domeniile de tracker și hosturile cunoscute ca nocive sunt filtrate înainte de livrare. Reduce greutatea paginii, elimină o clasă de atacuri de supply chain (JavaScripturi compromise ale rețelelor de publicitate) și îmbunătățește privacy-ul. ### Gateway Tor / de anonimizare Zona de anonimizare nu are deloc **egress direct la internet**. Tot traficul TCP este rutat transparent printr-un daemon Tor local, inclusiv cererile DNS (printr-un resolver local care folosește portul DNS al lui Tor). Dispozitivele din această zonă nu au nevoie de client Tor propriu — rețeaua impune rutarea. ### Gateway I2P / Privacy Aceeași idee ca zona Tor, un strat mai jos. Folosit pentru workloads la care chiar și încrederea în exit nodes Tor este un subiect. ## Default-uri operaționale - **Default-deny.** Fiecare regulă care permite trafic este explicită. Protecție anti-spoofing, validare reverse-path și euristici anti-scan rulează implicit. - **Limite de connection state.** Sute de mii de sesiuni paralele sunt susținute; cap-uri per sursă previn epuizarea state table-ului. - **Normalizarea traficului.** TCP reassembly, MSS clamping și protecție anti-fingerprinting se aplică pe toate căile de egress — important pentru uplink-uri mobile și tuneluri VPN. - **Dual-stack.** IPv4 și IPv6 sunt first-class, inclusiv mecanica ICMPv6 modernă (Router Advertisement, Neighbour Discovery). ## Unde se potrivește daemonul Daemonul însoțitor [Abusive HTTP Watch](../../abusive-http-watch/) scrie o blocklistă pe care firewallul o consumă printr-un cron de reîncărcare de tabel. Asta adaugă un strat de block bazat pe comportament deasupra regulilor statice — IP-urile care dovedit caută exploituri sunt droppate la edge. ## Ce nu este - Nu este o vendor box de cumpărat. Este un pattern de livrare, nu un SKU de produs. - Nu este un proiect pentru începători. A opera asta responsabil cere operatori competenți (sau serviciul de [Operare](/ro/services/support/) care îi furnizează). - Nu este o soluție „setezi o dată și uiți". Seturile de tokenuri, blocklistele și regulile de zonă au nevoie de întreținere — vezi [Operare](../operations/).