J'essaie de transmettre des paquets de HostA à HostB en utilisant le tunneling ip-in-ip. Bien que les paquets atteignent leur destination, ils ne sont pas décapsulés par l'hôte récepteur et sont donc abandonnés par la suite. J'ai l'impression d'avoir épuisé toutes les ressources de Google. En gros, il semble que l'hôte récepteur n'envoie jamais les paquets au dispositif de tunnel pour les décapsuler.
Le tutoriel que j'ai le plus utilisé en essayant ceci est le suivant aquí J'ai essayé plusieurs méthodes et différents tutoriels, mais je suis toujours confronté au même problème. Que me manque-t-il ?
Sur l'hôte A :
ip tunnel add tun0 mode ipip local $hostA remote $hostB
ip link set tun0 up
ip addr add 10.10.10.1/24 dev tun0
Sur HostB
ip tunnel add tun0 mode ipip local $hostB remote $hostA
ip link set tun0 up
ip addr add 10.10.10.2/24 dev tun0
Maintenant, quand je ping 10.10.10.2
Je n'obtiens aucune réponse. HostB montre (via tcpdump -c 10 -nn src host 10.10.10.1 or src host $hostA
):
(édité pour enlever l'adresse IP réelle des hôtes)
18:18:56.026192 IP [HostA eth0 IP] > [HostB eth0 IP]: IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 41073, seq 69, length 64 (ipip-proto-4)
Les paquets entrants ressemblent à ce qu'ils devraient être, mais ils ne sont jamais décapsulés. tcpdump -nni tun0
n'a pas de sortie, et aucune réponse n'est jamais faite au ping.
1 votes
Êtes-vous sûr que les règles de votre pare-feu permettent à la demande d'être reçue par HostB ?
0 votes
J'ai (pour les besoins de ce test) fait
iptables -A INPUT -p icmp -j ACCEPT
0 votes
Euh. Ok. Oui. Donc, en ajoutant
-p ipencap
a réglé le problème... wow. Tu es génial. Si vous voulez mettre ça dans le champ des réponses, je le marquerai comme accepté. Sinon, je vais juste supprimer la Q0 votes
Ce sont toujours ces fichues règles de pare-feu. >smile<