Ein Multihomed-System ist ein System mit mehreren IP-Schnittstellen. Diese Schnittstellen können sich in demselben oder in verschiedenen Subnetzen befinden. Heute möchte ich mich mit Protokollen wie FTP und NDMP beschäftigen. Bei beiden Protokollen nimmt der Server eine Verbindung vom Client an und stellt dann eine neue Verbindung zurück zum Client her. In einem Multihomed-System ist es diese neue Verbindung, die alle Probleme verursacht.
Bei beiden Protokollen basiert die Quell-IP-Adresse NICHT auf der IP-Adresse, mit der der Client ursprünglich verbunden war. Stattdessen basiert sie auf der Schnittstelle, die mit dem Gateway verbunden ist, das verwendet wird, um zurück zum Client zu gelangen.
Beispiel für die folgenden Schnittstellen und die 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.1ready 15:33:57Ein Client mit der IP-Adresse 10.1.1.1 verbindet sich mit 172.16.1.50, nennen wir diese Verbindung "A". Um Pakete an 10.1.1.1 zu senden, muss das Modul das Standard-Gateway verwenden, das sich im Netz 192.168.77.0/24 befindet, und verwendet daher die Schnittstelle 192.168.77.50. Es verwendet diese Schnittstelle für den gesamten Verkehr an 10.1.1.1 für Verbindung "A"; die IP-Adresse im TCP-Header lautet jedoch 172.16.1.50, da dies 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, Verbindung "B", herstellt, wählt STCP standardmäßig 192.168.77.50 als Quell-IP-Adresse. Dies geschieht, weil dies die Schnittstelle ist, an die das Gateway angeschlossen ist. Die Anwendung kann dies außer Kraft setzen, aber weder FTP noch NDMP tun dies.
Der wichtigste Punkt ist die Konfiguration von Firewalls und Zugriffslisten auf Routern. Wenn die Client-Firewall oder die ACLs des Routers so konfiguriert sind, dass sie nur Verbindungen von 172.16.1.50 zulassen, wird die Verbindung von 192.168.1.50 fehlschlagen. Die Lösung besteht darin, entweder eine Route zu 10.1.1.1 über einen Router im Subnetz 172.16.1.0/24 zu erstellen (natürlich muss der gewählte Router in der Lage sein, 10.1.1.1 zu erreichen) oder die Firewall und die Router-Zugriffslisten so umzukonfigurieren, dass 192.168.1.50 zugelassen wird.
Sie können dies mit folgendem Skript testen
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port NSie müssen natürlich 10.1.1.1 durch die tatsächliche IP-Adresse des Clients und 172.16.1.50 durch die IP-Adresse ersetzen, mit der sich der Client verbindet. Der Port N sollte ein Port sein, der auf dem Client offen ist und von den Firewalls und ACLs des Routers zugelassen wird.
Bei der ersten Verbindung wird die Standard-IP-Adresse verwendet, bei der zweiten Verbindung 172.16.1.50. Wenn die erste Verbindung abbricht (das dauert etwa eine Minute) oder sofort mit einer Fehlermeldung "Verbindung verweigert" zurückkehrt, die zweite Verbindung aber funktioniert (Sie sehen nur die Eingabeaufforderung "stcp:"), können Sie sicher sein, dass ein Problem mit der Firewall oder den Router-ACLs vorliegt, das gelöst werden muss.