Ubuntu-fr

Bap2703

Configuration réseau, masque, passerelle, mais où est le problème ?

Bonjour,

J'ai installé ubuntu serveur sur un de mes pc, pour faire un serveur donc.

Il doit être accessible depuis deux réseau.
1) le réseau local : 10.201.0.0 à 10.201.127.255, donc masque=255.255.128.0, avec une passerelle, 10.201.0.254
2) un réseau vpn qui est accessible via la même passerelle. (plage d'ip en 10.31.*)

J'ai bien configuré la partie 1 et tout fonctionne sur ce réseau.

Maintenant j'essaye de faire fonctionner la partie 2.
Sans rien modifier j'essaye : les clients sur le réseau 2 envoient leurs paquets, le serveur les reçoit, il répond... mais côté client rien n'arrive
Du coup impossible de faire quoi que ce soit (testé sur un serveur ssh et irc)

Mais, et c'est la que c'est fort, il a des moments où ca marche ! Je ne sais pas pourquoi, environ une fois sur 20 la connection s'établit : coup de bol les paquets du serveur arrivent au client. Mais ca ne dure pas et en général je peux juste entrer mon login en ssh que la connection est déjà morte.

J'ai tout ouvert avec iptables, ca ne change rien.

J'ai essayé la même chose sur un serveur windows configuré de la même manière... et ca MARCHE !!
Ca veux bien dire que le problème est du côté de ma configuration réseau. Alors routes, masques, passerelle, j'ai essayé plein de réglages différents sans succès.

Je viens donc demander de l'aide ici vu que je ne m'y connais pas vraiment en réseau et en linux. Y aurait-il quelqu'un qui aurait une idée ?

Merci
Bap2703, qui espère qu'il ne va quand meme pas devoir mettre son serveur sous windows !

dexinou

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Salut,
tu peux poser ta question ici : http://forum.debian-fr.org
Ils sont assez fort question réseau et tout ce qui concerne linux.

Dernière modification par dexinou (Le 31/01/2007, à 09:12)

---

Ubuntu 9.10 64bits ext4 ® Core 2 Duo
Unix..... il y a moins bien mais c'est plus cher.
Si t'as pas compris la réponse, pose mieux ta question.
Tutoriaux Linux, apache, pure-ftpd, bind, mysql, qmail...

Uggy

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

2) un réseau vpn qui est accessible via la même passerelle. (plage d'ip en 10.31.*)

Donne des détails sur la partie VPN... Quel type de VPN avec quelle conf... quels logs etc...

Uggy

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Sans rien modifier j'essaye : les clients sur le réseau 2 envoient leurs paquets, le serveur les reçoit, il répond... mais côté client rien n'arrive

Tu as sniffé les paquets pour arriver à cette conclusion ?

Bap2703

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Oui j'ai sniffé les paquets. Mais ca ne me renseigne pas sur l'endroit où sont passés les paquets qui n'arrivent pas au client.

Je ne peux pas donner de détails sur la partie vpn puisque ce n'est pas moi qui m'en occupe mais mon école

La seule chose que je sais c'est qu'il est possible de faire communiquer une machine sur vpn et une qui n'est pas sur le vpn.

Si je fais un traceroute sous windows (où ca marche) j'ai ca :
10.31.x.y (vpn) veut communiquer avec 10.201.z.w
Les paquets passent par la passerelle 10.201.0.254 entre les deux et c'est tout ! Même chose pour une communication dans l'autre sens.

Sur le serveur j'aurais pensé qu'ajouter une route suffirait :
route add -net 10.31.0.0 netmask 255.255.0.0 gw 10.201.0.254 metric 1 dev eth0

mais non
Je vais voir en parallèle sur le forum debian proposé par dexinou

Uggy

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

les clients sur le réseau 2 envoient leurs paquets, le serveur les reçoit, il répond... mais côté client rien n'arrive

Je résume:
- Ton client en 10.31.* envoit des Syn vers ton serveur
- Ton serveur recoit les paquets venant de 10.31.* (a travers la machine 10.201.0.254)
Tu vois les SYN arriver en sniffant..
- Ton serveur repond par des Syn/Ack
Tu vois les Syn/Ack partir vers 10.31.* (a travers la machine 10.201.0.254)
- Ton client ne recoit jamais ces Syn/Ack
(Tu ne les vois pas arriver en sniffant)

Si j'ai tout bon, je dirais que c'est une machine sur le chemin: 10.201.0.254 ou autre ou meme ta 10.31.* qui donc bloque les paquets... a voir sur toutes ces machines si il n'y a pas un Firewall qui drop les paquets...

Bap2703

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

C'est ca.

Est-il normal que sur les paquets qui partent du serveur je vois la destination finale (le client), et non la passerelle ?

tcpdump me donne un truc du genre :
Heure IP hostname_du_serveur.ssh > hostame_du_client.1278 : S un_grand_nombre:un_grand_nombre(0) ack un_grand_nombre win 5840 <mss 1460,nop,nop,sackOK>

Apparement je vois rien qui concerne la passerelle "en clair" je sais pas si c'est normal ou si codé dans les "un_grand_nombre".

L'idée de la machine entre les deux qui intercepte serait bonne si ca ne marchait pas nickel sous windows
Je vais sniffer sur le serveur windows pour voir si y a des différences.

Uggy

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Est-il normal que sur les paquets qui partent du serveur je vois la destination finale (le client), et non la passerelle ?

Oui.
Mais au niveau ARP, tu vois voir l'adresse MAC de la passerelle.

tcpdump me donne un truc du genre :
Heure IP hostname_du_serveur.ssh > hostame_du_client.1278 : S un_grand_nombre:un_grand_nombre(0) ack un_grand_nombre win 5840 <mss 1460,nop,nop,sackOK>

Ca m'etonnerais que "un_grand_nombre" soit si confidentiel que cela...
Et si "IP" est de type rfc1918, alors pareil ... mais bon

Apparement je vois rien qui concerne la passerelle "en clair" je sais pas si c'est normal ou si codé dans les "un_grand_nombre".

Non ce n'est pas codé dans "un_grand_nombre", c'est au niveau ARP que tu dois voir l'adresse MAC de la passerelle.

L'idée de la machine entre les deux qui intercepte serait bonne si ca ne marchait pas nickel sous windows

L'idée que ca marche nickel sous windows serait bonne si tu me confirmes que tu as accédé strictement aux mêmes ports

Bap2703

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Alors des nouvelles :

Oui le client essaye de se connecter au même port que le serveur soit sous linux ou sous windows.

Je vois bien les adresses mac des passerelles dans les paquets émis par le serveur windows.
Pas contre elles n'y sont pas pour ceux émis par le serveur linux !

Voici ce que j'observe côté serveur linux :

No.     Time        Source                Destination           Protocol Info
      1 0.000000    10.31.41.168          10.201.39.105         TCP      3942 > 22 [SYN] Seq=0 Len=0 MSS=1260

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, [b]Src: Cisco_be:30:00 (00:11:5d:be:30:00)[/b], [b]Dst: 3com_e1:cc:5f (00:50:04:e1:cc:5f)[/b]
Internet Protocol, Src: 10.31.41.168 (10.31.41.168), Dst: 10.201.39.105 (10.201.39.105)
Transmission Control Protocol, Src Port: 3942 (3942), Dst Port: 22 (22), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      2 0.000045    10.201.39.105         10.31.41.168          TCP      22 > 3942 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, [b]Src: 3com_e1:cc:5f (00:50:04:e1:cc:5f)[/b], Dst: [b]Intel_7b:ad:8e (00:03:47:7b:ad:8e)[/b]
Internet Protocol, Src: 10.201.39.105 (10.201.39.105), Dst: 10.31.41.168 (10.31.41.168)
Transmission Control Protocol, Src Port: 22 (22), Dst Port: 3942 (3942), Seq: 0, Ack: 1, Len: 0

Dans le 1er paquet, la source "Cisco" est la passerelle (10.201.0.254), la carte 3com est celle du serveur.
Dans le 2eme paquet le serveur envoie vers une carte Intel : c'est la carte du pc portable qui sert de client.

Le client vpn cisco crée une interface avec sa propre adresse mac, je ne sais pas si c'est normal que le serveur s'adresse à l'interface physique du client au lieu de son interface vpn.

Mais bon déjà apparement le serveur n'utilise pas la passerelle pour renvoyer ses paquets.

Peut-être que ca à un rapport avec le fait que la connexion marche de temps en temps : quand je n'ai pas essayé depuis longtemps, ou que le client s'est déconnecté puis reconnecté au vpn (ip attribuée aléatoirement) et donc à changé d'ip.
Serait-il possible qu'il y ait sur le serveyr une sorte de cache qui retienne la route la plus rapide ? Il n'y aurait pas ce mécanisme sous windows ce qui expliquerait que ca marche ?

Si je n'ai pas fait d'essai depuis longtemps ou que le client à changé d'ip => son adresse n'est pas en cache, il prend la route "par defaut" qui passe par la passerelle.
Si l'adresse du client est en cache => le serveur essaye de contacter directement le client sans passer par la passerelle = ca ne marche pas.

Bon je connais pas grand chose en réseau alors c'est ptetre une hypothèse farfelue

Je viens de vérifier, les paquets émis par le serveur windows passent bien systématiquement par la machine cisco qui est la passerelle.

Uggy

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Je ne pige pas comment ton serveur peut récupérer l'adresse MAc du client si les 2 ne sont pas dans le même réseau....

En tout cas le problème est bien à cause de çà... les paquets retour ne partent pas vers la passerelle...pourquoi.. je ne sais pas..j'imagine que des détails sur le VPN utilisé seraient utiles...

Bap2703

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Et bien les machines sont physiquement sur le même réseau.
Par contre le client se connecte au réseau virtuel qui lui permet d'accéder à un proxy pour accéder à internet.

Le client vpn (cisco) crée une interface réseau pour le vpn et désactive la connexion physique. Enfin c'est un truc bizarre mais on peut plus rien faire sur l'interface physique bien qu'elle supporte la connexion virtuelle. (vive les logiciels propriétaires... )

Du coup je pense que le serveur arrive à voir la connexion physique, je ne sais pas comment. Du coup il doit se dire "c'est plus simple d'envoyer directement par là". Sauf que comme du côté client on ne peut pas utiliser la connexion physique, on ne peut pas lire les paquets que le serveur à envoyé.

Le tout est de trouver pourquoi le serveur prend une telle initiative au lieu de répondre connement en passant par la passerelle. (comme le fait le serveur windows).

Au niveau des routes j'ai celles par défaut.

Serveur windows

Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0     10.201.0.254   10.201.39.103       20
       10.201.0.0    255.255.128.0    10.201.39.103   10.201.39.103       20
    10.201.39.103  255.255.255.255        127.0.0.1       127.0.0.1       20
   10.255.255.255  255.255.255.255    10.201.39.103   10.201.39.103       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        224.0.0.0        240.0.0.0    10.201.39.103   10.201.39.103       20
  255.255.255.255  255.255.255.255    10.201.39.103   10.201.39.103       1
Passerelle par défaut :      10.201.0.254
===========================================================================
Itinéraires persistants :
  Aucun

Serveur linux

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.201.0.0      0.0.0.0         255.255.128.0   U     0      0        0 eth0
0.0.0.0         10.201.0.254    0.0.0.0         UG    0      0        0 eth0

J'ai essayé de recopier celles du serveur windows sur le serveur linux sans succès.

Bap2703

Re : Configuration réseau, masque, passerelle, mais où est le problème ?

Je crois que j'ai trouvé la solution !

En fait c'est ta remarque sur "comment fait le serveur pour connaitre l'adresse du client" qui m'a interpelé.

Car j'avais remarqué qu'après chaque connexion réussie, le serveur recevait un paquet ICMP en provenance de la passerelle et qu'après ce ne marchait plus.

Wireshark appelle ce paquet "Redirect (redirect for host)", je me suis dit qu'il faisait un bon candidat en tant que raporteur de la passerelle pour lui éviter le boulot.

Du coup j'ai tout simplement... bloqué le traffic icmp entrant sur le serveur

Et ca a l'air de marcher, j'ai réussi à me logguer en ssh une dizaine de fois d'affilée.
Je vais tester ca un peu plus pour confirmer que ca marche bien.

Après je chercherais à bloquer uniquement ce type de paquet et pas tout les paquets icmp.
Et dire que demain j'ai mon premier cours de "introduction aux réseaux"