Distribution EOLE » Outils Eole » ERA

Que voulez faire exactement ?

Si on ping le serveur A, les pings sont redirigés vers le serveur B ?

Quel est l'intérêt ?

Test de base, rien de plus. Effectivement pour pinger un serveur de la DMZ, depuis n'importe quel poste.
Je reconnais que ça a pas un grand intéret...

N'empeche, on pouvait le faire avec les anciennes versions. Maintenant, cette directive empeche la création du fichier des règles iptables.

L'intérêt dépend du contexte :
soit un lan séparé du wan par un amon
Le tout dans un adressage privé.

Sur l'amon, on rajoute une zone dédiée à une box Internet dans un adressage non routé intranet

Si on veut faire du traffic vers Internet via la box => nécessite du nat sinon pas de retour.
ICMP est juste là pour les diagnotics.

Je présume qu’il n’y a pas besoin de gérer --icmp-type ?

root@amon:~# iptables -p icmp -h
iptables v1.4.4
[...]
icmp match options:
[!] --icmp-type typename        match icmp type
[!] --icmp-type type[/code]     (or numeric type or type/code)
Valid ICMP Types:
any
echo-reply (pong)
destination-unreachable
   network-unreachable
   host-unreachable
   protocol-unreachable
   port-unreachable
   fragmentation-needed
   source-route-failed
   network-unknown
   host-unknown
   network-prohibited
   host-prohibited
   TOS-network-unreachable
   TOS-host-unreachable
   communication-prohibited
   host-precedence-violation
   precedence-cutoff
source-quench
redirect
   network-redirect
   host-redirect
   TOS-network-redirect
   TOS-host-redirect
echo-request (ping)
router-advertisement
router-solicitation
time-exceeded (ttl-exceeded)
   ttl-zero-during-transit
   ttl-zero-during-reassembly
parameter-problem
   ip-header-bad
   required-option-missing
timestamp-request
timestamp-reply
address-mask-request
address-mask-reply

Autre cas de figure:

Sur un amonhorus, si on ajoute une zone pour le réseau pédagogique et que l'on veuille autoriser le ping du conteneur fichier depuis le péda. Je ne suis jamais parvenu à communiquer vers l'ip link d'un conteneur à partir d'une zone qui n'est pas sur le même réseau local que cette ip link de ce conteneur. Du coup pour y parvenir j'ai du creer les regles suivantes (10.4.201.6 est l'ip link du conteneur fichier):

iptables -t nat -I PREROUTING -i eth2 -d 10.4.201.6 -p icmp -m state --state NEW -m icmp --icmp-type 8 -j DNAT --to-destination 192.0.2.52
iptables -A FORWARD -i eth2 -o br0 -d 192.0.2.52 -p icmp -m state --state NEW -m icmp --icmp-type 8 -j ACCEPT

Si on essaie de le faire par une directive dans era on tombe sur le message d'erreur

Cependant j'ai l'impression que cela n'est pas uniquement lié à du DNAT. Je prend un autre exemple:

Toujours sur amonecole, je veux créer une regle qui autorise juste le ping depuis le réseau admin vers l'ip eth1 (je sais à priori c'est inutile car cela fonctionne déja, mais c'est pour le principe). Si je crée une extrémité sur la zone bastion ayant comme valeur %%adresse_ip_eth1 (je sais il faut choisir l'extrémité "bastion" qui est prévu à cet effet mais là encore c'est pour le principe) et que je crée une directive qui autorise echo-request depuis la zone admin entière vers cette adresse j'ai également ce message d'erreur (alors que je n'en ai pas si je fais la même chose avec un autre service, par exemple autoriser le port 53 depuis la zone admin entière vers cette extrémité)

En espérant que cela puisse aider