Přehled: netfilter
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ů:
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.
Co použít
| Situace | Doporučení |
|---|---|
| Jednoduchý server, pár portů | ufw |
| Potřebuješ NAT, forwarding, složitější logiku | nftables |
| Zděděná konfigurace, staré návody | iptables |
| Red Hat, Fedora, Rocky | firewalld |
| Docker v hostiteli | vždycky navíc DOCKER-USER, viz 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.
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.
POSTROUTING je těsně před odesláním. Sem patří SNAT a masquerade, tedy NAT ven.
Souvislost s tím, co se děje na drátě, je v cestě paketu.
Stavovost
Netfilter je stavový — 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:
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:
nft list ruleset > /root/firewall-zaloha.nft
iptables-save > /root/iptables-zaloha.rules