# Linux firewall: jeden systém, čtyři rozhraní

Nejčastější nedorozumění v celé téhle oblasti zní: „mám vypnout iptables a zapnout ufw?" Otázka nedává smysl, protože to nejsou konkurenční firewally.

## Mentální model

V jádře Linuxu je jediný firewall a jmenuje se **netfilter**. Ten skutečně zahazuje a propouští pakety. Nikdy s ním nemluvíš přímo — mluvíš s ním přes některý z nástrojů:

```mermaid
flowchart TD
    A[iptables] --> N
    B[nftables] --> N
    C[ufw] --> B
    D[firewalld] --> B
    N[netfilter v jádře<br/>tady se to skutečně děje]
```

Z toho plyne několik věcí, které řeší většinu zmatků:

**Nemůžeš mít „zapnuté dva firewally".** Můžeš mít dva nástroje, které zapisují do stejného místa a nevědí o sobě. To je horší.

**ufw a firewalld jsou nadstavby.** Nedělají nic, co by neuměl nftables — jen ti dávají příjemnější příkazy. Pod kapotou generují stejná pravidla.

**iptables už na moderních distribucích většinou není iptables.** Na Debianu 11+, Ubuntu 22.04+ a všem novějším je `iptables` ve skutečnosti `iptables-nft`, tedy překladová vrstva zapisující do nftables. Příkazy fungují, ale `nft list ruleset` ti ukáže pravdu.

**Pravidla, která nevidíš, pořád platí.** `ufw status` ti ukáže jen to, co zapsalo ufw. Když ti Docker přidá vlastní pravidla, ufw o nich mlčí. Viz [Docker a firewall](Docker-a-firewall).

## Co použít

| Situace | Doporučení |
|---|---|
| Jednoduchý server, pár portů | [ufw](ufw) |
| Potřebuješ NAT, forwarding, složitější logiku | [nftables](nftables) |
| Zděděná konfigurace, staré návody | [iptables](iptables) |
| Red Hat, Fedora, Rocky | firewalld |
| Docker v hostiteli | vždycky navíc `DOCKER-USER`, viz [Docker a firewall](Docker-a-firewall) |

Když začínáš dnes na čistém stroji: **ufw pro jednoduché věci, nftables když ufw nestačí.** iptables se uč jen proto, abys rozuměl existujícím konfiguracím a návodům na internetu — nových věcí v něm nepiš.

## Kudy paket letí

Tohle je společné všem nástrojům a je to jediná věc, kterou musíš mít v hlavě. Netfilter má body, ve kterých může do paketu zasáhnout, a záleží na tom, jestli paket míří **na tenhle stroj**, nebo **skrz něj**.

```mermaid
flowchart LR
    IN[příchozí paket] --> PRE[PREROUTING<br/>DNAT]
    PRE --> R{je to pro mě?}
    R -->|ano| INP[INPUT] --> L[lokální proces]
    R -->|ne| FWD[FORWARD] --> POST
    L --> OUT[OUTPUT] --> POST[POSTROUTING<br/>SNAT/masquerade]
    POST --> EXT[ven]
```

Praktické důsledky, kvůli kterým se ta pravidla nejčastěji píšou špatně:

**INPUT** je provoz **na** tenhle stroj. Sem patří „povol SSH", „povol web".

**FORWARD** je provoz **skrz** tenhle stroj. Sem patří všechno, co se týká routeru, VPN a kontejnerů. Když píšeš pravidlo do INPUT a ono „nefunguje", v devíti z deseti případů měl paket jít přes FORWARD.

**PREROUTING** je před rozhodnutím o směrování. Sem patří DNAT, tedy [port forwarding](NAT-a-port-forwarding).

**POSTROUTING** je těsně před odesláním. Sem patří SNAT a masquerade, tedy [NAT](NAT-a-port-forwarding) ven.

Souvislost s tím, co se děje na drátě, je v [cestě paketu](Cesta-paketu).

## Stavovost

Netfilter je [stavový](Firewall-a-zony) — sleduje otevřená spojení. Proto začíná skoro každá rozumná konfigurace tímhle:

```
povol vše ve stavu ESTABLISHED,RELATED
zahoď vše ve stavu INVALID
```

a teprve pak řešíš nová spojení. Bez toho bys musel psát pravidla pro odpovědi, což nikdo nedělá.

## Než začneš experimentovat

**Zamkneš se.** Ne možná, určitě. Když ladíš firewall přes SSH, dřív nebo později si zahodíš vlastní spojení.

Pojistka, která tě zachrání — naplánuje vypnutí firewallu za deset minut:

```bash
echo "nft flush ruleset" | at now + 10 minutes
```

Když se odřízneš, počkáš deset minut a jsi zpátky. Když je všechno v pořádku, úlohu zrušíš (`atq` a `atrm`).

Na Proxmoxu nebo VM máš konzoli, takže je to méně dramatické. Na vzdáleném VPS bez konzole je tohle rozdíl mezi nepříjemností a reinstalací.

**Vždycky si zálohuj současný stav:**

```bash
nft list ruleset > /root/firewall-zaloha.nft
iptables-save > /root/iptables-zaloha.rules
```