Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Netfilter : migrer vers du Nat ?

10 réponses
Avatar
Samuel
Bonjour,

Ayant parcouru google, je voudrais confirmation avant de faire des bêtises :

Actuellement, ma passerelle/firewall débian (3 pattes) est connectée sur un
routeur qui effectue lui-même le NAT pour Internet.
Nous venons de changer d'abonnement ADSL pour prendre Oleane avec un petit
sous-réseau de 8 adresses IP publiques.
Sur la passerelle, seule la carte réseau du Lan restera en adressage privé,
tandis que la carte de la DMZ ainsi que celle connectée au routeur/modem
passera en adressage IP publique.
Il faut donc que je déporte le NAT qui est sur le routeur vers la passerelle
Linux.
D'après mes lectures sur netfilter.org, cela ne pose pas de problème, on
laisse ses filtres iptables tel quel, et on rajoute juste la commande NAT
pour le postrouting :

iptables -t nat -A POSTROUTING -p tcp -i $LAN -j SNAT --to
$Mon_adresse_ip_publique

Il n'y a que cela à faire et les paquets seront quand même vérifiés par
Netfilter ???

Merci d'avance.
Samuel.

10 réponses

Avatar
Samuel
iptables -t nat -A POSTROUTING -s $MSQLAN -d ! $MSQDMZ -j MASQUERADE

ou MSQLAN est mon masque de reseau pour le LAN (disons 192.168.1.0/24) et
MSQDMZ le masque d'adressage de ma DMZ comme 10.0.0.0/30...


Salut,

Merci pour cette réponse très rapide ainsi que l'astuce pour le routage vers
la DMZ que j'avais oubliée.

Par contre, juste pour comprendre :

Sur Netfilter.org, ils disent que 'MASQUERADE' doit être employé avec des IP
dynamique, ce qui évite d'avoir à fournir la nouvelle adresse source (avec
SNAT) ..... mais je suppose que ça doit marcher aussi bien avec des IP
fixes comme dans mon cas ????

Merci encore.
Samuel.

Avatar
Julien Salgado
Eric Belhomme a écrit :
"Samuel" wrote in
petit sous-réseau de 8 adresses IP publiques.
Sur la passerelle, seule la carte réseau du Lan restera en adressage

iptables -t nat -A POSTROUTING -p tcp -i $LAN -j SNAT --to
$Mon_adresse_ip_publique


iptables -t nat -A POSTROUTING -s $MSQLAN -d ! $MSQDMZ -j MASQUERADE



Oui, mais non... le filtrage sur le réseau de destination est très bien
(quoi qu'il n'est possible que si il n'y a qu'une DMZ, il est peut être
avantageux de filtrer sur l'interface de sortie (qui est connue car on
est en post routing)), mais comme les IPs sont fixes il est très
interessant de faire de la _source NAT_, en effet :
- les tables seront un poil plus petites (donc moins de mémoire
utilisée),
- si l'interface ADSL tombe, les tables ne sont pas perdues
contrairement à ce qui ce passe avec du _masquerading_.

DOnc, il faut plutôt mettre :
iptables -t nat -A POSTROUTING -i $LAN -s $MSQLAN -o $ADSL
-j SNAT --to-source $Mon_adresse_ip_publique

ou $ADSL, est l'interface ADSL (ppp0 par exemple) et $LAN celle du LAN
(disons eth0).

La vérification de topologie (anti spoofing) ce faisant avec le _reverse
path filtering_
sysctl -w net.ipv4.conf.default.rp_filter=1

ou MSQLAN est mon masque de reseau pour le LAN (disons 192.168.1.0/24) et
MSQDMZ le masque d'adressage de ma DMZ comme 10.0.0.0/30...




--
Julien


Avatar
Samuel
DOnc, il faut plutôt mettre :
iptables -t nat -A POSTROUTING -i $LAN -s $MSQLAN -o $ADSL
-j SNAT --to-source $Mon_adresse_ip_publique


Merci à vous deux pour vos précisions,

Encore une remarque : Plutôt que de mettre :

iptables -t nat -A POSTROUTING -i $LAN -s $MSQLAN -o $ADSL -j
SNAT --to-source $Mon_adresse_ip_publique

Pourquoi ne pas mettre simplement :

iptables -t nat -A POSTROUTING -i $LAN -o $ADSL -j SNAT --to-source
$Mon_adresse_ip_publique

cad en enlevant '-s $MSQLAN' qui dans ce cas ne sert pas à grand chose non
????

Merci.
Samuel.

Avatar
Samuel
Les regles de filtrages doivent êtres les plus restrictives possibles,
c'est le fameux principe de ceinture ET bretelles...


Ok j'ai bien compris,

Merci beaucoup pour ces explications.

Samuel.

Avatar
Eric Belhomme
"Samuel" wrote in
news:bfjhcc$8i8$:

cad en enlevant '-s $MSQLAN' qui dans ce cas ne sert pas à grand chose
non ????

parce que tu peux avoir sur ton LAN d'autres classes d'adresse qui n'ont

pas le droit de sortir, ou pour prévenir le spoofing d'adresses, etc...

Les regles de filtrages doivent êtres les plus restrictives possibles,
c'est le fameux principe de ceinture ET bretelles...

--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/

Avatar
Cedric Blancher
Dans sa prose, Eric Belhomme nous ecrivait :
Cedric Blancher wrote in
Pourquoi ? Les machiens de la DMZ n'ont pas à avoir de route vers le
LAN.
ben ca depend... chez moi le dns est dans la dmz, le serveur smtp aussi...



Et alors ? Ces services n'ont pas besoin de joindre, de leur propre
initiative, les stations du LAN, si ? Si, oui, c'est mal (tm). Donc, tu
SNAT les requêtes des stations du LAN vers ces services. Sinon, tu colles
une 2e DMZ.

--
Pourriez vous me dire comment réaliser un fichier autoexecutable ou
plus presisement le fichier .exe que l'on met dedans !
-+- T in Guide du Neuneu Usenet : autoexécution de neuneu -+-


Avatar
Samuel
Et alors ? Ces services n'ont pas besoin de joindre, de leur propre
initiative, les stations du LAN, si ? Si, oui, c'est mal (tm). Donc, tu
SNAT les requêtes des stations du LAN vers ces services. Sinon, tu colles
une 2e DMZ.


Bonjour,

Donc pour un relais SMTP dans une DMZ, on utilise pas la fonction de 'relais
SMTP' vers le LAN, mais c'est plutôt le serveur SMTP du LAN qui doit
récupérer en smart pop les mails sur le serveur SMTP de la DMZ ?

Merci.
Samuel.

Avatar
Cedric Blancher
Dans sa prose, Samuel nous ecrivait :
Donc pour un relais SMTP dans une DMZ, on utilise pas la fonction de
'relais SMTP' vers le LAN, mais c'est plutôt le serveur SMTP du LAN qui
doit récupérer en smart pop les mails sur le serveur SMTP de la DMZ ?


Dans l'absolu, non plus. Le MDA devrait se trouver dans une 2e DMZ. Mais
ce n'est pas toujours possible, il faut donc trouver un compromis entre :

1. laisser un accès de la DMZ vers le LAN pour atteindre un MDA
2. laisser du mail sur la DMZ

Dans les deux cas c'est chaud, mais moins si tu viens régulièrement poller
le serveur en DMZ.

Ce que je considère comme mieux, c'est d'avoir deux DMZ : une pour les
services publics accessibles depuis Internet, et une autre pour les
services à usage interne communiquant avec l'extérieur.

Dans la première DMZ, tu trouveras ton MX, ton serveur DNS public, tes
serveurs WEB, etc. Dans la seconde, tu mets les proxies et le stockage du
mail.

--
BOFH excuse #239:

CPU needs bearings repacked

Avatar
Eric Belhomme
Cedric Blancher wrote in
news::

Ce que je considère comme mieux, c'est d'avoir deux DMZ : une pour les
services publics accessibles depuis Internet, et une autre pour les
services à usage interne communiquant avec l'extérieur.

Dans la première DMZ, tu trouveras ton MX, ton serveur DNS public, tes
serveurs WEB, etc. Dans la seconde, tu mets les proxies et le stockage
du mail.

voui, c'est ce que je ferais maintenant, si j'en avais la possibilité...


--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/

Avatar
Eric Belhomme
Cedric Blancher wrote in
news::

Dans sa prose, Eric Belhomme nous ecrivait :
non, mais selon que les requetes viennent du net ou du LAN, mes
services réagissent pas pareil, alors si je natte mes IP venant du
LAN vers la dmz, je suis marron !


Non plus, puisque tu les NATes avec l'IP de la patte DMZ de ton
firewall (ou une autre IP spécifique) alors que les requêtes du Net
viennent d'autres IP.

bah j'y avais pas pensé :-/

Ca mérite réflexion... je tenterai ca un de ces soir... tard...

Je sais pas qui de nous deux a du mal, mais je crois que tu devrais
dormir un peu ;)

a qui le dis tu :( mais c'est pas gagné... vivement les ouacances !



--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/