☰

Rotear o tráfego para o dispositivo com um endereço IP estático por meio da interface especificada - não está funcionando?

tag-icon • tag-icon iproute
Rotear o tráfego para o dispositivo com um endereço IP estático por meio da interface especificada - não está funcionando?

Eu tenho um único dispositivo que configurei com um endereço IP estático (192.168.1.16) e está conectado diretamente à quarta porta (enp4s0) no meu PC Ubuntu Linux. O m/c também está conectado à minha LAN através da 3ª porta (enp3s0). Minha LAN usa DHCP para distribuir IPs na minha rede 192.168.1.1/24.

Agora quero poder fazer ping em meu dispositivo em 192.168.1.19 via enp4s0, então usei este comando para adicionar uma rota a ele por meio de um único endereço IP:

sudo ip route add 192.168.1.19/32 dev enp4s0

Infelizmente o ping falha:

$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
From 192.168.1.168 icmp_seq=1 Destination Host Unreachable
From 192.168.1.168 icmp_seq=2 Destination Host Unreachable
From 192.168.1.168 icmp_seq=3 Destination Host Unreachable

Olhando para algum status, vejo que o link está inativo:

$ ip route
default via 192.168.1.1 dev enp3s0 proto dhcp metric 101
default via 10.136.209.45 dev wwan0 proto static metric 700
10.136.209.40/29 dev wwan0 proto kernel scope link src 10.136.209.44 metric 700
169.254.0.0/16 dev enp3s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.168 metric 101
192.168.1.19 dev enp4s0 scope link linkdown

$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 78:d0:04:31:91:bd brd ff:ff:ff:ff:ff:ff
3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 78:d0:04:31:91:be brd ff:ff:ff:ff:ff:ff
4: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 78:d0:04:31:91:bf brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.168/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
       valid_lft 85575sec preferred_lft 85575sec
    inet6 fe80::1191:4ec4:6844:2273/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 78:d0:04:31:91:c0 brd ff:ff:ff:ff:ff:ff
6: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether e6:83:24:bc:f6:81 brd ff:ff:ff:ff:ff:ff
    inet 10.136.209.44/29 brd 10.136.209.47 scope global noprefixroute wwan0
       valid_lft forever preferred_lft forever
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:f1:f6:93:0b brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:f1ff:fef6:930b/64 scope link
       valid_lft forever preferred_lft forever
9: veth36abd25@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether ae:27:23:82:70:6a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::ac27:23ff:fe82:706a/64 scope link
       valid_lft forever preferred_lft forever

Estou faltando alguma outra coisa que preciso fazer para acessar o dispositivo em 192.168.1.19 ?

Atualizar:

Depois de tentar trocar os cabos, descobri que os conectores não estão em uma ordem lógica! Em vez de serem 1,2,3,4, são na verdade 1,4,3,2.

Então, o que pensei ser enp4s0 é na verdade en2s0. Tendo ultrapassado esta confusão, parece agora haverOutro problemacomo demonstrado aqui:

$ sudo ip route add 192.168.1.19/32 dev enp2s0
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         setup.ubnt.com  0.0.0.0         UG    102    0        0 enp3s0
default         _gateway        0.0.0.0         UG    700    0        0 wwan0
10.63.138.32    0.0.0.0         255.255.255.248 U     700    0        0 wwan0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp3s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.1.0     0.0.0.0         255.255.255.0   U     102    0        0 enp3s0
eZ80Acclaim     0.0.0.0         255.255.255.255 UH    0      0        0 enp2s0
$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
64 bytes from 192.168.1.19: icmp_seq=1 ttl=250 time=1.01 ms
64 bytes from 192.168.1.19: icmp_seq=2 ttl=250 time=1.06 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=250 time=1.18 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=250 time=1.27 ms
64 bytes from 192.168.1.19: icmp_seq=5 ttl=250 time=1.18 ms
64 bytes from 192.168.1.19: icmp_seq=6 ttl=250 time=1.04 ms
64 bytes from 192.168.1.19: icmp_seq=7 ttl=250 time=1.17 ms
64 bytes from 192.168.1.19: icmp_seq=8 ttl=250 time=1.18 ms
64 bytes from 192.168.1.19: icmp_seq=9 ttl=250 time=1.05 ms
64 bytes from 192.168.1.19: icmp_seq=10 ttl=250 time=1.17 ms
64 bytes from 192.168.1.19: icmp_seq=11 ttl=250 time=1.43 ms
64 bytes from 192.168.1.19: icmp_seq=12 ttl=250 time=0.941 ms
From 192.168.1.168 icmp_seq=13 Destination Host Unreachable
From 192.168.1.168 icmp_seq=14 Destination Host Unreachable
From 192.168.1.168 icmp_seq=15 Destination Host Unreachable
^C
--- 192.168.1.19 ping statistics ---
18 packets transmitted, 12 received, +3 errors, 33.3333% packet loss, time 17129ms
rtt min/avg/max/mdev = 0.941/1.139/1.433/0.124 ms, pipe 4
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         setup.ubnt.com  0.0.0.0         UG    102    0        0 enp3s0
default         _gateway        0.0.0.0         UG    700    0        0 wwan0
10.63.138.32    0.0.0.0         255.255.255.248 U     700    0        0 wwan0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp3s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.1.0     0.0.0.0         255.255.255.0   U     102    0        0 enp3s0
$

Como você pode ver, a rota é adicionada à tabela de rotas e o ping do dispositivo funciona. No entanto, após alguns segundos, o destino torna-se inacessível. Olhando novamente para a tabela de rotas, vejo que a rota foi removida!!

Portanto, a questão agora é 'quem' removeu a rota e por quê?

Responder1

Se a sua placa de rede não estiver conectada (como parece), você deverá ignorar o status da operadora.

Veressa outra perguntapara detalhes

Responder2

Acho que encontrei a resposta para a eliminação das rotas estáticas. Parece que o NetworkManger (nmcli) não gosta que eu adicione uma rota diretamente e, portanto, ele os mata em segundo plano.

Eu tenho alguma inspiraçãoaquisobre como adicionar uma rota estática para meu dispositivo usando nmcli. Então, usei este comando para adicionar a rota necessária.

$ sudo nmcli con add type ethernet con-name "static-ip" ifname enp2s0 ipv4.method manual ipv4.addresses 192.168.1.19/32 gw4 0.0.0.0

Não tenho certeza se entendi exatamente tudo o que está acontecendo, mas parece funcionar e agora posso executar ping em meu dispositivo em 192.168.1.19 o tempo todo. Melhor ainda, a mudança é persistente durante as reinicializações e também parece que consigo executar ping no dispositivo do meu laptop na mesma rede 192.168.1.0/24.

informação relacionada