Itinérance réseau entre site local et distant



  • Contexte : milieu pro / Stagiaire 1ère année Administration réseau
    Besoin : Permettre aux véhicules situés sur n'importe quel site (local ou distant) de communiquer avec le SRV1.
    Sachant que les véhicules ne connaissent que l'IP 10.1.100.1. et qu'il s'agit d'un réseau non routé.
    Schéma :
    Projet Wifi SCH.png

    Contexte du projet :
    Le contexte est le suivant parc véhicule couvert par un réseau Wifi sur lequel les véhicules se connectent pour décharger leur journée.
    Comme l'interface 10.1.100.1 se trouve dans le même VLAN que les AP wifi, on ne rencontre pas de problème pour décharger les véhicules locaux.
    Mon employeur à reproduit cette solution sur un site distant et effectue un job de synchro dans la nuit entre le serveur local et le distant.
    Mais il veut supprimer le serveur distant, d'où se projet tordu.

    Question :
    Comme présenté dans le besoin ci-dessus, mon maître de stage me demande de réaliser l'impossible. (chose courante en stage :o) )
    Je n'arrive pas à trouver de réponse sans créer une passerelle au niveau du réseau local situé juste derrière le SRV1 chose que l'on m'interdit.

    Auriez-vous une solution réseau envisageable ?
    A défaut je prends des arguments pour orienter le projet sur une autre voie.

    Merci pour votre aide.



  • (Bon point : un stagiaire est capable de bien décrire un problème !)

    Une entreprise, avec une bonne 'maturité', évite d'avoir le même réseau sur plusieurs de ses sites, car cela empêche d'atteindre l'un depuis l'autre.

    De même, une bonne 'maturité' préconise de toujours utiliser des noms dns pour des serveurs au lieu d'adresse ip. Avec des noms dns, on peut aisément faire 2 possibilités : 1 serveur unique accessible de partout, 1 serveur différents sur chaque site (et répondant au même nom dns). Exemple typique du 2ième cas : le proxy avec un nom uPnique mais 1 proxy par site.

    Pour être sûr, le problème est-il que, sur 1 des 2 sites, un serveur d'adresse ip connue soit réel d'un coté et 'virtuel' de l'autre ? Par 'virtuel', il faut comprendre qu'il n'y aura pas de serveur physique avec cette adresse ip qui répondra, mais un mécanisme doit quand même localement répondre à cette adresse et transférer l'intégralité du flux à un serveur situé ailleurs ?

    Ai je bien compris ?



  • Merci pour l'intérêt porté à mon sujet. (les stagiaires n'ont pas tous moins de 30 ans ☺ )

    Il est difficile de ne pas avoir le même réseau sur les 2 sites puisque les véhicules qui eux ont leur propre IP (établi sur leur numéros de véhicule) peuvent naviguer d'un site à l'autre. Pour être plus clair un véhicule qui démarre sa journée sur le site 1, peut la terminer sur le site 2.

    Nous n'utilisons pas non plus de non DNS car rien n'a été développé dans ce sens sur le système embarqué des véhicules. L'objectif est bien d'avoir un serveur unique accessible depuis tous les sites donc exactement le cas du serveur "virtuel" d'un point de vue IP.



  • La config choisie est très 'à l'ancienne' ! vos machines (voiture ?) ont une adresse ip fixe, et c'est une galère ...

    Une config moderne : les pc fixes ou nomades sont en dhcp, quand les nomades sont sur un site, ils récupèrent une adresse ip locale ET le dns se met à jour, donc le nom dns de la machine pointe sur l'ip réelle active.

    Forcément un jour, il faudra migrer à cette 'config moderne', parce qu'on ne peut pas identifier un matériel à son adresse ip, il faut identifier un matériel à son nom de machine, nom qui doit être unique si on veut gérer un parc correctement.

    Cependant, tout n'est pas perdu.
    Il est possible sur un site d'avoir un serveur qui réponde à une adresse mais qui transfère tout vers un autre serveur. Sans serveur cela s'appelle du NAT port forward. Mais ce serait mieux avec un serveur.

    Il faudrait comprendre comment fonctionne ce serveur : quels services, il propose ?



  • Le serveur offre comme service : un serveur FTP, un serveur de temps, et un service applicatif dédié sur port TCP défini.
    La borne wifi sur le site distant est une WLn-xROAD de chez Acksys.



  • Je penche pour un vrai serveur (plutôt qu'un NAT port forward), et pour l'utilisation de 'netcat' (utilitaire très puissant).



  • Pour l'heure je vais tenter de mettre en service le NAT directement sur l'AP wifi, puisqu'il sait le gérer.

    Si j'ai bien compris le principe du NAT je vais dire à ma borne Wifi distante de répondre en tant que 10.1.100.1 (en lui fixant cette IP).

    Dans cette borne je vais lui indiquer de transférer l'ensemble du flux entrant sur 172.19.0.203.

    C'est bien ça ?



  • C'est la possibilité logique et de base, que l'on peut essayer en première solution. Néanmoins, il est clair que l'accès à ce serveur (natté) sera notablement plus lent puisque distant !

    Ne pas oublier qu'il faudra accéder au seul serveur restant, sans doute par double nat : premier nat depuis site où le serveur n'est plus et réalisé par le boitier wifi, deuxième nat depuis le firewall du site où le serveur est resté.

    Il n'est pas certain que cela fonctionne, en particulier pour FTP. Parce que FTP est un vieux protocole et qu'à chaque traversée de NAT, il y a une modification à faire dans les paquets, cf mode FTP + traversée de firewall.

    Il y a tout lieu de penser qu'une réorganisation de la solution serait préférable (avec le concepteur).

    NB : dans le schéma, on voit que la position des bornes Wifi est loin d'être idéale : elles devraient être connectées sur un port supplémentaires du firewall dans une zone dédiée Wifi, ...



  • @jdh said in Itinérance réseau entre site local et distant:

    [...] elles devraient être connectées sur un port supplémentaires du firewall dans une zone dédiée Wifi, ...

    Je suis bien d'accord avec ce point. Mais je suppose qu'a l'époque où cette topologie a été conçue ils n'ont pas souhaité investir dans un pare-feu et donc sécurisé cette exposition "publique" en la limitant au serveur FTP.

    Chose que aujourd'hui ils souhaites reconsidérer.


Log in to reply