Linux-firewall.md

# 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ů: ```mermaidflowchart 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**. ```mermaidflowchart 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,RELATEDzahoď 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: ```bashecho "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:** ```bashnft list ruleset > /root/firewall-zaloha.nftiptables-save > /root/iptables-zaloha.rules```