Architektura

Przegląd#

                                ┌──────────────────────────────┐
            ISP A ──────────────┤                              │
                                │   Sovereign Edge Firewall    ├── Strefa: Klienci
            ISP B ──────────────┤   (active / passive failover)│── Strefa: VPN
                                │                              │── Strefa: Anonimizacja
                                │   • Stateful-filtr            │── Strefa: Privacy
                                │   • NAT (per uplink)          │── Strefa: DMZ
                                │   • Transparentny SSL-offload │
                                │   • Monitor failover          │
                                └──────────────────────────────┘

Firewall siedzi na brzegu sieci z dwoma równoległymi uplinkami internetowymi. Wewnętrznie prezentuje logiczny interfejs per izolowaną strefę.

Dual-provider wysoka dostępność#

Dwa uplinki (np. światłowód + LTE/5G lub dwóch carrierów) są podłączone równolegle. Monitor failover obserwuje link-state, dostępność gateway i latencję i przy awarii przełącza default-route w mniej niż pięć sekund na drugi uplink.

Kluczowe punkty:

• Symetryczny zbiór reguł. Oba uplinki dzielą reguły filtra, NAT i scrub. Bez „dobrej" i „złej" ścieżki.
• Dynamiczny NAT. Source-NAT bierze IP egress dynamicznie z aktywnego interfejsu — bez hardcodingu, bez stale-mappings przy failover.
• Selektywne sterowanie. Określone klasy ruchu można celowo przypiąć do drugiego uplinka (np. ścieżka proxy anonimizacji lub rozkład obciążenia dla serwisów obciążonych downloadem).
• Automatyczny failback. Gdy główny uplink jest znów zdrowy, monitor automatycznie zwraca default-route.
• Testy failover. Zdefiniowana rutyna drill (patrz Operacje) weryfikuje kwartalnie, że failover naprawdę działa — nie tylko w teorii.

Segmentacja stref#

Zamiast płaskiej topologii „wewnątrz/na zewnątrz" firewall operuje na wielopoziomowym modelu stref. Ruchy lateralne między strefami są domyślnie blokowane.

Każda strefa ma własną:

• Logikę reguł filtra — co może wejść, co może wyjść.
• Politykę NAT — które IP egress, który uplink preferowany.
• Warstwę inspekcji — czy HTTPS jest rozbijany, co jest logowane.
• Tabele whitelist/blocklist — zasilane outputami daemonów (patrz dokumentacja Abusive HTTP Watch).

Transparentne warstwy bezpieczeństwa#

Urządzenia końcowe w strefie klientów otrzymują następujące warstwy ochrony bez lokalnej konfiguracji:

SSL-offloading jako ochrona antywirusowa#

Operacyjnie najbardziej wartościowa warstwa. Uzasadnienie:

• Ponad 90 % nowoczesnych zagrożeń web — downloady malware, payloady phishingowe, drive-by exploity — jest dostarczanych przez TLS.
• Antywirus na urządzeniu końcowym (Defender, Bitdefender, …) na stacji roboczej widzi tylko zaszyfrowany stream. Może rozpoznać zarażony plik dopiero po rozpakowaniu go przez urządzenie.
• W tym momencie urządzenie wykonało już pierwsze stopnie payloadu. Containment staje się incident-response.

Firewall terminuje TLS zamiast tego na gateway, przekazuje plaintext silnikowi antywirusowemu i dopiero potem przekazuje treść do urządzenia końcowego. Urządzenie końcowe widzi już przeskanowany stream. Malware jest blokowany zanim dotrze do urządzenia końcowego.

CA dla tego bumpa to Sovereign Certificate Authority — klienci ufają certyfikatom gateway, ponieważ wewnętrzne root CA jest zainstalowane przez standardowe configuration management.

Content-filter#

Sieci reklamowe, domeny trackerów i znane szkodliwe hosty są filtrowane przed dostarczeniem. Redukuje wagę strony, eliminuje klasę ataków supply-chain (skompromitowane JavaScripty sieci reklamowych) i poprawia prywatność.

Tor / brama anonimizacji#

Strefa anonimizacji w ogóle nie ma bezpośredniego egressu internetowego. Cały ruch TCP jest transparentnie routowany przez lokalny daemon Tor, włącznie z zapytaniami DNS (przez lokalny resolver, który używa portu DNS Tora). Urządzenia końcowe w tej strefie nie potrzebują własnego klienta Tor — sieć wymusza routing.

I2P / brama Privacy#

Ta sama idea co strefa Tor, warstwa głębiej. Używana dla workloadów, w których nawet zaufanie do exit-node Tor jest tematem.

Operacyjne defaulty#

• Default-deny. Każda reguła, która pozwala na ruch, jest jawna. Ochrona przed spoofingiem, walidacja reverse-path i heurystyki anti-scan działają domyślnie.
• Limity connection-state. Setki tysięcy równoległych sesji są wspierane; per-source-caps zapobiegają wyczerpaniu state-table.
• Normalizacja ruchu. TCP-reassembly, MSS-clamping i ochrona przed fingerprintingiem są stosowane na wszystkich ścieżkach egress — istotne dla uplinków komórkowych i tuneli VPN.
• Dual-Stack. IPv4 i IPv6 są first-class, włącznie z nowoczesną mechaniką ICMPv6 (Router Advertisement, Neighbour Discovery).

Gdzie pasuje daemon#

Towarzyszący daemon Abusive HTTP Watch pisze blocklistę, którą firewall konsumuje przez cron reload tabeli. To dodaje warstwę blokowania opartą na zachowaniu nad statycznymi regułami — IP, które dowodnie szukają eksploitów, są droppowane na edge.

Czym to nie jest#

• Bez vendor-boxa do kupienia. To wzorzec dostarczenia, nie produkt SKU.
• Bez projektu dla początkujących. Odpowiedzialne prowadzenie tego wymaga kompetentnych operatorów (lub usługi Wsparcie, która ich dostarcza).
• Bez rozwiązania „raz ustawić i zapomnieć". Zestawy tokenów, blocklisty i reguły stref potrzebują pielęgnacji — patrz Operacje.