Ein Multihomed-System ist ein System mit mehreren IP-Schnittstellen. Diese Schnittstellen können sich auf demselben oder auf verschiedenen Subnetzen befinden. Heute möchte ich Protokolle wie FTP und NDMP in Betracht ziehen. Bei beiden Protokollen nimmt der Server eine Verbindung vom Client an und stellt dann eine neue Verbindung zurück zum Client her. Auf einem Multihomed-System ist es diese neue Verbindung, die alle Probleme verursacht.
In beiden Protokollen basiert die Quell-IP-Adresse NICHT auf der IP-Adresse, mit der sich der Client ursprünglich verbunden hat. Stattdessen basiert sie auf der Schnittstelle, die mit dem Gateway verbunden ist, das verwendet wird, um zurück zum Client zu gelangen.
Zum Beispiel mit den folgenden Schnittstellen und der folgenden Routing-Tabelle
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
Ein Client mit der IP-Adresse 10.1.1.1.1 verbindet sich mit 172.16.1.50, nennen Sie diese Verbindung "A". Um Pakete an 10.1.1.1.1 zu senden, muss das Modul den Standard-Gateway verwenden, der sich im 192.168.77.0/24-Netz befindet und daher die 192.168.77.50-Schnittstelle verwendet. Es benutzt diese Schnittstelle für ALLEN Verkehr nach 10.1.1.1 für die Verbindung "A"; aber die IP-Adresse im TCP-Header wird 172.16.1.50 sein, weil das die IP-Adresse ist, mit der der Client in Verbindung A verbunden ist. Wenn das Modul jedoch eine neue Verbindung zu 10.1.1.1.1, Verbindung "B", erstellt, wählt STCP standardmäßig 192.168.77.50 als Quell-IP-Adresse. Dies geschieht, weil dies die Schnittstelle ist, an die auch das Gateway angeschlossen ist. Die Anwendung kann dies überschreiben, aber weder FTP noch NDMP tun dies.
Die wichtigste Überlegung ist die Konfiguration von Firewalls und Zugriffslisten auf Routern. Wenn die Client-Firewall oder die Router-ACLs so konfiguriert sind, dass sie nur Verbindungen ab 172.16.1.50 zulassen, wird die Verbindung ab 192.168.1.50 fehlschlagen. Die Lösung besteht entweder darin, eine Route zu 10.1.1.1.1 unter Verwendung eines Routers im Subnetz 172.16.1.0/24 zu erstellen (natürlich muss der ausgewählte Router in der Lage sein, 10.1.1.1 zu erreichen) oder die Firewall- und Router-Zugriffslisten neu zu konfigurieren, aber 192.168.1.50 zuzulassen.
Sie können dies mit dem folgenden Skript testen
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
Sie müssen natürlich 10.1.1.1.1 durch die tatsächliche IP-Adresse des Clients und 172.16.1.50 durch die IP-Adresse ersetzen, die auch der Client verbindet. Der Port N sollte ein Port sein, der auf dem Client offen ist und von den Firewalls und Router-ACLs zugelassen wird.
Bei der ersten Verbindung wird die Standard-IP-Adresse verwendet, bei der zweiten Verbindung wird 172.16.1.50 verwendet. Wenn die erste Verbindung ein Timeout hat (das dauert etwa eine Minute) oder sofort mit einem Fehler "Verbindung abgelehnt" zurückkehrt, ABER die zweite Verbindung funktioniert (alles, was Sie sehen, ist die "stcp:"-Eingabeaufforderung), können Sie sicher sein, dass es ein Firewall- oder Router-ACL-Problem gibt, das gelöst werden muss.

© 2020 Stratus Technologies.