Angeben der IP-Adresse für ausgehende Verbindungen auf einem Multi-IP-Host

Einer meiner Server (Debian 5.0.6) hat zwei öffentliche IP-Adressen auf derselben Oberfläche. Früher hat dies monatelang gut funktioniert, aber plötzlich werden "die falschen" IP-Adressen für ausgehende Verbindungen verwendet. Dies ist ein Problem, da die umgekehrte Suche nicht passt und E-Mails daher Spam-Punkte erhalten.

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

Derzeit wird 85.214.157.120 für ausgehende Verbindungen verwendet. Wie kann ich 81.169.180.51 verwenden?

Bearbeiten : Die Netzmaske von 255.255.255.255 stimmt sowohl mit der Dokumentation als auch mit der DHCP-Antwort des Hosting-Unternehmens überein. Wenn Sie mehrmals /etc/init.d/networking restart aufrufen, erhalten Sie schließlich die richtige IP-Adresse für Outbount-Verbindungen. Das ist aber offensichtlich keine stabile Lösung. /Bearbeiten

Bearbeiten 2 : Um sicherzustellen, dass die Hostroute nicht mit meinem Problem zusammenhängt, richte ich ein lokales Testnetzwerk ein:

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Wenn jemand eine Idee hat, wie er sicherstellen kann, dass die Quell-IP-Adresse 192.168.0.2 für ausgehende TCP-Verbindungen verwendet wird, wäre ich dankbar. / Bearbeiten 2

Standard aktualisieren:

ip route change default via 81.169.180.1 src 81.169.180.51

Überprüfen Sie die Konfiguration:

ip route list

Die Antwort von bindbn ist gut, aber ich habe einige Komplikationen gefunden.

1) Sie sollten "IP-Routenliste" überprüfen, wie Bindbn sagt. Einige andere Regeln in der Liste haben möglicherweise Vorrang vor der Standardroute. Möglicherweise müssen Sie diese Regel löschen oder eine etwas andere Regel erstellen.

2) Alle über den Befehl ip vorgenommenen Änderungen funktionieren nur bis zum nächsten Neustart. In dieser Antwort wird das dauerhafte Hinzufügen von Quellrichtlinien-Routingregeln erläutert, um die Persistenz zu gewährleisten.

Zusammenfassend können Sie den Befehl ip route, den Sie als "up" - oder "post-up" -Zeile ausführen müssen, zu / etc / network / interfaces hinzufügen. Sie können eine entsprechende "Down" -Zeile hinzufügen, um die Route zu entfernen.

Versuchen Sie es zu ändern

 allow-hotplug eth0

zu

 auto eth0

Das sollte dazu führen, dass Ihre physische Schnittstelle zuerst angezeigt wird. Möglicherweise müssen Sie den Eintrag allow-hotplug auch für eth0: 0 ändern.

Warum haben Ihre IP-Adressen aus Neugier eine Netzmaske von 255.255.255.255? Das ist wirklich nicht machbar, da es bedeuten würde, dass die gesamte Adresse das Netzwerk ist. Kein Platz für Gastgeber. Die Tatsache, dass Ihre Broadcast-Adresse mit Ihrer Host-IP übereinstimmt, ist ebenfalls besorgniserregend, aber wahrscheinlich auf Grund des Netzmaskenproblems. Es sieht eher so aus, als ob Ihre Netzmaske 255.255.255.0 sein sollte.

Wurde dies getan, um Ihnen zwei Hosts im selben Subnetz zur Verfügung zu stellen? Es ist möglicherweise vorzuziehen, einfach eine Änderung vorzunehmen, damit sich jede Schnittstelle in einem anderen Subnetz befindet. 255.255.255.128 würde eth0 und Ihr Gateway (von 81.169.180.1) in dasselbe Subnetz stellen, mit eth0: 0 in einem separaten Subnetz. Dies würde jedoch bedeuten, dass eth0 nur mit 81.169.180.1-81.169.180.127 kommunizieren könnte. Und eth0: 0 von 129-254. Trotzdem kann ich nicht wirklich verstehen, warum Ihr aktuelles Setup überhaupt funktioniert.

Verursacht dies die oben genannten Probleme? Ich kann keinen direkten Link sehen, aber es ist möglich.
Es ist sicherlich etwas, das ich optimieren würde. Wenn das nicht hilft, können Sie vielleicht erklären, warum Sie die Dinge so eingerichtet haben.

---

Bearbeiten: Funktionierte dies auf diesem Host einwandfrei oder war es ein anderes Computer / Betriebssystem? Irgendeine Idee, was sich geändert haben könnte? Der Grund, den ich frage, ist, dass Linux wirklich nicht zwei Schnittstellen im selben Subnetz haben möchte. Es hat mich verrückt gemacht, dies in meinem eigenen Netzwerk zum Laufen zu bringen. Es ist durchaus möglich, dass Sie diese Funktion auf der richtigen IP aktiviert haben, bis Sie die Netzwerkdienste neu gestartet / neu gestartet haben. Dann kam es mit der falschen Schnittstelle. Referenz: http://anders.com/cms/258

Sie können auch ifdowneth0: 0 anprobieren, dann die Route hinzufügen und dann ifupzurückgeben. Das könnte garantieren, dass die richtige IP verwendet wird.

Das manuelle Hinzufügen von dev eth0 könnte helfen, aber es scheint, als ob die Route ordnungsgemäß ausgeführt wurde.

---

Further Edit: Sie könnten versuchen, die neuesten IP-Verwaltungstools in Debian zu verwenden iproute 2. ( Secondary Link ) Es sieht
ungefähr so ​​aus, als würde das Interface aufgerufen: ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

ip route add 10.0.0.0/16 via 192.168.0.2


Richten Sie dann mit --Christopher Karel die Routing-Tabelle ein

Ihr aktuelles Setup sollte eigentlich gar nicht funktionieren. Da die Netzmaske für beide Schnittstellen 255.255.255.255 ist, ist kein Platz für ein Gateway. Um jedoch einen sinnvollen Datenverkehr zu gewährleisten, benötigt Ihr Server ein Gateway. Der ISP, der die beiden öffentlichen IP-Adressen bereitstellt, sollte Ihnen auch die Netzmasken- und Gateway-Einstellungen für beide IP-Adressen bereitstellen.

Beispiel (dies ist mein privater Server und die IP-Adressen sind echt):

Kernel-IP-Routing-Tabelle
Destination Gateway Genmask Flags Metric Ref Use Iface
217.10.144.208 0.0.0.0 255.255.255.248 U 0 0 0 eth0
0.0.0.0 217.10.144.209 0.0.0.0 UG 0 0 0 eth0

Der Server selbst befindet sich in der 217.10.144.210, die sich im selben Subnetz befindet wie das Gateway (muss, sonst kann kein Verkehr geroutet werden). Vermutlich stellt der ISP das gleiche Subnetz auch für einige andere Kunden bereit.

Wenn Sie sich auf diesem Server befinden und einen Ping an Ihr Gateway senden, sollten Sie die Meldung "Keine Route zum Host" erhalten.

Sprechen Sie mit dem Internetdienstanbieter und ermitteln Sie die korrekten Einstellungen. Aktualisieren Sie dann Ihre Schnittstellenkonfiguration, starten Sie das Netzwerk neu und überprüfen Sie es erneut.