Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian lsNAT : No longer support implicit source local NAT

lsNAT : No longer support implicit source local NAT

5 réponses
Avatar
herve thibaud
Bonjour
J'ai un serveur interne 192.168.0.6 (web et mail)
une station 192.168.0.4
serveur et station sont derrière une freebox, configurée en routeur,
serveur et station connectés par wifi.
Pour pouvoir accéder au web du serveur 192.168.0.6 avec l'adresse
publique je n'ai pas trouvé d'autre solution que d'installer shorewall
sur la station et d'inclure une règle DNAT :
DNAT fw net:192.168.0.6 tcp smtp - 81.56.xxx.xxx qui traduit donc l'IP
publique en IP interne.
fw est donc la station elle même et net tout les appels fait sur la la
liaison wifi
Malheureusement cette règle qui est une traduction d'un appel sortant
n'est plus supportée par les nouveaux noyaux et j'ai bloqué la version
du noyau en place à 2.6.15.
Je ne vois pas de possibilité de faire cette traduction sur la freebox,
ce qui serait plus logique.

Qu'est ce qui peux être mis en place


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Pascal Hambourg
Salut,

herve thibaud a écrit :
J'ai un serveur interne 192.168.0.6 (web et mail)
une station 192.168.0.4
serveur et station sont derrière une freebox, configurée en routeur,
serveur et station connectés par wifi.
Pour pouvoir accéder au web du serveur 192.168.0.6 avec l'adresse
publique je n'ai pas trouvé d'autre solution que d'installer shorewall
sur la station et d'inclure une règle DNAT :
DNAT fw net:192.168.0.6 tcp smtp - 81.56.xxx.xxx qui traduit donc l'IP
publique en IP interne.
fw est donc la station elle même et net tout les appels fait sur la la
liaison wifi



Ce n'est pas un peu "riche" d'installer shorewall alors qu'une simple
règle iptables comme ci-dessous suffirait ?

iptables -t nat -A OUTPUT -d 81.56.xxx.xxx -p tcp --dport 25
-j DNAT --to-destination 192.168.0.6

Malheureusement cette règle qui est une traduction d'un appel sortant
n'est plus supportée par les nouveaux noyaux et j'ai bloqué la version
du noyau en place à 2.6.15.



Cette règle est toujours supportée par les noyaux récents, je viens de
vérifier avec le dernier 2.6.18.2. Par contre il y a eu une modification
du comportement de DNAT dans OUTPUT à partir de la version 2.6.11, d'où
le message "No longer support implicit source local NAT" qui n'est qu'un
avertissement et non une erreur. Ton noyau 2.6.15 doit logiquement
inclure ce changement.

Extrait du changeLog du noyau 2.6.11 :
[PATCH] Remove do_extra_mangle: double NAT on LOCAL_OUT

On NF_IP_LOCAL_OUT, when destination NAT changes the destination
interface, we also change the source address, so the packet is the
same as if it were generated to go that way in the first place. This
is not strictly necessary, I believe.

This patch rips that code out to see what breaks.

La différence avec les noyaux plus anciens, c'est qu'en cas de
changement d'interface de sortie induit par la nouvelle destination, la
cible DNAT ne modifie plus l'adresse source. Dans ton cas ça ne devrait
pas poser de problème puisque l'interface de sortie ne change pas :
c'est la même pour communiquer avec le serveur local et la Freebox.

Quand l'interface de sortie change à cause de la règle DNAT, on peut si
nécessaire modifier explicitement l'adresse source dans PREROUTING avec
une règle SNAT ou MASQUERADE. Il y a toutefois un cas où ça ne marche
pas : quand l'adresse source est une adresse de loopback (127.0.0.0/8),
le paquet est refusé. Je suppose que c'est parce que le routage de
sortie qui a lieu entre OUTPUT et POSTROUTING refuse d'envoyer un paquet
avec une adresse source 127.0.0.0/8 par une interface autre que
l'interface de loopback.

Je ne vois pas de possibilité de faire cette traduction sur la freebox,
ce qui serait plus logique.



Hélas la Freebox, comme tous les routeurs NAT basiques pas trop
élaborés, ne le permet pas.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
herve thibaud
Pascal Hambourg wrote:
Salut,

herve thibaud a écrit :
J'ai un serveur interne 192.168.0.6 (web et mail)
une station 192.168.0.4
serveur et station sont derrière une freebox, configurée en routeur,
serveur et station connectés par wifi.
Pour pouvoir accéder au web du serveur 192.168.0.6 avec l'adresse
publique je n'ai pas trouvé d'autre solution que d'installer shorewall
sur la station et d'inclure une règle DNAT :
DNAT fw net:192.168.0.6 tcp smtp - 81.56.xxx.xxx qui traduit donc l'IP
publique en IP interne.
fw est donc la station elle même et net tout les appels fait sur la la
liaison wifi



Ce n'est pas un peu "riche" d'installer shorewall alors qu'une simple
règle iptables comme ci-dessous suffirait ?

iptables -t nat -A OUTPUT -d 81.56.xxx.xxx -p tcp --dport 25
-j DNAT --to-destination 192.168.0.6

Malheureusement cette règle qui est une traduction d'un appel sortant
n'est plus supportée par les nouveaux noyaux et j'ai bloqué la version
du noyau en place à 2.6.15.



Cette règle est toujours supportée par les noyaux récents, je viens de
vérifier avec le dernier 2.6.18.2. Par contre il y a eu une
modification du comportement de DNAT dans OUTPUT à partir de la
version 2.6.11, d'où le message "No longer support implicit source
local NAT" qui n'est qu'un avertissement et non une erreur. Ton noyau
2.6.15 doit logiquement inclure ce changement.

Extrait du changeLog du noyau 2.6.11 :
[PATCH] Remove do_extra_mangle: double NAT on LOCAL_OUT

On NF_IP_LOCAL_OUT, when destination NAT changes the destination
interface, we also change the source address, so the packet is the
same as if it were generated to go that way in the first place. This
is not strictly necessary, I believe.

This patch rips that code out to see what breaks.

La différence avec les noyaux plus anciens, c'est qu'en cas de
changement d'interface de sortie induit par la nouvelle destination,
la cible DNAT ne modifie plus l'adresse source. Dans ton cas ça ne
devrait pas poser de problème puisque l'interface de sortie ne change
pas : c'est la même pour communiquer avec le serveur local et la Freebox.

Quand l'interface de sortie change à cause de la règle DNAT, on peut
si nécessaire modifier explicitement l'adresse source dans PREROUTING
avec une règle SNAT ou MASQUERADE. Il y a toutefois un cas où ça ne
marche pas : quand l'adresse source est une adresse de loopback
(127.0.0.0/8), le paquet est refusé. Je suppose que c'est parce que le
routage de sortie qui a lieu entre OUTPUT et POSTROUTING refuse
d'envoyer un paquet avec une adresse source 127.0.0.0/8 par une
interface autre que l'interface de loopback.

Je ne vois pas de possibilité de faire cette traduction sur la freebox,
ce qui serait plus logique.



Hélas la Freebox, comme tous les routeurs NAT basiques pas trop
élaborés, ne le permet pas.




J'ai essayé la règle (avec port 80) sur un poste avec un noyau
2.6.18-rc5-git6. J'accède aux sites en entrant leurs adresses.

Merci



ci dessous un morceau des traces que je trouve dans le fichier syslog

europe:/var/log# cat syslog | grep NAT


[...]
Nov 5 07:44:12 europe kernel: NAT: no longer support implicit source
local NAT
Nov 5 07:44:12 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 6 10:18:54 europe kernel: NAT: no longer support implicit source
local NAT
Nov 6 10:18:54 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 7 09:25:22 europe kernel: NAT: no longer support implicit source
local NAT
Nov 7 09:25:22 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 8 09:05:53 europe kernel: NAT: no longer support implicit source
local NAT
Nov 8 09:05:53 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 8 14:15:23 europe kernel: NAT: no longer support implicit source
local NAT
Nov 8 14:15:23 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 9 08:51:35 europe kernel: NAT: no longer support implicit source
local NAT
Nov 9 08:51:35 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 10 09:19:46 europe kernel: NAT: no longer support implicit source
local NAT
Nov 10 09:19:46 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85
Nov 11 09:18:08 europe kernel: NAT: no longer support implicit source
local NAT
Nov 11 09:18:08 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85


[...]

merci.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Pascal Hambourg
herve thibaud a écrit :



J'ai essayé la règle (avec port 80) sur un poste avec un noyau
2.6.18-rc5-git6. J'accède aux sites en entrant leurs adresses.



Tu veux dire leurs noms de domaine qui pointent sur l'adresse IP
publique ? Problème réglé, alors.
Mais ça aurait dû marcher aussi avec shorewall qui devait générer une
règle iptables similaire (à vérifier avec iptables-save). Du moins je le
suppose, ne connaissant rien à la syntaxe de shorewall. Que se
passait-il exactement ?

ci dessous un morceau des traces que je trouve dans le fichier syslog

europe:/var/log# cat syslog | grep NAT



[...]
Nov 5 07:44:12 europe kernel: NAT: no longer support implicit source local NAT
Nov 5 07:44:12 europe kernel: NAT: packet src 192.168.0.6 -> dst 81.56.198.85




[...]
Ce message d'avertissement du noyau apparaît au plus une fois à chaque
chargement des modules NAT du noyau, donc en gros une fois par
redémarrage sauf si on s'amuse à décharger et recharger les modules. La
formulation de la seconde ligne est un peu étrange puisque 'src' est
l'adresse destination (!) après DNAT, 'dst' étant l'adresse destination
originale. Je pense que c'est un bug, sans gravité.

D'après ce que je comprends du code source de la fonction
warn_if_extra_mangle() qui émet le message, 'src' (paramètre srcip)
devrait être l'adresse source du paquet et 'dst' (paramètre dstip) la
nouvelle adresse destination. L'appel de la fonction a dû s'emmêler les
pinceaux. :-)
D'ailleurs dans ton cas, si la fonction warn_if_extra_mangle() était
appelée avec les bons paramètres, tu n'aurais même pas ce message
puisque l'adresse source n'a pas lieu de changer.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
herve thibaud
Pascal Hambourg wrote:
herve thibaud a écrit :



J'ai essayé la règle (avec port 80) sur un poste avec un noyau
2.6.18-rc5-git6. J'accède aux sites en entrant leurs adresses.



Tu veux dire leurs noms de domaine qui pointent sur l'adresse IP
publique ? Problème réglé, alors.


Exact
Mais ça aurait dû marcher aussi avec shorewall qui devait générer une
règle iptables similaire (à vérifier avec iptables-save). Du moins je
le suppose, ne connaissant rien à la syntaxe de shorewall. Que se
passait-il exactement ?



Ca marche avec shorewall. Juste que je n'avais jamais vu ce message
d'erreur. Ce qui m'a inquiété c'est de pouvoir me retrouver avec une
erreur plus grave qui interdise le démarrage de shorewall. En fait c'est
ce qui m'était arrivé en tentant d'installer un noyau plus récent.
Peut-être il y avait-il un autre problème, mais je ne suis qu'un amateur
et franchement la doc tout en anglais déjà que je trouve difficile
d'avaler quand c'est en français ...
Peut-être que je me trompe mais il me semble que sur l'autre poste avec
un noyau plus récent (mise à jour régulière à partir de kernel.org), une
telle règle empéchait le démarrage de shorewall. Mais je ne me suis pas
acharner

ci dessous un morceau des traces que je trouve dans le fichier syslog

europe:/var/log# cat syslog | grep NAT



[...]
Nov 5 07:44:12 europe kernel: NAT: no longer support implicit
source local NAT
Nov 5 07:44:12 europe kernel: NAT: packet src 192.168.0.6 -> dst
81.56.198.85




[...]
Ce message d'avertissement du noyau apparaît au plus une fois à chaque
chargement des modules NAT du noyau, donc en gros une fois par
redémarrage sauf si on s'amuse à décharger et recharger les modules.
La formulation de la seconde ligne est un peu étrange puisque 'src'
est l'adresse destination (!) après DNAT, 'dst' étant l'adresse
destination originale. Je pense que c'est un bug, sans gravité.


En effet, la règle que tu me donnes, laisse la même trace dans syslog.

D'après ce que je comprends du code source de la fonction
warn_if_extra_mangle() qui émet le message, 'src' (paramètre srcip)
devrait être l'adresse source du paquet et 'dst' (paramètre dstip) la
nouvelle adresse destination. L'appel de la fonction a dû s'emmêler
les pinceaux. :-)
D'ailleurs dans ton cas, si la fonction warn_if_extra_mangle() était
appelée avec les bons paramètres, tu n'aurais même pas ce message
puisque l'adresse source n'a pas lieu de changer.




Là je suis largué depuis longtemps... je suis devenu allergique aux
concepts informatiques.

Merci


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Pascal Hambourg
herve thibaud a écrit :

Problème réglé, alors.



Exact



Bien. Merci à toi d'avoir attiré mon attention sur ce changement de
comportement de Netfilter/iptables que je ne connaissais pas. J'en ai
profité pour recenser les autres changements dans cette partie du noyau
au fur et à mesure des versions 2.6.x. Le résultat est là :
http://www.plouf.fr.eu.org/bazar/netfilter/changements-netfilter-2.6.html

Si quelqu'un voit d'autres changements de comportement signficatifs qui
m'ont échappé, merci de m'en faire part.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact