D'une manière générale, le NAT est utile surtout en IPv4, puisqu'en IPv6, chaque nœud est potentiellement directement connecté à l'internet.

Le MASQUERADE (masquage d'adresse) est donc un «source NAT» un peu plus sophistiqué puisqu'il doit gérer correctement les retours. C'est LA solution pour permettre à toutes les stations de 192.168.1.0/24 de pouvoir dialoguer avec l'internet.

«Destination NAT» est une technique qui permet de modifier l'adresse de destination des paquets entrants depuis l'internet qui est donc en IPv4 obligatoirement l'unique adresse publique allouée par le modem ADSL/Fibre/Câble que récupère le routeur NAT.

Si nous désirons rendre public un serveur HTTP/HTTPS que nous installons sur une machine dédiée pour diverses raisons dont quelques-unes concernant la sécurité de l'ensemble dans le réseau 192.168.61.0/24 il faudra bricoler un peu l'adresse de destination.

HTTP utilise par défaut le port 80 et HTTPS le port 443.

1. lorsque le routeur reçoit une connexion sur le port 80 ou sur le port 443 de son adresse publique, il ne doit pas les rejeter mais les transmettre ici à 192.168.61.2, d'où la translation d'adresse de destination, qui ne va pas changer l'adresse de la source (le client).
2. le serveur 192.168.61.2 répond donc comme s'il avait été directement interrogé, à l'adresse publique du client (puisqu'elle n'a pas été modifiée).
3. le routeur qui fait du masquage d'adresse remplace dans la réponse l'adresse privée du serveur 192.168.61.2 par l'adresse publique.
4. le client n'y voit que du feu…

Notons que les «box» des fournisseurs d'accès doivent probablement savoir faire tout ça. La démonstration est là pour illustrer le DNAT fait «maison».

Il nous faut rajouter tout d'abord de quoi faire le MASQUERADING en créant dans la famille ip puisque seul ipv4 est concerné une table que nous appellerons nat et dedans une chaîne que nous nommerons POSTROUTING et nous y mettrons la règle de masquage d'adresse:

table ip nat {
	chain POSTROUTING {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.168.61.0/24 oif "enp1s0" masquerade
	}
}

Rappelons que les noms choisis pour les tables et les chaînes dans les tables est purement conventionnel. Ils sont choisis ici pour rappeler les repères de l'antique iptables. (oif, c'est pareil que oifname) En ajoutant ceci à la configuration précédente, tous les nœuds IPv4 du LAN pourront communiquer avec l'internet.

Profitons de la table nat dans la famille ip pour y ajouter une chaîne TREROUTING car le nat de destination doit être effectué avant la décision de routage, sinon le routeur pensera que le paquet lui est destiné, ce qui donne au final:

table ip nat {
	chain POSTROUTING {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.168.61.0/24 oif "enp1s0" masquerade
	}

	chain PREROUTING {
		type nat hook prerouting priority dstnat; policy accept;
		tcp dport { 80, 443 } dnat to 192.168.61.2
	}
}

Ce qui donne finalement pour /etc/nftables.conf:

table inet filter {
	chain INPUT {
		type filter hook input priority filter; policy drop;
		iifname "enp7s0" tcp dport { 22, 23 } accept
		iifname "enp7s0" udp dport { 53, 67, 68 } accept
		iifname "enp1s0" tcp dport 22 accept
		iifname "lo" accept
		ct state established,related accept
		icmpv6 type { echo-request, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
		icmp type echo-request accept
	}
}
table ip nat {
	chain POSTROUTING {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.168.61.0/24 oif "enp1s0" masquerade
	}

	chain PREROUTING {
		type nat hook prerouting priority dstnat; policy accept;
		tcp dport { 80, 443 } dnat to 192.168.61.2
	}
}

Ne reste plus qu'à tester le tout. À vous de jouer

Nous pourrions faire mieux…

Supposons qu'un malveillant arrive à prendre le contrôle de 192.168.61.2, suite à une faille du serveur HTTP. Une fois dans la place, il pourra avoir accès au routeur via telnet et ssh et éventuellement aux stations du LAN.

La sécurité, c'est une affaire de paranoïa…