☰

Kurz zusammengefasst

tag-icon • tag-icon ubuntu networking tcp port-forwarding socket
Kurz zusammengefasst

Ich verwende Ubuntu server 22.04und habe ein eigenartiges Portweiterleitungsproblem mit einem lokalen Computer. Dieser Computer hat zwei Ethernet-Schnittstellen und die verbundene enp1s0Schnittstelle hat eine IP-Adresse 192.168.1.50. Die vollständige IP-Konfiguration lautet wie folgt:

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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4f:68:02:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 metric 100 brd 192.168.1.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 240f:74:de92::d1e/128 scope global dynamic noprefixroute 
       valid_lft 35597sec preferred_lft 35597sec
    inet6 fd41:d8b6:99ba::d1e/128 scope global dynamic noprefixroute 
       valid_lft 35597sec preferred_lft 35597sec
    inet6 fd41:d8b6:99ba:0:2e0:4fff:fe68:2bb/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 240f:74:de92:0:2e0:4fff:fe68:2bb/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 98462sec preferred_lft 98462sec
    inet6 fe80::2e0:4fff:fe68:2bb/64 scope link 
       valid_lft forever preferred_lft forever
3: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:e0:4c:68:01:6e brd ff:ff:ff:ff:ff:ff
    altname enp2s0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:55:86:e6:e5 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

Ich habe Portweiterleitungsregeln für meinen Router eingerichtet, so dass alle eingehenden TCP- oder UDP- from wan to port 22211Paketeforwarded to lan 192.168.1.50 port 22211

In meiner ufwKonfiguration habe ich das Routing dieses Ports zugelassen:

$ sudo ufw status
[sudo] password for *
Status: active

To                         Action      From
--                         ------      ----
22211/tcp                  ALLOW       Anywhere                  
22211/tcp (v6)             ALLOW       Anywhere (v6)

Wenn ich jetzt einen einfachen Netcat-Socket ( nc -l -p 22211) für diesen Port starte, kann ich ihn telnetproblemlos über eine andere Maschine im lokalen Netzwerk erreichen. Hier ist tcudumpdas Protokoll, wenn ich von einer anderen lokalen Maschine aus per Telnet telefoniere. Ich verbinde mich, sende einen Brief aund drücke die Eingabetaste:

$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:01:48.350024 IP (tos 0x0, ttl 64, id 59572, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [S], cksum 0x527d (correct), seq 3440167578, win 32120, options [mss 1460,sackOK,TS val 3772353734 ecr 0,nop,wscale 7], length 0
21:01:48.350139 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.50.22211 > 192.168.1.196.38840: Flags [S.], cksum 0x3a60 (correct), seq 495600843, ack 3440167579, win 65160, options [mss 1460,sackOK,TS val 102903428 ecr 3772353734,nop,wscale 7], length 0
21:01:48.351892 IP (tos 0x0, ttl 64, id 59573, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [.], cksum 0x66b7 (correct), seq 1, ack 1, win 251, options [nop,nop,TS val 3772353737 ecr 102903428], length 0
21:01:50.698846 IP (tos 0x0, ttl 64, id 59574, offset 0, flags [DF], proto TCP (6), length 55)
    192.168.1.196.38840 > 192.168.1.50.22211: Flags [P.], cksum 0xf275 (correct), seq 1:4, ack 1, win 251, options [nop,nop,TS val 3772356082 ecr 102903428], length 3

Aber wenn ich Telnet von außerhalb meines lokalen Netzwerks versuche, wird die Verbindung aus irgendeinem Grund nie hergestellt. Lange Zeit war ich sicher, dass meine Portweiterleitungskonfiguration deaktiviert war (obwohl derselbe Router andere Ports problemlos an eine andere Maschine in meinem lokalen Netzwerk weiterleitet und ich die Konfiguration im Grunde nur auf einen anderen Port gespiegelt habe), aber wie Sie den tcpdumpfolgenden Protokollen entnehmen können, kommen Pakete an der enp1s0Schnittstelle an:

$ sudo tcpdump -pnvvi enp1s0 port 22211
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:05.448829 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x4448 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560510789 ecr 0,sackOK,eol], length 0
20:58:06.593532 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x405f (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560511790 ecr 0,sackOK,eol], length 0
20:58:07.613818 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x3c76 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560512791 ecr 0,sackOK,eol], length 0
20:58:08.603603 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.9875 > 192.168.1.50.22211: Flags [S], cksum 0x388c (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560513793 ecr 0,sackOK,eol], length 0
20:58:09.563590 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    126.33.109.168.36371 > 192.168.1.50.22211: Flags [S], cksum 0xcd21 (correct), seq 2086171535, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 560514795 ecr 0,sackOK,eol], length 0

Ich kann auch sehen, dass Netcat alle Schnittstellen abhört (den Teil 0.0.0.0):

$ sudo ss -tulpn | grep 22211
tcp   LISTEN 0      1                               0.0.0.0:22211      0.0.0.0:*    users:(("nc",pid=3344,fd=3))

Die Routingtabelle sieht wie folgt aus:

$ sudo route -vn
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 enp1s0
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 enp1s0
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     100    0        0 enp1s0
192.168.1.1     0.0.0.0         255.255.255.255 UH    100    0        0 enp1s0

Ich verstehe also nicht, warum die Pakete, die von einem externen Netzwerk kommen, nie den lokalen Socket im Port 22211 erreichen. Gibt es eine zusätzliche Firewall-Konfiguration, die ich konfigurieren muss?

Bearbeiten: Interessanterweise tritt tatsächlich ping 8.8.8.8eine Zeitüberschreitung auf (während beispielsweise das Pingen auf google.com problemlos funktioniert)

Antwort1

Kurz zusammengefasst

Wenn etwas Kompliziertes nicht funktioniert, dann vergewissern Sie sich zunächst, dass die Grundlagen einwandfrei funktionieren.

Längere Version

Präambel

Dies ist ein gutes Beispiel dafür, wie man eine Frage stellt.

  1. Es gibt Hintergrundinformationen, z. B. läuft Ubuntu 22.04, die Maschine hat zwei Ethernet-Schnittstellen.

  2. Es werden detaillierte Informationen, z. B. die IP-Konfigurationsinformationen, bereitgestellt.

  3. Es werden sowohl funktionierende als auch nicht funktionierende Beispiele angezeigt.

Debuggen des Problems.

Missverständnisse korrigieren.

  • Der OP erklärte: „Ich verstehe nicht, warum die Pakete, die von außerhalb des Netzwerks kommen, nie den lokalen Socket im Port 22211 erreichen.“ Obwohl die Daten zeigten, dass die Pakete ankamen, waren es die Antworten, die diese Schnittstelle nicht verließen.

  • Der OP sagte, dass es zwei Schnittstellen gab. Die IP-Informationen zeigen, dass die zweite Schnittstelle ausgefallen ist, aber vielleicht hat die Maschine erwartet, die Antwort über die andere Schnittstelle zu senden?

Erstanfrage für weitere Informationen.

  • "Zeigt die Routing-Tabelle, dass die Route zu 126.33.189.168 über die aktive Schnittstelle (enp1s0) führt?" Der OP antwortete, indem er die Routing-Tabelle hinzufügte und sagte außerdem

  • „Ich habe der Originalnachricht die Routing-Tabelleninformationen hinzugefügt. Außerdem habe ich sichergestellt, dass die andere Schnittstelle eno1 ausgefallen ist, aber es scheint keine Änderung zu geben.“

Zweite Anfrage für weitere Informationen.

Die Routing-Tabelle enthielt symbolische Namen und keine numerischen Adressen. Ohne Kenntnis der Zuordnung war dies nicht sehr nützlich.

  • „Könnten Sie Ihre Bearbeitung bitte so ändern, dass die Ausgabe sudo route -vnder numerischen Werte angezeigt wird?“

Stellen Sie die Fragen auf eine Weise, die für den Antwortenden natürlich ist.

In einem Kommentar wurde vorgeschlagen, ip routeanstelle von zu verwenden route -vn. Ich verwende es ip routeseit Jahren und würde behaupten, dass es ein besseres Tool ist. Die Frage, die man stellen sollte, lautet: „Versuchen wir, dem OP bessere Tools beizubringen, oder versuchen wir, ihm zu helfen, sein Problem zu beheben?“. Ich denke, es wäre ablenkend, neue Tools einzuführen.

Zweite Anfrage nach weiteren Informationen – Fortsetzung folgt.

  • "Können Sie auch bestätigen, dass Sie von 192.168.1.50 aus eine bekannte Adresse anpingen können, z. B. 8.8.8.8?" Dies rief die Antwort hervor

  • „Sie haben Recht, aus irgendeinem Grund läuft Ping 8.8.8.8 ab! Aber Ping google.com funktioniert einwandfrei.“

Debuggen, warum ping google.comfunktioniert

  • „Und welche IP-Adresse wählt der Ping von google.com? (Sie wird in der ersten Zeile angezeigt.) Das klingt, als hätten Sie sich durch eine Firewall von IPv4 abgeschirmt, verfügen aber immer noch über voll funktionsfähiges IPv6.“

Ich würde den Begriff nicht verwenden firewalled. Da die Routing-Tabelle zwei Standardrouten mit unterschiedlichen Metriken anzeigte, handelte es sich nun mit ziemlicher Sicherheit um ein Routing-Problem.

Dritte Bitte um weitere Informationen.

Die meisten Menschen verfügen nur über eine einzige Internetverbindung. Versuchen Sie jedoch, keine ungerechtfertigten Annahmen zu treffen.

  • „Erwarten Sie, dass Sie zwei Router haben, von denen jeder das Internet erreichen kann (vielleicht mit zwei verschiedenen ISPs)?“

Als die Antwort negativ ausfiel, musste ich dem OP nur sagen, dass er das Routing-Problem beheben solle (mit dem Befehl, mit dem er vertraut war), und alles funktionierte. Wenn man die Antwort vorwegnimmt und die Anweisungen mit der Frage eingibt, spart man Verzögerungen.

  • „Die Möglichkeit, 8.8.8.8 anzupingen, ist Ihr wichtigstes Problem. Wenn Sie das lösen, ist möglicherweise alles gelöst.“

Das eigentliche Problem.

  • Wenn Pakete über das Internet und nicht über das lokale Netzwerk gesendet werden müssen, wurde ihnen gesagt, sie sollten über eine nicht vorhandene Maschine laufen.

  • Um Pakete an diese nicht vorhandene Maschine zu senden, schickte der Host ARP-Pakete, die keine Antwort erhielten.

  • Schließlich gab der Host die Versuche auf, Kontakt mit der nicht vorhandenen Maschine aufzunehmen, und meldete einen Fehler beim Ping-Befehl oder schickte keine Bestätigung für die eingehende Verbindung.

  • Durch das Korrigieren der Routing-Tabelle, um Pakete, die für das Internet bestimmt sind, über die richtige Adresse zu senden, funktionierte alles.

verwandte Informationen