Datenverkehr über die angegebene Schnittstelle an ein Gerät mit einer statischen IP-Adresse weiterleiten – funktioniert nicht?

Datenverkehr über die angegebene Schnittstelle an ein Gerät mit einer statischen IP-Adresse weiterleiten – funktioniert nicht?

Ich habe ein einzelnes Gerät, das ich mit einer statischen IP-Adresse (192.168.1.16) konfiguriert habe und das direkt mit dem 4. Port (enp4s0) meines Ubuntu-Linux-PCs verbunden ist. Das Gerät ist außerdem über den 3. Port (enp3s0) mit meinem LAN verbunden. Mein LAN verwendet DHCP, um IPs in meinem 192.168.1.1/24-Netzwerk zu verteilen.

Ich möchte nun in der Lage sein, mein Gerät unter 192.168.1.19 über enp4s0 anzupingen. Daher habe ich mit diesem Befehl eine Route über eine einzelne IP-Adresse dorthin hinzugefügt:

sudo ip route add 192.168.1.19/32 dev enp4s0

Leider schlägt der Ping fehl:

$ 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

Bei der Betrachtung einiger Statusmeldungen wird angezeigt, dass der Link unterbrochen ist:

$ 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

Übersehe ich noch etwas, das ich tun muss, um das Gerät unter 192.168.1.19 erreichen zu können?


Aktualisieren:

Nachdem ich versucht habe, die Kabel ein wenig umzutauschen, habe ich festgestellt, dass die Anschlüsse nicht in logischer Reihenfolge sind! Statt 1,2,3,4 sind sie in Wirklichkeit 1,4,3,2.

Was ich also für enp4s0 hielt, ist in Wirklichkeit en2s0. Nachdem diese Verwirrung überwunden ist, scheint es nunEin anderes Problemwie hier gezeigt:

$ 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
$

Wie Sie sehen, wird die Route zur Routentabelle hinzugefügt und das Pingen des Geräts funktioniert. Nach einigen Sekunden ist das Ziel jedoch nicht mehr erreichbar. Wenn ich mir die Routentabelle noch einmal ansehe, sehe ich, dass die Route entfernt wurde!!

Die Frage ist nun: „Wer hat die Route entfernt und warum?“

Antwort1

Wenn Ihre Netzwerkkarte nicht verbunden ist (wie es scheint), müssen Sie den Trägerstatus ignorieren.

Sehendiese andere Fragefür Details

Antwort2

Ich glaube, ich habe die Antwort auf das Löschen der statischen Routen gefunden. Es scheint, dass NetworkManger (nmcli) es nicht mag, wenn ich eine Route direkt hinzufüge, und deshalb beendet er sie im Hintergrund.

Ich habe etwas Inspiration bekommenHierwie ich stattdessen mit nmcli eine statische Route für mein Gerät hinzufüge. Also habe ich diesen Befehl verwendet, um die benötigte Route hinzuzufügen.

$ 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

Ich bin mir nicht ganz sicher, ob ich das alles genau verstehe, aber es scheint zu funktionieren und jetzt kann ich mein Gerät unter 192.168.1.19 ständig anpingen. Noch besser ist, dass die Änderung auch nach Neustarts bestehen bleibt und ich das Gerät anscheinend auch von meinem Laptop aus im selben Netzwerk 192.168.1.0/24 anpingen kann.

verwandte Informationen