NB : toute les machines sont sous linux.
le routeur a son IP publique attribué par un FAI, et j'ai 4 adresses
publique pour ma DMZ. ip_pub/30
Pour ne pas griller des adresses en LAN/BROADCAST et pouvoir mettre 4
machine en DMZ j'ai utilisé une adresse privé pour l'interconnexion
avec le routeur et j'affecte des adresses publique en utilisant un alias
(eth0:0)
j'ai donc sur la machine1
eth0 10.0.0.1
eth0:0 ip_pub1
ip route add default 10.0.0.254 (ethernet routeur)
ma machine est joignable sans problème sur son ip_pub1
pour sortir avec mon IP_pub1 je fais un
iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1
et ca marche tres bien.
maintenant j'aimerai pouvoir utiliser ip_pub1 pour faire du MASQUERADE
car je vais ajouter une carte et un réseau privé a machine1.
eth1 192.168.0.1
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or
je veux $ip_pub1
et je ne sais plus comment faire pour nater les paquets forwardé avec
mon ip_pub1
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
Pascal Hambourg
Salut,
dominix a écrit :
le routeur a son IP publique attribué par un FAI, et j'ai 4 adresses publique pour ma DMZ. ip_pub/30 Pour ne pas griller des adresses en LAN/BROADCAST
Je connais le problème. Pour ma part, résolu avec des VPN point à point.
et pouvoir mettre 4 machine en DMZ j'ai utilisé une adresse privé pour l'interconnexion avec le routeur et j'affecte des adresses publique en utilisant un alias (eth0:0) j'ai donc sur la machine1 eth0 10.0.0.1 eth0:0 ip_pub1 ip route add default 10.0.0.254 (ethernet routeur)
ma machine est joignable sans problème sur son ip_pub1
pour sortir avec mon IP_pub1 je fais un iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1 et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du tout avec certains protocoles. Et surtout c'est évitable ici. Tu pourrais simplement forcer l'adresse source par défaut dans la route par défaut :
ip route add default 10.0.0.254 src $ip_pub1
maintenant j'aimerai pouvoir utiliser ip_pub1 pour faire du MASQUERADE car je vais ajouter une carte et un réseau privé a machine1. eth1 192.168.0.1
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or je veux $ip_pub1 et je ne sais plus comment faire pour nater les paquets forwardé avec mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait plus haut, à l'exception de l'option -s à adapter (et d'une option -o en plus) :
le routeur a son IP publique attribué par un FAI, et j'ai 4 adresses
publique pour ma DMZ. ip_pub/30
Pour ne pas griller des adresses en LAN/BROADCAST
Je connais le problème. Pour ma part, résolu avec des VPN point à point.
et pouvoir mettre 4
machine en DMZ j'ai utilisé une adresse privé pour l'interconnexion
avec le routeur et j'affecte des adresses publique en utilisant un alias
(eth0:0)
j'ai donc sur la machine1
eth0 10.0.0.1
eth0:0 ip_pub1
ip route add default 10.0.0.254 (ethernet routeur)
ma machine est joignable sans problème sur son ip_pub1
pour sortir avec mon IP_pub1 je fais un
iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1
et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du
tout avec certains protocoles. Et surtout c'est évitable ici. Tu
pourrais simplement forcer l'adresse source par défaut dans la route par
défaut :
ip route add default 10.0.0.254 src $ip_pub1
maintenant j'aimerai pouvoir utiliser ip_pub1 pour faire du MASQUERADE
car je vais ajouter une carte et un réseau privé a machine1.
eth1 192.168.0.1
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or
je veux $ip_pub1
et je ne sais plus comment faire pour nater les paquets forwardé avec
mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait
plus haut, à l'exception de l'option -s à adapter (et d'une option -o en
plus) :
le routeur a son IP publique attribué par un FAI, et j'ai 4 adresses publique pour ma DMZ. ip_pub/30 Pour ne pas griller des adresses en LAN/BROADCAST
Je connais le problème. Pour ma part, résolu avec des VPN point à point.
et pouvoir mettre 4 machine en DMZ j'ai utilisé une adresse privé pour l'interconnexion avec le routeur et j'affecte des adresses publique en utilisant un alias (eth0:0) j'ai donc sur la machine1 eth0 10.0.0.1 eth0:0 ip_pub1 ip route add default 10.0.0.254 (ethernet routeur)
ma machine est joignable sans problème sur son ip_pub1
pour sortir avec mon IP_pub1 je fais un iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1 et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du tout avec certains protocoles. Et surtout c'est évitable ici. Tu pourrais simplement forcer l'adresse source par défaut dans la route par défaut :
ip route add default 10.0.0.254 src $ip_pub1
maintenant j'aimerai pouvoir utiliser ip_pub1 pour faire du MASQUERADE car je vais ajouter une carte et un réseau privé a machine1. eth1 192.168.0.1
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or je veux $ip_pub1 et je ne sais plus comment faire pour nater les paquets forwardé avec mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait plus haut, à l'exception de l'option -s à adapter (et d'une option -o en plus) :
pour sortir avec mon IP_pub1 je fais un iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1 et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du tout avec certains protocoles. Et surtout c'est évitable ici. Tu pourrais simplement forcer l'adresse source par défaut dans la route par défaut :
ip route add default 10.0.0.254 src $ip_pub1
excellent je ne connaissait pas l'option src,
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or je veux $ip_pub1 et je ne sais plus comment faire pour nater les paquets forwardé avec mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait plus haut, à l'exception de l'option -s à adapter (et d'une option -o en plus) :
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
merci en tout cas de m'avoir rafraîchis les idées, ça marche comme je veux maintenant.
-- Dominix
Pascal Hambourg a écrit :
Salut,
dominix a écrit :
...
pour sortir avec mon IP_pub1 je fais un
iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1
et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du
tout avec certains protocoles. Et surtout c'est évitable ici. Tu
pourrais simplement forcer l'adresse source par défaut dans la route par
défaut :
ip route add default 10.0.0.254 src $ip_pub1
excellent je ne connaissait pas l'option src,
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or
je veux $ip_pub1
et je ne sais plus comment faire pour nater les paquets forwardé avec
mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait
plus haut, à l'exception de l'option -s à adapter (et d'une option -o en
plus) :
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que
SNAT ne maintenait pas les connexions et qu'il fallait impérativement
faire un DNAT approprié, apparemment ce n'est plus la peine.
merci en tout cas de m'avoir rafraîchis les idées, ça marche comme je
veux maintenant.
pour sortir avec mon IP_pub1 je fais un iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source $ip_pub1 et ca marche tres bien.
Bof, le NAT c'est quand même pas terrible, ça marche mal voire pas du tout avec certains protocoles. Et surtout c'est évitable ici. Tu pourrais simplement forcer l'adresse source par défaut dans la route par défaut :
ip route add default 10.0.0.254 src $ip_pub1
excellent je ne connaissait pas l'option src,
si je MASQUERADE sur eth0 les paquets auront 10.0.0.1 comme adresse or je veux $ip_pub1 et je ne sais plus comment faire pour nater les paquets forwardé avec mon ip_pub1
Je ne vois pas où est le problème, c'est exactement comme tu as fait plus haut, à l'exception de l'option -s à adapter (et d'une option -o en plus) :
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
merci en tout cas de m'avoir rafraîchis les idées, ça marche comme je veux maintenant.
-- Dominix
Pascal Hambourg
dominix a écrit :
ip route add default 10.0.0.254 src $ip_pub1
excellent je ne connaissait pas l'option src,
Oui, dommage qu'il n'y ai pas l'équivalent pour les routes IPv6, d'autant plus que la sélection d'adresse source en IPv6 est parfois quelque peu discutable...
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes* les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
La différence entre SNAT et MASQUERADE, outre la sélection de la nouvelle adresse source, c'est que MASQUERADE efface les connexions masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a servi est supprimée ou modifiée.
dominix a écrit :
ip route add default 10.0.0.254 src $ip_pub1
excellent je ne connaissait pas l'option src,
Oui, dommage qu'il n'y ai pas l'équivalent pour les routes IPv6,
d'autant plus que la sélection d'adresse source en IPv6 est parfois
quelque peu discutable...
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que
SNAT ne maintenait pas les connexions et qu'il fallait impérativement
faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
les opérations de NAT d'iptables maintiennent l'état et font
implicitement l'opération réciproque dans le sens retour. Dans le cas
contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de
règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas
dit), et ça marchait.
La différence entre SNAT et MASQUERADE, outre la sélection de la
nouvelle adresse source, c'est que MASQUERADE efface les connexions
masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a
servi est supprimée ou modifiée.
Oui, dommage qu'il n'y ai pas l'équivalent pour les routes IPv6, d'autant plus que la sélection d'adresse source en IPv6 est parfois quelque peu discutable...
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes* les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
La différence entre SNAT et MASQUERADE, outre la sélection de la nouvelle adresse source, c'est que MASQUERADE efface les connexions masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a servi est supprimée ou modifiée.
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai commencé avec un noyau 0.99 :) Et j'ai le souvenir de vrai casse tête avec ça.
les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le retour se faisait donc vers la bonne machine, pas la peine de DNATer.
La différence entre SNAT et MASQUERADE, outre la sélection de la nouvelle adresse source, c'est que MASQUERADE efface les connexions masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a servi est supprimée ou modifiée.
bon ça marche. mais je suis de la vieille école, j'avais le souvenir
que SNAT ne maintenait pas les connexions et qu'il fallait
impérativement faire un DNAT approprié, apparemment ce n'est plus la
peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai
commencé avec un noyau 0.99 :)
Et j'ai le souvenir de vrai casse tête avec ça.
les opérations de NAT d'iptables maintiennent l'état et font
implicitement l'opération réciproque dans le sens retour. Dans le cas
contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de
règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas
dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le
retour se faisait donc vers la bonne machine, pas la peine de DNATer.
La différence entre SNAT et MASQUERADE, outre la sélection de la
nouvelle adresse source, c'est que MASQUERADE efface les connexions
masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a
servi est supprimée ou modifiée.
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai commencé avec un noyau 0.99 :) Et j'ai le souvenir de vrai casse tête avec ça.
les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le retour se faisait donc vers la bonne machine, pas la peine de DNATer.
La différence entre SNAT et MASQUERADE, outre la sélection de la nouvelle adresse source, c'est que MASQUERADE efface les connexions masqueradées lorsque l'interface de sortie tombe ou l'adresse qui a servi est supprimée ou modifiée.
bien noté
Pascal Hambourg
dominix a écrit :
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai commencé avec un noyau 0.99 :)
Je doute que ce soit avec ipchains. De mémoire, ipchains n'avait pas d'équivalent de la cible SNAT mais seulement la cible MASQ, équivalent de la cible MASQUERADE d'iptables. Tu confonds peut-être avec le NAT sans état intégré au routage configuré avec ip rule et ip route, pour lequel il fallait définir explicitement les opérations dans les deux sens ?
les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le retour se faisait donc vers la bonne machine, pas la peine de DNATer.
Pas suffisant. Si un processus envoie un paquet avec l'adresse source privée (avant MASQUERADE) et reçoit une réponse avec l'adresse destination publique, ça ne marche pas car il attend une réponse sur l'adresse privée. Il faut donc remettre l'adresse d'origine au retour.
dominix a écrit :
bon ça marche. mais je suis de la vieille école, j'avais le souvenir
que SNAT ne maintenait pas les connexions et qu'il fallait
impérativement faire un DNAT approprié, apparemment ce n'est plus la
peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai
commencé avec un noyau 0.99 :)
Je doute que ce soit avec ipchains. De mémoire, ipchains n'avait pas
d'équivalent de la cible SNAT mais seulement la cible MASQ, équivalent
de la cible MASQUERADE d'iptables. Tu confonds peut-être avec le NAT
sans état intégré au routage configuré avec ip rule et ip route, pour
lequel il fallait définir explicitement les opérations dans les deux sens ?
les opérations de NAT d'iptables maintiennent l'état et font
implicitement l'opération réciproque dans le sens retour. Dans le cas
contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de
règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas
dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le
retour se faisait donc vers la bonne machine, pas la peine de DNATer.
Pas suffisant. Si un processus envoie un paquet avec l'adresse source
privée (avant MASQUERADE) et reçoit une réponse avec l'adresse
destination publique, ça ne marche pas car il attend une réponse sur
l'adresse privée. Il faut donc remettre l'adresse d'origine au retour.
bon ça marche. mais je suis de la vieille école, j'avais le souvenir que SNAT ne maintenait pas les connexions et qu'il fallait impérativement faire un DNAT approprié, apparemment ce n'est plus la peine.
Ça n'a jamais été nécessaire, je me demande d'où tu sors ça. *Toutes*
probablement d'avant iptables, ipchain ou autre, après tout j'ai commencé avec un noyau 0.99 :)
Je doute que ce soit avec ipchains. De mémoire, ipchains n'avait pas d'équivalent de la cible SNAT mais seulement la cible MASQ, équivalent de la cible MASQUERADE d'iptables. Tu confonds peut-être avec le NAT sans état intégré au routage configuré avec ip rule et ip route, pour lequel il fallait définir explicitement les opérations dans les deux sens ?
les opérations de NAT d'iptables maintiennent l'état et font implicitement l'opération réciproque dans le sens retour. Dans le cas contraire on ne s'en sortirait jamais. D'ailleurs tu n'avais pas de règle DNAT pour accompagner ta première règle SNAT (ou tu ne l'as pas dit), et ça marchait.
oui car l'adresse sourcé manuellement appartenait déjà a la machine. le retour se faisait donc vers la bonne machine, pas la peine de DNATer.
Pas suffisant. Si un processus envoie un paquet avec l'adresse source privée (avant MASQUERADE) et reçoit une réponse avec l'adresse destination publique, ça ne marche pas car il attend une réponse sur l'adresse privée. Il faut donc remettre l'adresse d'origine au retour.
