Não é possível usar o "eth1" em uma configuração dupla de IP CentOS VPS

0

Hoje recebi um VPS com dois endereços IP.

O IP em eth0 está funcionando quando eu faço ping -I eth0 www.google.com Tenho 0% de perda de pacotes, mas quando eu faço ping -I eth1 www.goole.com , recebi 100% de perda de pacotes.

Esta é a ifconfig output:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 185.8.49.12  netmask 255.255.255.0  broadcast 185.8.49.255
    inet6 fe80::250:56ff:fe84:5ed6  prefixlen 64  scopeid 0x20<link>
    ether 00:50:56:84:5e:d6  txqueuelen 1000  (Ethernet)
    RX packets 5716  bytes 398892 (389.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 933  bytes 294738 (287.8 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    inet 185.8.49.157  netmask 255.255.255.0  broadcast 185.8.49.255
    ether 00:50:56:84:5e:d7  txqueuelen 1000  (Ethernet)
    RX packets 0  bytes 0 (0.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 0  bytes 0 (0.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 0  (Local Loopback)
    RX packets 56  bytes 8896 (8.6 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 56  bytes 8896 (8.6 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Esta é a saída de ifcfg-eth0 :

DEVICE=eth0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
BOOTPROTO=none
IPADDR=185.8.49.12
NETMASK=255.255.255.0
GATEWAY=185.8.49.1
DNS1=62.149.128.4
DNS2=62.149.132.4

E esta é a saída de ifcfg-eth1 :

DEVICE=eth1
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
BOOTPROTO=none
IPADDR=185.8.49.157
NETMASK=255.255.255.0
GATEWAY=185.8.49.1

Eu tentei reiniciar o sistema, mas nada funciona.

    
por HyperGainZ 18.09.2015 / 18:44

1 resposta

1

"DEFROUTE = yes" em ambas as configurações de interface não faz o que você acha que faz.

Reinicialize (para limpar qualquer ajuste que você tenha feito) e execute "ip route".
Você deveria ver algo como:

# ip route
default via 185.8.49.1 dev eth0
185.8.49.0/24 dev eth0  proto kernel  scope link  src 185.8.49.12 
185.8.49.0/24 dev eth1  proto kernel  scope link  src 185.8.49.157 

Quando você emite "ping -I eth1 8.8.8.8", porque o sistema não está configurado com um gateway padrão acessível fora de eth1, as solicitações ARP são enviadas para todas as interfaces para localizar 8.8.8.8 na rede local:

# ping -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 185.8.49.157 eth1: 56(84) bytes of data.
From 185.8.49.157 icmp_seq=1 Destination Host Unreachable
From 185.8.49.157 icmp_seq=2 Destination Host Unreachable
From 185.8.49.157 icmp_seq=3 Destination Host Unreachable
From 185.8.49.157 icmp_seq=4 Destination Host Unreachable

# tcpdump -ni eth0 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.821526 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:43.821185 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:44.823000 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46

# tcpdump -ni eth1 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.820834 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:43.820864 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:44.822841 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28

(Obviamente, o servidor DNS do Google não está na mesma sub-rede que o seu VPS.)

Vá em frente e tente adicionar a segunda rota padrão:

# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists

Parece que o sistema não aceita prontamente várias rotas padrão.
E isso faz algum sentido - de que outra forma o dispositivo saberia através de quais de seus múltiplos gateways enviar um pacote? Ele enviaria uma cópia por gateway ... então lidaria com vários pacotes de retorno? Ou enviaria pacotes arbitrariamente, de maneira não determinista (um pesadelo para solucionar problemas)?
Presumivelmente, poderia balancear a carga, então vamos tentar isso:

#ip route delete default
#ip route add default scope global nexthop via 185.8.49.1 dev eth0 weight 1 nexthop via 185.8.49.1 dev eth1 weight 1
#ip ro
default 
        nexthop via 185.8.49.1  dev eth0 weight 1
        nexthop via 185.8.49.1  dev eth1 weight 1
...

Mas isso funciona?

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=17.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=17.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=15.3 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 15.337/17.227/18.762/1.241 ms

# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:31.837933 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 1, length 64
05:46:31.855566 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 1, length 64
05:46:33.842373 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 3, length 64
05:46:33.859469 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 3, length 64

# tcpdump -ni eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:32.840535 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 2, length 64
05:46:32.859029 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 2, length 64
05:46:34.843725 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 4, length 64
05:46:34.859020 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 4, length 64

TA-DA!
Agora cabe a você decidir se o balanceamento de carga é algo que você realmente precisa e está disposto a dar suporte.

    
por 20.09.2015 / 11:51