Somente a NIC do gateway padrão recebe resposta para o Ping

Question

Somente a NIC do gateway padrão recebe resposta para o Ping

#1 resposta do (1 votos)

0

Caso cenário ( Kali Linux v2 no RaspBerry Pi 2 B +):

luis@Fresoncio:~$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.18.25.1     0.0.0.0         UG    0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    100    0        0 eth1
default         192.168.35.100  0.0.0.0         UG    101    0        0 eth2
... etc (see full table below)

Cartões Ethernet (cabo RJ45) ( NICs ):

luis@Fresoncio:~$ sudo ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.25.246  netmask 255.255.255.0  broadcast 172.18.25.255
        inet6 fe80::ba27:ebff:fe92:feb3  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:92:fe:b3  txqueuelen 1000  (Ethernet)
        RX packets 3013014  bytes 296362931 (282.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9910966  bytes 558782777 (532.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.33  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::b117:1000:39bb:f8f0  prefixlen 64  scopeid 0x20<link>
        ether a0:ce:c8:09:e3:ef  txqueuelen 1000  (Ethernet)
        RX packets 97636  bytes 7342211 (7.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 471  bytes 31163 (30.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.35.104  netmask 255.255.255.0  broadcast 192.168.35.255
        inet6 fe80::805b:dfe3:8c3b:61ff  prefixlen 64  scopeid 0x20<link>
        ether a0:ce:c8:09:f8:84  txqueuelen 1000  (Ethernet)
        RX packets 276507  bytes 18134656 (17.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 215  bytes 19996 (19.5 KiB)
        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 96  bytes 12362 (12.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96  bytes 12362 (12.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
--- etc (see fulll table below)

Como pode ser visto, este computador tem 3 NICs . Pings para o trabalho na internet com todos eles ao especificar o NIC:

luis@Fresoncio:~$ sudo ping -I eth0 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 172.18.25.246 eth0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=36.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=308 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=85.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=151 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=56.6 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 36.753/127.695/308.472/98.316 ms
luis@Fresoncio:~$ sudo ping -I eth1 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.1.33 eth1: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=43.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=41.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=40.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=41.5 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=40.9 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 40.757/41.517/43.303/0.962 ms
luis@Fresoncio:~$ sudo ping -I eth2 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.35.104 eth2: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=37.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=49.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=37.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=53.2 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 37.499/45.711/53.250/6.723 ms

E agora o cenário caso com falha ( Ubuntu v16 no laptop):

luis@Hipatio:~$ sudo route
Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
default         Router-         0.0.0.0         UG    0      0        0 enp2s0
default         192.168.22.1    0.0.0.0         UG    100    0        0 enx3c18a00b753d
link-local      *               255.255.0.0     U     1000   0        0 enp2s0
192.168.11.0    *               255.255.255.0   U     0      0        0 enp2s0
192.168.22.0    *               255.255.255.0   U     100    0        0 enx3c18a00b753d

Desta vez com 2 NICs de cabo RJ45 :

luis@Hipatio:~$ ifconfig
enp2s0    Link encap:Ethernet  direcciónHW 68:f7:28:d2:a4:ce
          Direc. inet:192.168.11.119  Difus.:192.168.11.255  Másc:255.255.255.0
          Dirección inet6: fe80::6af7:28ff:fed2:a4ce/64 Alcance:Enlace
          ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:454517 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:1940326 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:73243397 (73.2 MB)  TX bytes:2778755895 (2.7 GB)

enx3c18a00b753d Link encap:Ethernet  direcciónHW 3c:18:a0:0b:75:3d
          Direc. inet:192.168.22.51  Difus.:192.168.22.255  Másc:255.255.255.0
          Dirección inet6: fe80::4c9d:de01:a97a:fd42/64 Alcance:Enlace
          ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:194 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:355 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:20096 (20.0 KB)  TX bytes:39265 (39.2 KB)

lo        Link encap:Bucle local
          Direc. inet:127.0.0.1  Másc:255.0.0.0
          Dirección inet6: ::1/128 Alcance:Anfitrión
          ACTIVO BUCLE FUNCIONANDO  MTU:65536  Métrica:1
          Paquetes RX:60 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:60 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1
          Bytes RX:5099 (5.0 KB)  TX bytes:5099 (5.0 KB)

Desta vez, falhando (sem resposta) ao fazer ping da NIC não padrão:

luis@Hipatio:~$ ping -I enx3c18a00b753d -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.22.51 enx3c18a00b753d: 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

O padrão funciona OK:

luis@Hipatio:~$ ping -I enp2s0 -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.168.11.119 enp2s0: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=51.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=52.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=50.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=51.0 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 50.812/51.498/52.995/0.826 ms

luis@Hipatio:~$ ping -c 5 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=51 time=57.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=57.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=57.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=51 time=57.1 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=51 time=57.6 ms

O mesmo teste falha muito no Ubuntu Mate v16 para RaspBerry Pi 2 B + (4 NICs RJ45 desta vez): apenas o padrão funciona. Então, eu estou querendo saber se o problema deve estar no Ubuntu (estou certo de que esses testes de ping funcionaram em versões mais antigas do Ubuntu, como a v14). De qualquer forma, saber como solucionar o problema de qualquer Linux seria melhor para mim.

O que está acontecendo aqui e como eu poderia de um NIC específico ?

NOTA 1 : A distro de trabalho do Kali no primeiro exemplo tem várias VPNs funcionando ao mesmo tempo (um pouco confuso para ler, eu diria), então eu cortei a tabela route . Aqui está a versão completa (eu diria que não há necessidade disso, mas ... quem sabe?):

luis@Fresoncio:~$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.18.25.1     0.0.0.0         UG    0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    100    0        0 eth1
default         192.168.35.100  0.0.0.0         UG    101    0        0 eth2
115.red-79-157- 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
67.red-79-157-8 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
187.red-81-32-1 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
227.red-81-32-1 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
82.red-81-33-18 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
190.red-83-44-1 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
152.red-83-44-2 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
249.red-83-44-2 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
10.red-83-52-23 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
172.red-83-52-2 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
206.red-83-52-2 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
33.244.222.87.d 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
32.246.222.87.d 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
235.248.222.87. 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
151.18.16.95.dy 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
196.48.16.95.dy 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
143.49.16.95.dy 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
189.54.16.95.dy 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
122.56.16.95.dy 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
11.81.20.95.dyn 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
237.204.22.95.d 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
177.206.22.95.d 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
163.red-95-123- 172.18.25.1     255.255.255.255 UGH   0      0        0 eth0
172.18.25.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 eth1
192.168.35.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.35.0    0.0.0.0         255.255.255.0   U     100    0        0 eth2
192.168.210.0   0.0.0.0         255.255.255.0   U     0      0        0 ppp0
192.168.211.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

... e aqui está o completo ifconfig :

luis@Fresoncio:~$ sudo ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.25.246  netmask 255.255.255.0  broadcast 172.18.25.255
        inet6 fe80::ba27:ebff:fe92:feb3  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:92:fe:b3  txqueuelen 1000  (Ethernet)
        RX packets 3018864  bytes 296745295 (282.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9911793  bytes 558868110 (532.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.33  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::b117:1000:39bb:f8f0  prefixlen 64  scopeid 0x20<link>
        ether a0:ce:c8:09:e3:ef  txqueuelen 1000  (Ethernet)
        RX packets 97908  bytes 7362465 (7.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 480  bytes 31821 (31.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.35.104  netmask 255.255.255.0  broadcast 192.168.35.255
        inet6 fe80::805b:dfe3:8c3b:61ff  prefixlen 64  scopeid 0x20<link>
        ether a0:ce:c8:09:f8:84  txqueuelen 1000  (Ethernet)
        RX packets 277209  bytes 18180584 (17.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 223  bytes 20612 (20.1 KiB)
        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 96  bytes 12362 (12.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96  bytes 12362 (12.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1446
        inet 192.168.210.141  netmask 255.255.255.0  destination 192.168.210.1
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 461  bytes 43679 (42.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 423  bytes 90174 (88.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.211.141  netmask 255.255.255.0  destination 192.168.211.141
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 14  bytes 704 (704.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

NOTE2 : uma nova pista. Ao pesquisar, descobri que o recurso multirouting poderia exigir a opção CONFIG_IP_MROUTE_MULTIPLE_TABLES ou CONFIG_IP_MULTIPLE_TABLES ativada no kernel .
Estou suspeitando disso, desde que esta seja a saída do computador com falha :

luis@Hipatio:/usr/src/linux-headers-4.4.0-62-generic$ cat .config | grep "multiple" -i
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Multiplexer I2C Chip support

E esta é a saída do computador em funcionamento :

luis@Fresoncio:/usr/src/kernel$ cat .config | grep "multiple" -i
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Multiplexer I2C Chip support

NOTE3 : Método testado (ou assim acredito) mencionado em NOTE2 modificando em /etc/default/grub a linha:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash CONFIG_IP_MROUTE_MULTIPLE_TABLES=y"

Como pode ser visto, agora o sistema começa com este parâmetro em yes :

luis@Hipatio:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-62-generic root=UUID=66464d51-851f-4623-b5cb-1699901a4a9b ro quiet splash CONFIG_IP_MROUTE_MULTIPLE_TABLES=y vt.handoff=7

Infelizmente, com sem resultados . Pings ainda falhando.

networking ping

por Sopalajo de Arrierez 05.10.2017 / 02:00

1 resposta

Tags networking ping

x sed substituir padrão com caractere de nova linha verificar processos antes de executar

score 1 · Answer 1

Por padrão, os sistemas realmente usam uma rota para um determinado destino, aquele que você obtém com ip route get 8.8.8.8 . Se ele receber um pacote em uma interface que não seria a mostrada com o comando anterior, ele será considerado um tipo de tentativa de spoofing e o descartará. Isso não será feito se você desativar a filtragem de caminho inverso:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/enx3c18a00b753d/rp_filter.

Quando possível, e sempre é possível com a rota padrão, o modo solto (usando valor 2, mantendo 1 para enp2s0) deve ser preferido.

Sobre o seu comentário, não há nenhuma condição de corrida com enp2s0: a tabela de roteamento não muda e não é alterada por essas configurações, então nenhuma corrida acontece. Veja o Documentação do kernel linux ip-sysctl.txt para mais detalhes.

Agora, para o seu objetivo, não é isso que realmente deve ser feito. Você tem que definir uma rota table por interface / provider e source ip (a propósito, é para isso que é CONFIG_IP_MULTIPLE_TABLES. Esqueça sobre CONFIG_IP_MROUTE * é para multicast). Em seguida, use alguma lógica de seleção com os comandos ip rule . Mais de uma possibilidade. Eg marcando pacotes com o iptables e usando aqueles mark com mais regras de roteamento , ou como um dos seus exemplos, configurando rotas específicas para destinos específicos, ou ainda mais simples (veja em o fim).

Todos os detalhes lá com exemplos:

link

É um pouco longo colocar diretamente um exemplo de trabalho aqui, mas parece simples de seguir (incluindo alguns avisos etc.). Apenas note que você não deveria mais ter que alterar rp_filter neste caso, porque os pacotes sempre chegarão pela interface esperada, mesmo que (e porque) o algoritmo de seleção de roteamento não seja tão simples como antes.

Uma vez no lugar (em vez de seu exemplo de balanceamento de carga baseado em rota), você pode fazer coisas com o iptables. Por exemplo, combinando na tabela nat o statistic do módulo --every para balancear a carga em cada nova conexão com vários SNATs (um por provedor) que você usaria.