Eu tenho um sistema com dois NICs nele. Esta máquina, e alguns dispositivos acompanhantes, serão movidos e conectados a diferentes LANs ou, às vezes, usarão discagem.
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
Eu estou usando ifconfig para trazer interfaces para cima ou para baixo (diferente de ppp0, que é tratado pelo KPPP).
Se eu abrir a eth1 primeiro, ela recebe um endereço de seu DHCP e obtém o gateway, que é adicionado ao roteamento para que não haja problemas em alcançar a LAN e a Internet.
Se eu chamar eth0 primeiro ou segundo, ele obtém seu endereço e configura o gateway padrão para seu espaço de endereço (no intervalo 10.x.x.x). Se eu chamar eth0 first e eth1 second, o gateway padrão ainda é mantido dentro do intervalo 10.x.x.x.
Portanto, não importa o que eu faça, o eth0 irá sobrescrever eth1 e "reivindicar" o gateway no roteamento.
Existe alguma maneira de impedir que a eth0 reivindique o gateway ou de garantir que a eth1 (se criada em segundo lugar) use seu gateway? Ou posso de alguma forma priorizar um ranking de qual portal de interface deve ser usado sobre os outros?
Eu basicamente quero ter certeza de que o gateway de espaço de endereçamento padrão da eth1 é usado se estiver ativo, e se não, então o gateway padrão do ppp0 é usado. Gostaria de poder impedir que o eth0 tenha sempre o gateway padrão.
A configuração do servidor DHCP está errada. Não deve enviar uma opção de gateway padrão quando não puder fornecer roteamento para o resto do mundo. Se ele enviar essa opção, qualquer cliente poderá assumir que pode enviar pacotes para qualquer destino fora do link para o gateway padrão especificado.
Portanto, sua caixa está correta ao usar o gateway padrão da eth0, se for informado pelo DHCP. A solução é remover a má opção do seu servidor DHCP.
Eu enfrentei um problema semelhante no Raspbian (suponho que a solução abaixo seja aplicável ao Debian também). O Raspberry Pi 3 possui 2 NICs integradas: Wi-Fi e Ethernet. Eu uso os dois, eles são wlan0 e eth0, respectivamente. O wlan0 está conectado à minha rede Wi-Fi doméstica e o acesso à internet é feito através dessa interface. Obtém suas configurações via DHCP do meu roteador doméstico. O eth0 é conectado diretamente ao meu PC com Windows e tem um IP estático atribuído. Nenhum acesso à internet via eth0 estava disponível desde que eu não o configurei no meu PC com Windows.
No Raspbian, o daemon dhcpcd é responsável por configurar as interfaces de rede. Para definir o IP estático para a interface eth0, havia as seguintes linhas adicionadas ao final de /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
Com essas configurações, o dhcpcd criou duas rotas padrão e a rota via eth0 teve prioridade mais alta do que a via 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
Então eu não tinha acesso à internet, porque o sistema tentou rotear via eth0 e não tinha acesso à internet, como mencionei acima.
Para resolver o problema, usei a opção nogateway na interface /etc/dhcpcd.conf for eth0. Então a configuração específica do eth0 começou a ficar assim:
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
Depois de salvar essa configuração e reinicializar, não havia nenhuma rota padrão via 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
O acesso à Internet apareceu e o problema foi resolvido.
ok, então o que você quer é que a máquina nunca acesse um gateway padrão quando ele acionar o eth0 e obtiver seu endereço via DHCP.
Aqui está a solução:
Editar arquivo:
/etc/dhcp/dhclient-up-hooks
e preencha com:
#!/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
antes:
[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
após 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
No RHEL6 / Fedora 22, o seguinte foi testado.
Em / etc / sysconfig / network-scripts / ifcfg-eth1 adicione a linha:
DEFROUTE=no
Substitua eth1 pelo nome da interface na qual o roteamento padrão não é desejado.
Isso também pode ser feito através da GUI do Network Manager marcando a caixa "Usar esta conexão somente para recursos em sua rede" na parte inferior da guia IPv4.
DEFROUTE = no impede a adição da rota padrão (destino 0.0.0.0) à tabela de roteamento quando a interface está ativada. ie. a seguinte entrada não será adicionada.
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
Você pode editar o arquivo dhcpclient.conf e não solicitar qualquer rota padrão do servidor DHCP remoto.
Uma pequena amostra do que eu fiz e está funcionando para o meu caso
send host-name = "random-hostname";
request subnet-mask, broadcast-address, time-offset, interface-mtu, rfc3442-classless-static-routes, ntp-servers;
Tags networking routing ifconfig ipv4