Dlaczego ruch sieciowy w systemie Linux przechodzi tylko przez eth0?


20

Mam dwie karty sieciowe po stronie serwera, eth0? 192.168.8.140 i eth1? 192.168.8.142. Klient wysyła dane do 192.168.8.142 i oczekuję, iftopże pokażę ruch dla eth1, ale nie robi tego. Wszystkie sieci przechodzą przez eth0, więc jak mogę przetestować dwie karty sieciowe?

Dlaczego cały ruch przechodzi przez eth0 zamiast eth1? Spodziewałem się, że mogę uzyskać 1 Gbit / s na interfejs. Co jest nie tak z moją konfiguracją lub konfiguracją?

serwer

ifconfig

eth0    Link encap:Ethernet  HWaddr 00:00:00:19:26:B0
        inet addr:192.168.8.140  Bcast:0.0.0.0  Mask:255.255.252.0
        inet6 addr: 0000::0000:0000:fe19:26b0/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:45287446 errors:0 dropped:123343 overruns:2989 frame:0
        TX packets:3907747 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:66881007720 (62.2 GiB)  TX bytes:261053436 (248.9 MiB)
        Memory:f7e00000-f7efffff

eth1    Link encap:Ethernet  HWaddr 00:00:00:19:26:B1
        inet addr:192.168.8.142  Bcast:0.0.0.0  Mask:255.255.255.255
        inet6 addr: 0000::0000:0000:fe19:26b1/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:19358 errors:0 dropped:511 overruns:0 frame:0
        TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:1772275 (1.6 MiB)  TX bytes:1068 (1.0 KiB)
        Memory:f7c00000-f7cfffff

Po stronie serwera

# Listen for incomming from 192.168.8.142
nc -v -v -n -k -l 192.168.8.142 8000 | pv > /dev/null
Listening on [192.168.8.142] (family 0, port 8000)
Connection from 192.168.8.135 58785 received!

Klient

# Send to 192.168.8.142
time yes | pv |nc -s 192.168.8.135 -4 -v -v -n 192.168.8.142 8000 >/dev/null
Connection to 192.168.8.142 8000 port [tcp/*] succeeded!

Po stronie serwera

$ iftop -i eth0
interface: eth0
IP address is: 192.168.8.140

TX:             cumm:  6.34MB   peak: 2.31Mb   rates: 2.15Mb  2.18Mb  2.11Mb
RX:                    2.55GB          955Mb           874Mb   892Mb   872Mb
TOTAL:                 2.56GB          958Mb           877Mb   895Mb   874Mb

$ iftop -i eth1
interface: eth1
IP address is: 192.168.8.142

TX:             cumm:      0B   peak:     0b   rates:     0b      0b      0b
RX:                    4.51KB         3.49Kb          3.49Kb  2.93Kb  2.25Kb
TOTAL:                 4.51KB         3.49Kb          3.49Kb  2.93Kb  2.25Kb

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:19:26:b0 brd ff:ff:ff:ff:ff:ff
$ ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:19:26:b1 brd ff:ff:ff:ff:ff:ff

1
Wygląda na to, że to, czego naprawdę szukasz, to łączenie interfejsów: wiki.linuxfoundation.org/networking/bonding
Flexo

@flexo ma całkowitą rację - w zależności od ostatecznego celu połączenie dwóch interfejsów sieciowych może zapewnić większą ogólną przepustowość, ale opcje łączenia są różne. Najlepsze, co możesz uzyskać, to 2 strumienie ~ 1 Gbit, a nie 1 strumień 2 Gbit. Ponadto potrzebujesz usług zarządzanego przełącznika Ethernet. Podobnie łączenie 4 może dawać 4x 1 Gbit przepływów jednocześnie.
Criggie

Odpowiedzi:


32

Istnieją dwa możliwe modele projektowania stosu sieciowego TCP / IP: model silnego hosta i model słabego hosta. Oczekujesz zachowania, które pasowałoby do silnego modelu hosta. Linux został zaprojektowany do korzystania ze słabego modelu hosta. Ogólnie model słabego hosta jest bardziej powszechny, ponieważ zmniejsza złożoność kodu routingu, a zatem może oferować lepszą wydajność. W przeciwnym razie dwa modele hosta to po prostu różne zasady projektowania: żaden z nich nie jest z natury lepszy od drugiego.

Zasadniczo słaby model hosta oznacza, że ​​ruch wychodzący zostanie wysłany z pierwszego interfejsu wymienionego w tabeli routingu, który odpowiada adresowi IP miejsca docelowego (lub wybranej bramy, jeśli miejsce docelowe nie jest osiągalne bezpośrednio), bez względu na źródłowy adres IP adres .

Jest to zasadniczo powód, dla którego generalnie nie zaleca się używania dwóch oddzielnych interfejsów fizycznych, jeśli potrzebujesz dwóch adresów IP w tym samym segmencie sieci. Zamiast tego przypisz dwa adresy IP do jednego interfejsu (aliasy IP: np. Eth1 = 192.168.8.142 i eth1: 0 = 192.168.8.140). Jeśli potrzebujesz większej przepustowości niż pojedynczy interfejs może zapewnić, połącz (lub zespól, jeśli dotyczy) dwa lub więcej interfejsów razem, a następnie uruchom oba adresy IP na łączu / zespole.

Poprzez dostosowanie wielu ustawień sysctl i użycie funkcji „zaawansowanego routingu” do skonfigurowania niezależnych tabel routingu dla każdej karty sieciowej, można sprawić, że Linux będzie zachowywał się jak system z silnym hostem. Jest to jednak bardzo specjalna konfiguracja i przed wdrożeniem zaleciłbym dwa razy zastanowienie się.

Zobacz odpowiedzi na temat routingu źródła Linux, modelu silnego systemu końcowego / modelu silnego hosta? jeśli naprawdę tego potrzebujesz.


Domyślnym trybem jest również złe niespodzianka czeka jeśli próbuje ruchu kształt z iptables :)
rackandboneman

tak, w przeszłości dobrze się bawiłem, wdrażając model silnego hosta. Było to wymagane w tym projekcie, ale nie zawracałbym sobie głowy bólem głowy w przypadku komputera osobistego.
Baldrickk

11

Dodatkową kwestią do rozważenia jest to, że interfejs eth1 jest skonfigurowany z maską podsieci 255.255.255.255.

Oznacza to, że interfejs eth1 jest skonfigurowany tak, aby nie oczekiwać innych urządzeń (hostów) na swoim interfejsie sieciowym. Oznacza to, że nie będzie w stanie komunikować się z klientem 192.168.8.142.


2

Po wielu poszukiwaniach odkryłem, dlaczego netcat nie używa odpowiedniego interfejsu związanego z adresem IP? i to jest ten sam problem. Jak powiedział @telcoM, ruch wychodzący zostanie wysłany do pierwszego interfejsu, i to jest problem, więc najłatwiejszym sposobem rozwiązania tego jest:

ip route add default via 192.168.8.142 dev eth1 table 142
ip rule add from 192.168.8.142 table 142

Ta trasa spowoduje ip route get 192.168.8.135 from 192.168.8.142zwrot eth1 zamiast eth0. Wtedy wszystko działa zgodnie z oczekiwaniami.


3
Jeśli pominiesz ustawienia sysctl ARP wspomniane w pytaniu, o którym wspomniałem, i masz do czynienia z przełącznikami i routerami klasy korporacyjnej, administrator sieci będzie trochę niezadowolony z powodu powodowania niepotrzebnych komunikatów „trzepotania adresu IP” na routerze, ponieważ system może nadal odpowiadać na żądania ARP dla obu adresów IP na obu interfejsach. Lub jeśli masz ochronę przed przejęciem adresu IP w sieci, może on włączyć i wyłączyć cały ruch do twojego systemu.
telcoM
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.