# ArchitekturaWzorce, które utrzymują firewall w ruchu: HA, strefy, transparentne bezpieczeństwo, inspekcja SSL.

## 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](../operations/)) 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.

| Strefa | Cel | Profil egressu |
|---|---|---|
| Klienci | Stacje robocze pracowników | Transparentny proxy HTTP/HTTPS z content-inspection |
| VPN | Remote-access i tunele site-to-site | Profil egressu per tunel |
| Anonimizacja | Wrażliwe workloady (research, whistleblower) | Cały ruch przez Tor, włącznie z DNS |
| Privacy | Workloady maksymalnej ochrony | Anonimizacja + dodatkowa warstwa |
| DMZ | Zewnętrznie dostępne serwisy | Zhardenowany reverse-proxy przed serwisami |

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](../../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](../../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](../../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](/pl/services/support/), która ich dostarcza).
- Bez rozwiązania „raz ustawić i zapomnieć". Zestawy tokenów, blocklisty i reguły stref potrzebują pielęgnacji — patrz [Operacje](../operations/).