Un système multihébergement est un système avec plusieurs interfaces IP. Ces interfaces peuvent se trouver sur le même sous-réseau ou sur des sous-réseaux différents. Aujourd'hui, je veux envisager des protocoles comme FTP et NDMP. Dans ces deux protocoles, le serveur accepte une connexion du client et établit ensuite une nouvelle connexion avec le client. Sur un système multihébergement, c'est cette nouvelle connexion qui pose tous les problèmes.
Dans les deux protocoles, l'adresse IP source n'est PAS basée sur l'adresse IP à laquelle le client s'est connecté à l'origine. Elle est plutôt basée sur l'interface associée à la passerelle qui est utilisée pour retourner au client.
A titre d'exemple, les interfaces et le tableau de routage suivants
ifconfig -all
Number of interface(s) under IP: 5
%phx_vos#loop.m16: <UP, LOOPBACK, RUNNING> 127.0.0.1 netmask 0xff000000
%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 172.16.1.50 netmask 0xffffff00 broadcast 172.16.1.255
%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 192.168.77.50 netmask 0xffffff00 broadcast 164.152.77.255
ready 15:33:51
route print
Default Gateway: 192.168.77.1ready 15:33:57Un client ayant l'adresse IP 10.1.1.1 se connecte au 172.16.1.50, appelez cette connexion "A". Pour envoyer des paquets à 10.1.1.1, le module doit utiliser la passerelle par défaut qui se trouve sur le réseau 192.168.77.0/24 et utilise donc l'interface 192.168.77.50. Il utilise cette interface pour TOUT le trafic vers 10.1.1.1 pour la connexion "A" ; mais l'adresse IP dans l'en-tête TCP sera 172.16.1.50, car c'est l'adresse IP à laquelle le client est connecté dans la connexion A . Cependant, lorsque le module crée une nouvelle connexion vers 10.1.1.1, connexion "B", le STCP choisira par défaut 192.168.77.50 comme adresse IP source. Il le fait parce que c'est aussi l'interface à laquelle la passerelle est connectée. L'application peut passer outre à cela, mais ni FTP ni NDMP ne le font.
La principale considération est la configuration des pare-feu et des listes d'accès sur les routeurs. Si le pare-feu du client ou les listes d'accès du routeur sont configurés pour n'autoriser que les connexions à partir du 172.16.1.50, la connexion à partir du 192.168.1.50 échouera. La solution consiste soit à créer une route vers 10.1.1.1 en utilisant un routeur sur le sous-réseau 172.16.1.0/24 (bien entendu, le routeur sélectionné doit être capable d'atteindre 10.1.1.1), soit à créer un pare-feu et des listes d'accès sur les routeurs mais à les reconfigurer pour autoriser 192.168.1.50.
Vous pouvez le tester avec le scénario suivant
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port NVous devez bien sûr remplacer 10.1.1.1 par l'adresse IP réelle du client et 172.16.1.50 par l'adresse IP que le client se connecte également. Le port N doit être un port ouvert sur le client et autorisé par les pare-feux et les ACL des routeurs.
La première connexion utilisera l'adresse IP par défaut, la seconde utilisera 172.16.1.50. Si la première connexion est interrompue (cela prendra environ une minute) ou revient immédiatement avec une erreur de refus de connexion MAIS que la deuxième connexion fonctionne (tout ce que vous verrez est l'invite "stcp :"), vous pouvez être certain qu'il y a un problème de pare-feu ou de routeur ACL qui devra être résolu.