Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 21-11-2015 19:50:43

keitaro35
Membre
Inscription : 21-11-2015

Ping OK mais c'est tout...

Bonjour à tous,,

Voila, j'ai un souci qui fait que bientôt, je n'aurais plus de cheveux. Je viens donc solliciter de l'aide.
Voici ma configuration:

Site 1
=>routeur opérateur en 192.168.1.254
=>routeur Debian serveur 1:
- WAN sur eth0 via une @IP publique
- LAN sur eth1 en 192.168.1.1
- LAN2 sur eth1:0 en 192.168.100.1
- VPN sur tun0 en 192.168.254.1

Site 2
=>routeur opérateur en 192.168.2.254
=>routeur Debian serveur 2:
- WAN sur ppp0/eth0 via une @IP publique
- LAN sur eth0 en 192.168.2.1
- LAN2 sur eth0:0 en 192.168.101.1
- VPN sur tun0 en 192.168.254.2

Par défaut, les deux LAN 192.168.1.0/24 et 192.168.2.0/24 communique par les routeurs opérateurs. Sauf qu'ils sont tombés cette semaine, j'ai donc passé tout le trafic par le VPN. Cela fonctionnait sur un pied mais fonctionnait quand même.

J'ai profité aujourd'hui de la remise en état du lien principal pour faire une vrai config' de secours. Tous les réseaux communiquent bien entre eux (chose qui n'était pas le cas jusque la) en passant par le VPN.

Par défaut, la passerelle sur mes postes clients est le serveur Debian du site, avec sur chacun d'eux, une route statique qui pointe le réseau du site distant via le routeur opérateur. Tout fonctionne à 90%, les pings répondent partout. Mais impossible de me connecter de mon site 2 vers mon site 1 en TSE par exemple alors que le ping du serveur est OK. J'ai beau regarder mon parefeu, j'ai aucun blocage. J'avoue ne plus comprendre.

Si je mets la passerelle opérateur sur mes postes clients, aucun problème de connexion, le TSE fonctionne bien.
Et si je repasse tout sur mon VPN, tout fonctionne également.

Avez-vous une idée? Je suis preneur de toute idée.

Dernière modification par keitaro35 (21-11-2015 19:52:50)

Hors ligne

#2 21-11-2015 20:47:57

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Tu peux faire des captures de trafic sur chaque interface en chemin pour voir ce qui se passe.
As-tu essayé avec autre chose que TSE et le ping ? Dans l'autre sens ?
Quelles sont les règles iptables sur les routeurs Debian (iptables-save) ? Permettent-elle le routage asymétrique ? Le filtrage "à état" ne marche pas bien avec le routage asymétrique.

Pour rappel, le routage est dit asymétrique lorsque les chemins suivis dans un sens et dans l'autre sont différents :
Site 1 vers site 2 : source > routeur Debian 1 > routeur opérateur 1 > routeur opérateur 2 > destination (ne passe pas par le routeur Debian 2)
Site 2 vers site 1 : source > routeur Debian 2 > routeur opérateur 2 > routeur opérateur 1 > destination (ne passe pas par le routeur Debian 1)

PS : pas terrible d'utiliser la même interface ethernet pour le LAN et le WAN. C'est du PPPoE avec un modem ethernet en bridge ?

Hors ligne

#3 21-11-2015 21:30:08

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Je crois que tu as mis le doigt sur le problème. J'ai fait un test simple. J'ai ajouté la route de mon routeur opérateur sur mon serveur tse site 1, et depuis mon site 2 et la, pas de problème. En gros, cela donne:

PC site 2 > routeur Debian 2 > routeur opérateur 2 > routeur opérateur 1 > destination (KO si pas de route sur destination car doit essayer de repasser par routeur debian 1)

Tu peux m'aiguiller sur ce routage asymétrique? j'ai tapé la commande mais j'ai quelques lignes.. tongue. Pour info, je configure iptables via shorewall.


PS: faut de frappe, j'ai bien une interface distincte pour le WAN wink

Hors ligne

#4 21-11-2015 21:40:37

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Je n'ai pas compris ce que tu as modifié. Tu ne montre pas le chemin aller-retour complet avec problème et sans problème.

Sur quoi veux-tu que je 'aiguille exactement ? Je pense que tu as compris ce qu'est le routage asymétrique.
Si c'est bien la cause, il faut soit modifier les règles iptables pour autoriser le routage asymétrique, soit modifier le routage pour le rendre symétrique.

Hors ligne

#5 21-11-2015 21:43:28

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Teste ceci sur chaque routeur Debian :

iptables -I FORWARD -i $LAN -o $LAN -j ACCEPT


où $LAN est le nom de l'interface LAN.

Hors ligne

#6 21-11-2015 21:56:12

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

même résultat. impossible d'accéder au serveur

Hors ligne

#7 21-11-2015 22:01:55

Kusajika
Membre
Inscription : 08-04-2015

Re : Ping OK mais c'est tout...

Bonjour , tes différents site ont-ils une ip statique ?

En ligne

#8 21-11-2015 22:12:13

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

certainement, il s'agit d'une sdsl entre les deux routeurs opérateurs dont j'ai pas la main dessus.. :s

Hors ligne

#9 21-11-2015 23:13:35

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

keitaro35 a écrit :

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 :

ifconfig ethX mtu 1460

Dernière modification par raleur (21-11-2015 23:14:27)

Hors ligne

#10 21-11-2015 23:27:15

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Non toujours rien si je n'ajoute pas l'adresse de mon routeur 2 sur mon serveur du site 2.

Cependant, je viens de faire un test de connexion ssh vers mon routeur debian 2 depuis un poste du site 1. Il me masque mon IP avec l'@IP du routeur (j'ai bloqué le trafic pour voir cela).

J'ai vu des paramètres routeback sur shorewall pour renvoyer la trame par le routeur de départ, mais cela ne fonctionne pas

Hors ligne

#11 21-11-2015 23:36:33

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

keitaro35 a écrit :

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" ?

keitaro35 a écrit :

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 23:37:00)

Hors ligne

#12 22-11-2015 10:19:22

Kusajika
Membre
Inscription : 08-04-2015

Re : Ping OK mais c'est tout...

Bonjour,
J'aimerai avoir quelques infos stp:
Tu as deux sites avec deux machines Debian qui s'occupent que du routage?

Est ce que ça serait possible d'avoir les iptables -L des deux cotés par exemple ?

Quand tu vas du Site 1 au Site 2 tu passes bien par:

PC Site 1  > LAN routeur Debian 1 > LAN routeur opérateur 1  >WAN  routeur opérateur 1 > WAN  routeur opérateur 2 > LAN routeur opérateur 2 > LAN routeur Debian 2 > PC Site 2

Qu'appel tu exactement par "routeur opérateur" car ça peut être énormément de choses , tu n'as pas la main dessus c'est bien ça ?

Pour l'instant on peut pas vraiment de quel routeur vient le problème car tu peux avoir le WAN qui ne route pas vers le LAN, surtout qu'en TSE tu utilises un port particulier.

Juste un petit rappel pour le ping , il utilise le protocole ICMP, on peut l'autoriser ou le bloquer indépendamment.

En ligne

#13 22-11-2015 11:29:03

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Bonjour messieurs,

POur résumé, dans le cas ci-dessous :
PC-S2 > RT-DEB-S2 > RT-OPE-S2 > RT-OPE-S1 > PC-S1
je suis obligé de faire sur PC-S1 :
route add 192.168.2.0 mask 255.255.255.0 192.168.1.254

Par contre, dans le cas ci-dessous :
PC-S1 > RT-DEB-S1 > RT-OPE-S1 > RT-OPE-S2 > PC-S2

Ou:
PC-Sx correspond à un poste client sur le site x (1 ou 2)
RT-DEB-Sx correspond à mon routeur debian sur le site x qui est la passerelle par défaut des postes clients
RT-OPE-Sx correspond à mon routeur operateur SDSL sur le site x (qui a la base était la passerelle par défaut et non accessible)

Le souci provient bien de RT-DEB-S1 car je repasse par lui pour renvoyer le paquet vers PC-S2 si je n'ai pas la route statique sur le PC-S1.

Le iptables-save -t nat sur mon serveur debian 1
# Generated by iptables-save v1.4.14 on Sun Nov 22 10:17:24 2015
*nat
:PREROUTING ACCEPT [158791:12076643]
:INPUT ACCEPT [8:520]
:OUTPUT ACCEPT [118:7809]
:POSTROUTING ACCEPT [11721:538672]
:dnat - [0:0]
:eth0_masq - [0:0]
:eth1_masq - [0:0]
:net_dnat - [0:0]
:tun0_masq - [0:0]
-A PREROUTING -j dnat
-A POSTROUTING -o eth0 -j eth0_masq
-A POSTROUTING -o eth1 -j eth1_masq
-A POSTROUTING -o tun0 -j tun0_masq
-A dnat -i eth0 -j net_dnat
-A eth0_masq -s 192.168.1.0/24 -j MASQUERADE
-A eth0_masq -s 192.168.100.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.101.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.2.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.254.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.1.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.100.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.101.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.254.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.2.0/24 -j MASQUERADE
... (suppression des DNAT du net vers mon réseau interne)
-A tun0_masq -s 192.168.100.0/24 -j MASQUERADE
-A tun0_masq -s 192.168.1.0/24 -j MASQUERADE
COMMIT
# Completed on Sun Nov 22 10:17:24 2015

Le iptables-save -t net sur mon serveur debian 2
# Generated by iptables-save v1.4.14 on Sun Nov 22 10:24:47 2015
*nat
:PREROUTING ACCEPT [29636:2257178]
:INPUT ACCEPT [5477:624487]
:OUTPUT ACCEPT [177:45344]
:POSTROUTING ACCEPT [977:47260]
:eth1_masq - [0:0]
:ppp0_masq - [0:0]
:tun0_masq - [0:0]
-A POSTROUTING -o ppp0 -j ppp0_masq
-A POSTROUTING -o eth1 -j eth1_masq
-A POSTROUTING -o tun0 -j tun0_masq
-A eth1_masq -s 192.168.1.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.100.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.2.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.1.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.101.0/24 -j MASQUERADE
-A eth1_masq -s 192.168.100.0/24 -j MASQUERADE
-A ppp0_masq -s 192.168.2.0/24 -j MASQUERADE
-A ppp0_masq -s 192.168.101.0/24 -j MASQUERADE
-A tun0_masq -s 192.168.101.0/24 -j MASQUERADE
-A tun0_masq -s 192.168.2.0/24 -j MASQUERADE
COMMIT
# Completed on Sun Nov 22 10:24:47 2015


Pour le iptables -L que dois-je regarder précisément?

Dernière modification par keitaro35 (22-11-2015 11:30:55)

Hors ligne

#14 22-11-2015 12:32:27

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

J'ai peut-être une idée, en relation avec le masquerading et le suivi de connexion asymétrique. J'expliquerai si elle se confirme.

Essaie ceci sur le routeur Debian 1 :

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.0/24 -j ACCEPT


modifier le réseau source si l'adresse du PC dans le site 1 est différente (192.168.100.0/24).
pour annuler :

iptables -t nat -D POSTROUTING -o eth1 -s 192.168.1.0/24 -j ACCEPT



ou bien

sysctl -w net.netfilter.nf_conntrack_tcp_loose=0


pour annuler :

sysctl -w net.netfilter.nf_conntrack_tcp_loose=1

Dernière modification par raleur (22-11-2015 12:36:26)

Hors ligne

#15 22-11-2015 12:56:55

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Bingo raleur!

La résolution se trouve dans ta commande:

sysctl -w net.netfilter.nf_conntrack_tcp_loose=0



je veux bien un cours sur le problème wink

Hors ligne

#16 22-11-2015 13:13:56

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Zut, j'ai fait une erreur dans la règle iptables, il faut -I au lieu de -A (sinon la règle va en fin de chaîne et est ignorée) et cela devrait fonctionner aussi.

nf_conntrack_tcp_loose contrôle le suivi de connexion "lâche" (loose). Par défaut il est activé avec la valeur 1.

        nf_conntrack_tcp_loose
                when a connection is picked up from the middle, how many
                packets are required to pass in each direction after the
                system may assume to be in sync and window tracking can be
                started (default 1).
                If it is set to zero, picking up already esteblished
                connections is disabled.


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 13:28:03)

Hors ligne

#17 22-11-2015 13:27:48

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Des effets secondaires? Mon serveur Debian va tomber malade? non plus sérieux, mauvais trafic sur mon LAN?

En tout cas merci pour ton aide précieuse!

Hors ligne

#18 22-11-2015 13:36:47

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Avec nf_conntrack_tcp_loose=0, le suivi de connexion, et donc le filtrage à état (les règles avec NEW, ESTABLISHED, RELATED ou INVALID) et les règles de NAT qui en dépendent, est plus strict. Des connexions qui étaient acceptées peuvent être bloquées. Des règles de NAT qui s'appliquaient peuvent ne plus s'appliquer. Je reconnais que ce n'est pas facile à comprendre sans entrer dans les détails, ce qui peut être très fastidieux. Cela n'affecte pas que le trafic inter-LAN mais aussi le trafic avec l'extérieur, tout ce qui transite par le routeur Debian.

Ce que je ferais :
- S'il n'y a pas de filtrage des communications inter-LAN et si le routage est complet, je supprimerais tout suivi de connexion et NAT de ces communications.
- S'il faut faire du filtrage des communications inter-LAN, je forcerais tout le trafic inter-VLAN à passer par les deux routeurs Debian à l'aller et au retour, rendant le routage symétrique et permettant au suivi de connexion et au NAT de fonctionner correctement.

Dernière modification par raleur (22-11-2015 13:40:14)

Hors ligne

#19 22-11-2015 13:45:25

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Oui, grossièrement, je peux foutre le "bordel" en modifiant cette règle. L'idéal est ta seconde solution, mais il faudrait pour cela que tout le trafic arrive sur mon routeur Debian. Mais je ne peux le rediriger sur les routeurs opérateurs donc je suis bloqué de ce coté la.

PS: après modification sur mn serveur Debian 1, j'ai du le faire également sur mon Debian 2 car j'ai perdu la "connexion". Je viens de tester les applis métier / RDP et tout fonctionne dans les deux sens.

Par contre, ce que je ne m'explique pas, c'est qu'avant la coupure, le trafic passait bien dans le sens site 2 > site 1 mais pas l'inverse (problème inverse de celui exposé)

Dernière modification par keitaro35 (22-11-2015 13:54:32)

Hors ligne

#20 22-11-2015 14:03:56

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

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.

Hors ligne

#21 22-11-2015 14:31:04

Kusajika
Membre
Inscription : 08-04-2015

Re : Ping OK mais c'est tout...

Personnellement je trouve que la solution avec le

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.0/24 -j ACCEPT


serait mieux adaptée , a moins que son ip publique n'est pas statique , auquel cas le MASQUERADE serait la solution.

En ligne

#22 22-11-2015 14:33:48

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Mieux adaptée que quoi ? Dans quel but ? Quel rapport avec l'adresse IP publique ?

Hors ligne

#23 22-11-2015 17:59:18

Kusajika
Membre
Inscription : 08-04-2015

Re : Ping OK mais c'est tout...

Mieux adapté qu'utiliser les MASQUERADE , ses adresses IP entre les deux sites étant statiques pourquoi ne pas utiliser le DNAT et SNAT ?  Le MASQUERADE traitant chaque paquet je pense qu'il n'est pas forcement nécessaire.

En ligne

#24 22-11-2015 19:47:58

raleur
Membre
Inscription : 03-10-2014

Re : Ping OK mais c'est tout...

Je ne suis pas sûr de comprendre où tu veux en venir. Si tu veux dire qu'il serait préférable que MASQUERADE ne s'applique pas aux communications inter-LAN et entre les deux sites, je ne dis pas autre chose depuis le début. Mais alors je ne comprends pas le rapport avec les adresses IP publiques des sites (les LAN ont des adresses privées avec lesquelles ils peuvent communiquer entre eux), leur caractère fixe ou non, et l'emploi de DNAT ou SNAT.

MASQUERADE traite chaque paquet au même titre que DNAT et SNAT. Le choix entre SNAT et MASQUERADE dépend du caractère fixe ou variable de l'adresse IP "masquante", mais ici il s'agit plutôt de choisir entre MASQUERADE et rien (ACCEPT comme dans la règle que tu as citée).

Hors ligne

#25 23-11-2015 17:52:51

keitaro35
Membre
Inscription : 21-11-2015

Re : Ping OK mais c'est tout...

Bonjour messieurs

raleur a écrit :

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

Pied de page des forums