J'ai un serveur Linux (CentOS 5.5) qui a un accès direct à l'Internet avec une adresse IP fixe. L'adresse IP est 200.29.X.Y. La passerelle a été donnée par le centre de données (200.29.X.Z) et la connexion fonctionne parfaitement.
Je dois me connecter à une autre machine située sur un réseau local distant. Nous avons convenu de le faire par le biais d'un VPN, ils ont donc configuré un tunnel (IPsec utilisant une clé prépartagée) et ils nous ont donné toutes les informations (pair, domaine de cryptage, propriétés de la phase 1, et propriétés de la phase 2).
Le problème est que ma machine n'est pas derrière un firewall, et que je n'ai pas accès au firewall de mon centre de données... Le pare-feu doit donc être créé sur la même machine (en utilisant n'importe quel logiciel de ligne de commande VPN).
Le problème est que si ma machine a le pare-feu (et configure le VPN), le pair serait le même domaine de cryptage (c'est-à-dire la même adresse IP pour le pair et le domaine de cryptage)...
L'autre partie m'a dit que c'était faux et qu'en utilisant cette configuration, leur pare-feu ne savait pas où envoyer les réponses (puisque le domaine de cryptage est le même pair).
Pour tenter de résoudre ce problème, j'ai créé une interface Ethernet virtuelle appelée eth0.4 qui a une adresse IP locale, 192.160.0.4 ; et j'ai dit à l'autre partie de configurer cela comme mon domaine de cryptage, mais cela ne fonctionne toujours pas.
En faisant quelques tests locaux, à partir de l'adresse IP virale interne, 192.160.0.4, je ne peux pas faire de ping avec mon adresse IP réelle, 200.29.X.Y ( ping -I eth0.4 200.29.X.Y )... J'ai ajouté quelques règles de redirection sur iptables, mais mon adresse IP interne ne peut toujours pas communiquer avec mon adresse IP réelle... Je pense donc que cette "adresse IP locale virtuelle" ne résoudra pas mon problème (à moins que je n'aie ajouté des règles de redirection incorrectes).
J'utilise openswan pour configurer le VPN et selon l'autre partie, ils reçoivent les détails de la phase I, ils sont corrects, mais il y a un problème avec la réponse... donc le tunnel n'est jamais fait (en fait, la phase I ne se termine jamais).
010 "net-to-net" #1 : STATE_MAIN_I1 : retransmission ; attendra 20 s pour la réponse
010 "net-to-net" #1 : STATE_MAIN_I1 : retransmission ; attendra 40 s pour la réponse
010 "net-to-net" #1 : STATE_MAIN_I1 : retransmission ; attendra 40 s pour la réponse
010 "net-to-net" #1 : STATE_MAIN_I1 : retransmission ; attendra 40 s pour la réponse
031 "net-to-net" #1 : nombre max de retransmissions (20) atteint STATE_MAIN_I1. Pas de réponse (ou pas de réponse acceptable) à notre premier message IKE.
000 "net-to-net" #1 : début de l'essai de frappe 2 d'un nombre illimité, mais relâchement de la pression pour toujours...
Le log d'openswan ne me donne pas plus d'informations (il envoie les choses correctes mais pas de réponse), et tcpdump me dit toujours que j'envoie des paquets mais pas de réponses...
Des suggestions ?
