Określanie adresu IP dla połączeń wychodzących na hoście z wieloma adresami IP

jeden z moich serwerów (Debian 5.0.6) ma dwa publiczne adresy IP na tym samym interfejsie. To działało dobrze od miesięcy, ale nagle używa „niewłaściwych” adresów IP dla połączeń wychodzących. Jest to problem, ponieważ wyszukiwanie wsteczne nie pasuje i dlatego wiadomości e-mail otrzymują punkty spamu.

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

Obecnie używa połączeń 85.214.157.120 dla połączeń wychodzących. Jak mogę go używać do korzystania z wersji 81.169.180.51?

Edycja : Maska sieci 255.255.255.255 jest zgodna zarówno z dokumentacją, jak i odpowiedzią DHCP firmy hostingowej. Wielokrotne wywołanie /etc/init.d/networking restart ostatecznie zakończy się poprawnym adresem IP dla połączeń wychodzących. Ale to oczywiście nie jest stabilne rozwiązanie. /Edytować

Edycja 2 : Aby upewnić się, że trasa hosta nie jest związana z moim problemem, skonfigurowałem lokalną sieć testową:

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

Jeśli ktoś ma pomysł, jak upewnić się, że źródłowy adres IP 192.168.0.2 jest używany na wychodzących połączeniach TCP, byłbym wdzięczny. / Edytuj 2

Zaktualizuj domyślne:

ip route change default via 81.169.180.1 src 81.169.180.51

Sprawdź konfigurację:

ip route list

Odpowiedź bindbn jest dobra, ale znalazłem pewne komplikacje.

1) Powinieneś zaznaczyć „listę tras ip”, jak mówi bindbn. Niektóre inne reguły na liście mogą mieć pierwszeństwo przed domyślną trasą. Może być konieczne usunięcie tej reguły lub utworzenie nieco innej reguły.

2) Wszystkie zmiany dokonane za pomocą polecenia ip działają tylko do następnego uruchomienia. Ta odpowiedź. Trwałe dodawanie reguł routingu zasad źródłowych wyjaśnia, jak je zachować.

Podsumowując, możesz dodać polecenie ip route, które musisz uruchomić jako linię „up” lub „post-up” do / etc / network / interfaces. Możesz dodać odpowiedni wiersz „w dół”, aby usunąć trasę.

Spróbuj zmienić

 allow-hotplug eth0

do

 auto eth0

To powinno zmusić twój interfejs fizyczny do działania jako pierwszy. Być może trzeba zmienić wpis „allow-hotplug” również dla eth0: 0.

Z ciekawości, dlaczego twoje adresy IP mają maskę sieci 255.255.255.255? To naprawdę nie jest możliwe, ponieważ oznaczałoby to, że cały adres to sieć. Brak miejsca dla gospodarzy. Niepokojący jest również fakt, że adres rozgłoszeniowy jest taki sam jak adres IP hosta, ale prawdopodobnie z powodu problemu z maską sieciową. Wygląda raczej na to, że twoja maska ​​sieci powinna mieć rozmiar 255.255.255.0.

Czy zrobiono to, aby zapewnić dwa hosty w tej samej podsieci? Zalecane może być po prostu dokonanie zmiany, aby każdy interfejs znajdował się w innej podsieci. 255.255.255.128 umieściłoby eth0 i bramę (z 81.169.180.1) w tej samej podsieci, z eth0: 0 w oddzielnej podsieci. Oznaczałoby to jednak, że eth0 może komunikować się tylko z 81.169.180.1-81.169.180.127. I eth0: 0 od 129-254. Ale powiedziawszy to, naprawdę nie rozumiem, dlaczego twoja obecna konfiguracja w ogóle działa.

Czy to spowoduje problemy, które widzisz powyżej? Nie widzę bezpośredniego linku, ale jest to możliwe.
Z pewnością coś poprawię. Jeśli to nie pomoże, być może możesz wyjaśnić, dlaczego masz takie ustawienia.

---

Edycja: Czy działało to dobrze na tym hoście, czy to był inny komputer / system operacyjny? Masz pojęcie, co mogło się zmienić? Pytam dlatego, że Linux naprawdę nie lubi mieć dwóch interfejsów w tej samej podsieci. Doprowadziło mnie to do szaleństwa, próbując uruchomić to w mojej własnej sieci. Wydaje się całkiem prawdopodobne, że działasz na odpowiednim adresie IP, aż do ponownego uruchomienia / ponownego uruchomienia usług sieciowych. Potem pojawił się, używając niewłaściwego interfejsu. Odniesienie: http://anders.com/cms/258

Możesz także wypróbować ifdowneth0: 0, następnie dodać trasę, a następnie ifupponownie ją wczytać. To może zagwarantować, że zostanie użyte prawidłowe IP.

Ręczne dodanie dev eth0 może pomóc, ale wygląda na to, że trasa została poprawnie wykonana.

---

Dalsze Edit: Można spróbować przy użyciu najnowszych narzędzi do zarządzania IP w Debianie iproute 2. ( Drugi link ) Wygląda to jak coś w stylu
Bringin w górę interfejsu: 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

Następnie
ip route add 10.0.0.0/16 via 192.168.0.2


ustaw tabelę routingu za pomocą --Christopher Karel

Twoja obecna konfiguracja w ogóle nie powinna działać. Ponieważ maska ​​sieci dla obu interfejsów to 255.255.255.255, nie ma miejsca na bramę. Aby jednak zapewnić znaczący ruch, serwer potrzebuje bramy. Dostawca usług internetowych udostępniający dwa publiczne adresy IP powinien również zapewnić maskę sieci i ustawienia bramy dla obu adresów IP.

Przykład (to jest mój prywatny serwer, a adresy IP są prawdziwe):

Tabela routingu IP jądra
Brama docelowa Genmask Flagi Metryka Ref Użyj 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

Sam serwer jest na 217.10.144.210, który znajduje się w tej samej podsieci co brama (musi to zrobić, w przeciwnym razie ruch nie będzie mógł być kierowany). Przypuszczalnie ISP zapewnia tę samą podsieć również niektórym innym klientom.

Jeśli jesteś na tym serwerze i wykonujesz polecenie ping do bramy, powinieneś otrzymać komunikat „brak trasy do hosta”.

Porozmawiaj z dostawcą usług internetowych i uzyskaj prawidłowe ustawienia, a następnie zaktualizuj konfigurację interfejsu, uruchom ponownie sieć i sprawdź ponownie.