Vous n'êtes pas identifié(e).
Dernière modification par keitaro35 (21-11-2015 18:52:50)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
où $LAN est le nom de l'interface LAN.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
Hors ligne
même résultat. impossible d'accéder au serveur
Je suis un peu surpris. Si c'était un problème de filtrage à état dû au routage asymétrique, ces règles acceptant inconditionnellement tout le trafic entrant et ressortant par l'interface LAN devrait supprimer le blocage. Tu es sûr de n'avoir pas fait d'erreur dans le nom de l'interface LAN sur chaque machine ?
Eventuellement, ça pourrait être un problème tordu de MTU à cause de la liaison SDSL. Dans ce cas ce n'est pas l'établissement de la connexion TCP qui coincerait mais la transmission de gros segments. Tu peux tester en envoyant des pings de grande taille (~1500). Tu peux aussi essayer de baisser un peu le MTU du poste client ou du serveur (~1460 maxi), pour voir. Pour Linux :
Dernière modification par raleur (21-11-2015 22:14:27)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Non toujours rien si je n'ajoute pas l'adresse de mon routeur 2 sur mon serveur du site 2.
Qu'entends-tu exactement par "ajouter l'adresse du routeur 2 sur le serveur du site 2" ?
Il me masque mon IP avec l'@IP du routeur
Tu veux dire que les routeurs Debian font du NAT sur le trafic renvoyé vers le LAN ? S'il y a bien une chose qui ne marche pas avec le routage asymétrique, c'est le NAT "à état" (stateful NAT) tel que le font les cibles SNAT, DNAT ou MASQUERADE d'iptables. Qu'affiche "iptables-save -t nat" ?
Dernière modification par raleur (21-11-2015 22:37:00)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par keitaro35 (22-11-2015 10:30:55)
Hors ligne
modifier le réseau source si l'adresse du PC dans le site 1 est différente (192.168.100.0/24).
pour annuler :
ou bien
pour annuler :
Dernière modification par raleur (22-11-2015 11:36:26)
Il vaut mieux montrer que raconter.
Hors ligne
je veux bien un cours sur le problème
Hors ligne
Quand le suivi de connexion TCP "lâche" est activé (par défaut), un segment TCP non SYN d'une connexion inconnue (par exemple une connexion déjà établie au moment où le module de suivi de connexion est chargé) est classé dans l'état NEW et la connexion TCP est prise en cours. Quand il est désactivé, un tel segment est classé dans l'état INVALID. Ceci a un effet sur le NAT à état : les règles de la table nat ne s'appliquent pas aux paquets dans l'état INVALID.
Dans ton cas, le routeur Debian 1 n'a pas vu passer le paquet initial SYN du poste du site 2 et voit arriver le paquet de réponse SYN/ACK du poste du site 1. Avec nf_conntrack_tcp_loose=1, ce paquet est néanmoins classé dans l'état NEW et les règles MASQUERADE peuvent s'appliquer. Problème : quand ce paquet de réponse arrive au poste du site 2, il n'a pas la bonne adresse source qui a été modifiée, donc le poste ne le reconnaît pas comme une réponse. Avec nf_conntrack_tcp_loose=0, le paquet a l'état INVALID et son adresse source n'est pas modifiée. On devrait pouvoir obtenir le même résultat en empêchant le paquet d'atteindre les règles de MASQUERADING (le premier test proposé).
Attention : ce ne sont que des tests pour valider l'hypothèse, pas des correctifs. Ils ont tous les deux potentiellement des effets secondaires.
La vraie solution passe par une remise à plat du routage et des règles de masquerading inter-LAN.
Dernière modification par raleur (22-11-2015 12:28:03)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (22-11-2015 12:40:14)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par keitaro35 (22-11-2015 12:54:32)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
serait mieux adaptée , a moins que son ip publique n'est pas statique , auquel cas le MASQUERADE serait la solution.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Il reste encore du masquerading à l'aller. Toutes ces règles MASQUERADE sur les interfaces autres que WAN sont-elles vraiment nécessaires ? En plus de compliquer les choses, elles empêchent de savoir quel poste est à l'origine d'une connexion, sans oublier que certains protocoles comme FTP ne sont pas toujours bien pris en charge par le NAT.
Oui, je viens d'en faire l'expérience. Car si je masque pas mon 192.168.101.0/24 sur mon site 2, je ne peux plus attaquer mon appli métier qui se trouve sur le 192.168.1.0/24 de mon site 1, car le 192.168.101.0/24 n'est pas connu de mon routeur opérateur je suppose.
Je suppose qu'à l'inverse, si je ne masque pas mon 192.168.100.0/24 sur mon site 1, je ne pourrais joindre les adresses en 192.168.2.0/24 sur mon site 2 car même problème.
Pour les autres, en effet, je peux les supprimer. Je testerai jeudi car je profiterai d'une coupure électrique sur mon site principal pour "m'amuser" à tester sans impacter le réseau
Hors ligne