Un sistema multihomed è un sistema con più interfacce IP. Queste interfacce possono essere sulla stessa o su diverse sottoreti. Oggi voglio considerare protocolli come FTP e NDMP. In entrambi i protocolli il server accetta una connessione dal client e poi effettua una nuova connessione al client. Su un sistema multihomed è questa nuova connessione che causa tutti i problemi.
In entrambi i protocolli l'indirizzo IP di origine NON si basa sull'indirizzo IP a cui il client si è collegato originariamente. Si basa invece sull'interfaccia associata al gateway che viene utilizzata per tornare al client.
Ad esempio, date le seguenti interfacce e tabella di routing
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.1
ready 15:33:57
Un client con l'indirizzo IP 10.1.1.1.1 si collega al 172.16.1.50, chiamare questa connessione "A". Per inviare pacchetti alla 10.1.1.1.1 il modulo deve utilizzare il gateway predefinito che si trova sulla rete 192.168.77.0/24 e quindi utilizza l'interfaccia 192.168.77.50. Utilizza questa interfaccia per TUTTO il traffico verso la 10.1.1.1.1 per la connessione "A"; ma l'indirizzo IP nell'intestazione TCP sarà 172.16.1.50, perché quello è l'indirizzo IP a cui il client è connesso nella connessione A . Tuttavia, quando il modulo crea una nuova connessione a 10.1.1.1.1, connessione "B", STCP sceglierà di default 192.168.77.50 come indirizzo IP di origine. Lo fa perché quella è l'interfaccia a cui è collegato anche il gateway. L'applicazione può sovrascrivere questo, ma né FTP né NDMP lo fanno.
La considerazione principale è la configurazione dei firewall e delle liste di accesso sui router. Se il firewall del client o le ACL del router sono configurate in modo da consentire solo connessioni a partire da 172.16.1.50, la connessione a partire da 192.168.1.50 fallirà. La soluzione è di creare un percorso verso la 10.1.1.1.1 utilizzando un router sulla sottorete 172.16.1.0/24 (naturalmente il router selezionato deve essere in grado di raggiungere la 10.1.1.1) o le liste di accesso del firewall e del router ma essere riconfigurato per consentire la 192.168.1.50.
Potete testarlo con il seguente script
stcp_calls
socket
connect -name 10.1.1.1 -port N
socket
bind -name 172.16.1.50 -port 0
connect -name 10.1.1.1 -port N
Naturalmente dovete sostituire il 10.1.1.1.1 con l'indirizzo IP effettivo del cliente e il 172.16.1.50 anche con l'indirizzo IP che il cliente collega. La porta N dovrebbe essere una porta aperta sul client e consentita dai firewall e dalle ACL del router.
La prima connessione utilizzerà l'indirizzo IP predefinito, la seconda utilizzerà 172.16.1.50. Se la prima connessione si interrompe (ci vorrà un minuto circa) o ritorna immediatamente con un errore di connessione rifiutata MA la seconda connessione funziona (tutto quello che vedrete è il prompt "stcp:") potete essere certi che c'è un problema di firewall o di ACL del router che dovrà essere risolto.

© 2020 Stratus Tecnologie.