Czy mogę zapobiec dodawaniu domyślnej trasy przy uruchamianiu interfejsu?

Mam system z dwoma kartami sieciowymi. To urządzenie i kilka towarzyszących mu urządzeń zostanie przeniesionych i podłączonych do różnych sieci LAN lub czasami będzie korzystało z połączenia dial-up.

    eth0:
    - 10.x.x.x address space
    - no internet gateway
    - only a few devices

eth1 (when used):
- 172.16.x.x or 192.168.x.x or other address spaces
- access to the gateway from LAN to internet

ppp0 (when used):
- internet access through dialup using KPPP

Korzystam z ifconfig, aby podnieść lub obniżyć interfejsy (inne niż ppp0, który jest obsługiwany przez KPPP).

Jeśli najpierw uruchomię eth1, pobiera adres z DHCP i pobiera bramę, która jest dodawana do routingu, więc nie ma problemu z dostępem do sieci LAN i Internetu.

Jeśli uruchomię eth0 jako pierwszą lub drugą, pobiera adres i ustawia bramę domyślną w swojej przestrzeni adresowej (w zakresie 10.xxx). Jeśli najpierw uruchomię eth0, a eth1 sekundę, domyślna brama nadal będzie znajdować się w zakresie 10.xxx.

Więc bez względu na to, co zrobię, eth0 zastąpi eth1 i „przejmie” bramę w routingu.

Czy jest jakiś sposób, aby albo powstrzymać eth0 przed zajęciem bramki, albo upewnić się, że eth1 (jeśli zostanie podniesiony na 2 miejscu) używa swojej bramki? Czy też mogę w jakiś sposób uszeregować według priorytetów, której bramy interfejsu należy użyć w stosunku do pozostałych?

Zasadniczo chcę się upewnić, że domyślna brama eth1 jest używana, jeśli jest aktywna, a jeśli nie, to używana jest domyślna brama ppp0. Chciałbym móc uniemożliwić interfejsowi eth0 kiedykolwiek domyślną bramę.

Konfiguracja serwera DHCP jest nieprawidłowa. Nie może wysyłać domyślnej opcji bramy, jeśli nie może zapewnić routingu do reszty świata. Jeśli wyśle ​​tę opcję, każdy klient może założyć, że może wysyłać pakiety dla dowolnego miejsca docelowego odłączonego od łącza do określonej domyślnej bramy.

Tak więc twoje urządzenie ma rację, używając domyślnej bramy z eth0, jeśli tak informuje DHCP. Rozwiązaniem jest usunięcie złej opcji z serwera DHCP.

Napotkałem podobny problem na Raspbian (przypuszczam, że poniższe rozwiązanie będzie miało zastosowanie również do Debiana). Raspberry Pi 3 ma zintegrowane 2 karty sieciowe: Wi-Fi i Ethernet. Używam ich obu, są to odpowiednio wlan0 i eth0. wlan0 jest podłączony do mojej domowej sieci Wi-Fi i dostęp do Internetu odbywa się za pośrednictwem tego interfejsu. Dostaje swoje ustawienia przez DHCP z mojego domowego routera. eth0 jest podłączony bezpośrednio do mojego komputera z systemem Windows i ma przypisany statyczny adres IP. Brak dostępu do Internetu przez eth0 był niedostępny, ponieważ nie skonfigurowałem go na komputerze z systemem Windows.

W Raspbian demon dhcpcd jest odpowiedzialny za konfigurację interfejsów sieciowych. Aby ustawić statyczny adres IP na interfejs eth0, na końcu dodano następujące linie /etc/dhcpcd.conf:

interface eth0

static ip_address=192.168.2.2/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1

Przy tych ustawieniach dhcpcd utworzył 2 domyślne trasy, a trasa przez eth0 miała wyższy priorytet niż przez wlan0:

pi@raspberrypi:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    202    0        0 eth0
default         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     *               255.255.255.0   U     303    0        0 wlan0
192.168.2.0     *               255.255.255.0   U     202    0        0 eth0

Więc nie miałem dostępu do Internetu, ponieważ system próbował trasować go przez eth0 i nie miał dostępu do Internetu, jak wspomniałem powyżej.

Aby rozwiązać problem, użyłem nogatewayopcji w /etc/dhcpcd.confinterfejsie dla eth0. Tak więc konfiguracja specyficzna dla eth0 zaczęła wyglądać tak:

interface eth0

static ip_address=192.168.2.2/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1
nogateway

Po zapisaniu tej konfiguracji i ponownym uruchomieniu nie było domyślnej trasy przez eth0:

pi@raspberrypi:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     *               255.255.255.0   U     303    0        0 wlan0
192.168.2.0     *               255.255.255.0   U     202    0        0 eth0

Pojawił się dostęp do Internetu i problem został rozwiązany.

Na RHEL6 / Fedora 22 przetestowano następujące elementy.

W / etc / sysconfig / network-scripts / ifcfg-eth1 dodaj wiersz:

DEFROUTE=no

Zamień eth1 na nazwę interfejsu, w którym domyślny routing nie jest pożądany.

Można to również zrobić za pomocą GUI Network Managera, zaznaczając pole „Używaj tego połączenia tylko do zasobów w jego sieci” u dołu karty IPv4.

DEFROUTE = no zapobiega dodaniu domyślnej trasy (miejsce docelowe 0.0.0.0) do tablicy routingu, gdy interfejs jest włączony. to znaczy. następujący wpis nie zostanie dodany.

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.x.x      0.0.0.0         UG        0 0          0 eth1

ok, więc chcesz, aby maszyna nigdy nie otwierała domyślnej bramy, gdy uruchomi eth0 i otrzyma swój adres przez DHCP.

Oto rozwiązanie:

Edytuj plik:

/etc/dhcp/dhclient-up-hooks

i wypełnić:

#!/bin/sh
## Prevent DHCP server on eth0 from forcing a default route on us

case ${interface} in
  eth0)
     printf "executing ip route delete default via $new_routers\n" 
     ip route delete default via $new_routers
  ;;
     *)
  ;;
esac

przed:

[root@centos7lab dhcp]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.4.1     0.0.0.0         UG    20     0        0 eth0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

po ifdown eth0, ifup eth0:

[root@centos7lab dhcp]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Możesz edytować plik dhcpclient.conf i nie żądać domyślnej trasy ze zdalnego serwera DHCP.

Mała próbka tego, co zrobiłem i działa w moim przypadku

send host-name = "random-hostname";

żądanie maski podsieci, adresu rozgłoszeniowego, przesunięcia czasowego, interfejsu-mtu, bezklasowych-statycznych tras rfc3442, serwerów NTTP;