Firewall a NAT

DNAT

DNAT řeší opačný problém: Dejme tomu, že v našem příkladu ve vnitřní síti máme na stanici s IP adresou 192.168.1.10 spuštěný HTTP server na portu 8080/tcp a chceme jej zpřístupnit zvenčí. Bylo by pochopitelně možné celý server přenést do sítě, která je na hosting veřejně dostupných služeb připravená a přečíslovat jej na global unicast adresu. Dejme ale tomu, že toto řešení z nějakého důvodu nechceme realizovat a místo toho se rozhodneme pomocí překladu cílové adresy zpřístupnit HTTP službu z vnitřní sítě na adrese našeho Linuxového routeru a to na portu 80/tcp. Teď tedy DNATem přeložíme nejen adresu, ale i číslo portu, jak ukazuje následující obrázek:

Tohoto přesměrování dosáhneme opět jediným pravidlem (za předpokladu, že směrovací tabulky zajišťují konektivitu v obou adresních doménách a že toku dat nestojí v cestě žádná pravidla v tabulce filter - k tomu se ještě vrátíme). Pravidlo pro iptables bude:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.1.10:8080

pro nftables bude ekvivaletní blok vypadat takhle:

table ip nat {
    chain PREROUTING {
        type nat hook prerouting priority 100; policy accept;
            iifname "eth1" meta l4proto tcp tcp dport 80 counter dnat to 192.168.1.10:8080
    }
}

Tentokrát už snad nemusíme zabíhat do tolika detailů a podíváme se jen na obrázek, který vlastně ukazuje první dva packety TCP spojení, které tentokrát navazuje klient 217.31.205.25 v Internetu nalevo na adresu 84.42.173.26. Zajímavá otázka může být, jak se klient dozví adresu našeho routeru v situaci, kdy to je domácí router a adresa na jeho eth1 je proměnlivá, protože se dynamicky přiděluje protokolem DHCP?: V této situaci se zpravidla používá nějaký druh dynamického DNS (DDNS), jehož smysl je v tom, že po přidělení nové adresy DHCP serverem na náš router dojde zvláštním protokolem k ohlášení nové adresy DDNS serveru a tato adresa se dočasně zapamatuje pro konkrétní (pevné) jméno, které máme pro náš router určené.

Klient se tedy připojuje TCP segmentem s flagem SYN=1 na adresu 84.42.173.26 na port 80. TCP segment dorazí na rozhraní eth1, čímž získá shodu s naším pravidlem v tabulce nat v PREROUTING řetězci, které změní cílovou adresu na 192.168.1.10 a cílový port na 8080. Tato změna nastane ještě před směrovacím rozhodnutím (proto PREROUTING), které by jinak rozhodlo o tom, že bude packet zpracován lokálně a poslán do síťového stacku. Protože ale včas došlo ke změně cílové adresy, směrovací rozhodnutí naopak vede k tomu, že je packet zpracován jako forwarding ve směru na interface eth0. Z hlediska serveru přichází normální HTTP request na port 8080 a server 192.168.1.10 vůbec neví, že se zdrojovou adresou v TCP segmentu 217.31.205.25 vlastně vůbec nemůže přímo bez NATu komunikovat. Proto server normálně odpoví a předpokládáme, že default GW na serveru odešle odpověď opět na náš router 192.168.1.1, který na základě informací v tabulce conntracku udělá tentokrát před routingem zpětný překlad (v obrázku zelenou adresu a port na červené) a packet odešle do Internetu. Klientovi tedy dorazí přesně takový packet, jaký očekával jako odpověď na navazování spojení. Všechny další TCP segmenty projdou dle tabulky conntracku tímto překladem adres a portů a proto se naváže a proběhne jinak zcela standardní TCP spojení.