Port Forwarding / Portweiterleitung debuggen

[Meikel_B]

Hallo zusammen,

ich möchte per SSH auf einen Rechner 192.168.1.19 zugreifen der hinter meinem Router per NAT ans Internet angebunden ist.

Auf dem Router habe ich eine Port-Weiterleitung eingerichtet:

TCP 22 --> 192.168.1.19 : 22

Aus dem Heimnetzwerk kann ich mich per SSH anmelden mit dem Befehl

ssh -p 22 sysadmin@192.168.1.19

und komme dann in die Shell des Zielrechners.

Wenn ich jetzt von außerhalb des Heimnetzes via Internet mich verbinden will mittels

ssh -vvp 22 sysadmin@<öffentliche-IP-des-Routers>

dann hängt der SSH-Client und irgendwann kommt die Meldung

debug1: connect to address <öffentliche-IP-des-Routers> port 22: Connection timed out

Der Zielrechner läuft unter Rocky Linux release 8.10, ich habe dort keine grafische Umgebung zur Verfügung, sondern nur die Shell (per SSH aus dem Heimnetz). Ich habe versucht auf dem Zielrechner zunächst mit einer rudimentären Analyse per tcpdump herauszufinden, ob überhaupt irgendwelche Pakete ankommen:

sudo tcpdump -i enp5s0 'host <DNS-Name-des-SSH-Client>'

und wenn ich jetzt versuche mich per SSH zu verbinden, dann bekomme ich von obigem tcpdump tatsächlich Meldungen angezeigt, etwa wie folgt:

16:35:17.078475 IP <DNS-Name-des-SSH-Client> > <interner-DNS-Name-des-Zielrechners>.ssh: Flags [S], seq 973816574, win 29200, options [mss 1452,sackOK,TS val 4160044127 ecr 0,nop,wscale 7], length 0

Dies interpretiere ich so, dass der Versuch eines Verbindungsaufbau für die SSH-Verbindung zumindest auf dem Zielrechner im Heimnetz ankommt. Ich habe vorsorglich vorübergehend die Firewall auf dem Zielrechner deaktiviert:

sudo systemctl stop firewalld.service

Trotz dieser Maßnahme kommt keine SSH-Verbindung zustande.

Ich habe keine Idee, wie ich das Problem weiter analysieren kann. Meiner Meinung nach sind die Informationen von tcpdump relativ dünn. Würde ein Netzwerkmitschnitt mittels Wireshark mehr Details liefern als tcpdump? Kann ich Wireshark ggf. ohne GUI in der Shell ausführen? Gibt es andere Tools die ich zur Analyse verwenden kann?

Wer hat eine Idee wie ich weiter vorgehen kann um das Problem einzugrenzen und zu lösen?

Randbemerkung: ich hatte die Portweiterleitung vor etwa 10 Tagen eingerichtet. Damals hatte der Zugang per SSH von außerhalb meines Heimnetzes einwandfrei funktioniert. Ich habe meines Wissens nach seither nichts an der Konfiguration geändert, lediglich der Zielrechner 192.168.1.19 war seit dem letzten Test heruntergefahren und ausgeschaltet, ich habe diesen erst heute wieder eingeschaltet.

Gruß,

Meikel

 

[blurrrr]

Hi,

najo, grundsätzlich gibt es ja nicht viele Ecken, an welchen Du ansetzen könntest. Ich gehe mal davon aus, dass Du für die Verbindung eine externe IPv4-Adresse nutzt. Pakete scheinen am Host anzukommen,

IP <DNS-Name-des-SSH-Client>

sollte dann der FQDN vom Provider sein. Bis dahin ja eigentlich auch alles tutti... Eigentlich bleiben da auch nur noch 2 Ecken übrig:

1) Router/Firewall
2) SSH-Host

Da sowas auf den Hosts für gewöhnlich nicht stattfindet: Zufällig mehrere öffentliche IPs an Router/Firewall vorhanden und/oder evtl. vorhandene NAT-Regeln, welche die Pakete umschreiben, so dass Dein "Client" sie mitunter verwirft (oder evtl. schon die Firewall vor dem Client)?

Desweiteren gibt es eigentlich nur 3 Stati bzw. der Verbindung:

1) Funktioniert
2) Wird abgelehnt (dann geht es ziemlich schnell)
3) Paket wird einfach ohne Rückmeldung verworfen (dauert dann eine Weile, bis die Nummer in einen Timeout läuft)

Wenn es bei Dir Client-seitig dann etwas dauert bis zur Rückmeldung, dann wird das Paket definitiv verworfen. Frage ist halt nur an welcher Stelle: Entweder vom SSH-Host (danach sieht es aber nicht aus), von der Firewall vor dem SSH-Host, von der Firewall vor dem Client oder dem Client selbst (inbesondere im Falle, dass aufgrund einer fehlerhaften NAT-Konfiguration der Firewall vor dem SSH-Host, die Antwort-Pakete mit einer falschen IP-Adresse bei Dir (Deinem Client/der Firewall vor dem Client) aufschlagen.

Also im besten Fall lässt Du einfach mal auf "beiden" Seiten (SSH-Host + Client) einen Paketmitschnitt laufen, während Du versuchst, eine Verbindung aufzubauen. Beim SSH-Host solltest Du allerdings auch ausgehende Pakete sehen. Ist dies nicht der Fall, versucht dieser evtl. seine Antwort über ein anderes Interface (Standard-Gateway) zu schicken.

Könntest auch ein bisschen mehr über die Infrastruktur erzählen (Netzwerk-Plan?), dann könnte man da ggf. auch besser ansetzen.

 

[the other]

Moinsen,
auf welchem Routermodell versuchst du das denn umzusetzen (Gerät auf dem die PWL eingerichtet wird)?

 

[Barungar]

Der tcpdump war von einem internen SSH Login?
Bist Du Dir sicher, dass Du eine "echte" externe IPv4 Adresse hast?

 

[the other]

Moinsen,
ich hatte es so verstanden, dass bei Versuch von extern keine Verbindung zum ssh Server zustande kommt, ein tcpdump aber durchaus zeigt, dass hierüber etwas bis zum Zielserver durchkommt, da dann aber Ende ist...daher die Verbindung selber von extern aufs LAN durchaus klappt...FALLS denn die Interpretation des dumps so stimmt. Das wäre ja ein Indiz für funktionierende echte öffentliche IPv4, oder?
Trotzdem immer gut, da nochmal zu fragen, bei der heutigen dslite / CGNAT "Seuche".

 

[Meikel_B]

Moinsen,
auf welchem Routermodell versuchst du das denn umzusetzen (Gerät auf dem die PWL eingerichtet wird)?

Das Router-Modell nennt sich Livebox und wurde vom Anbieter Orange (Frankreich) zu meinem Internet-Vertrag mitgeliefert (ähnlich wie in Deutschland bspw. Speedport von der Telekom). Ich kenne die rechtliche Situation hier nicht gut genug und habe keine Ahnung ob es Routerzwang gibt. Ich weiß auch nicht, ob rein technisch gesehen eine Fritz!Box an dem Anschluss hier laufen würde.

Hier die wichtigsten Daten die ich über die Web-Oberfläche abgefragt habe:

Fabricant Arcadyan
Modèle Livebox Fibre
Pays France
Version de firmware G06.R01.C21_06
Version de firmware Orange G06.R01.C21-fr

 

[Meikel_B]

Moinsen,
ich hatte es so verstanden, dass bei Versuch von extern keine Verbindung zum ssh Server zustande kommt, ein tcpdump aber durchaus zeigt, dass hierüber etwas bis zum Zielserver durchkommt, da dann aber Ende ist...daher die Verbindung selber von extern aufs LAN durchaus klappt...

Ja, so hatte ich es gemeint.

 

[Meikel_B]

Beim SSH-Host solltest Du allerdings auch ausgehende Pakete sehen. Ist dies nicht der Fall, versucht dieser evtl. seine Antwort über ein anderes Interface (Standard-Gateway) zu schicken.

Danke. Bei meiner allerersten Analyse hatte ich mich auch gewundert, dass nichts in die Gegenrichtung beim tcpdump zu sehen ist. Mir ist nach Deinem Hinweis mit dem Standard-Gateway dann prompt eine mögliche Problemursache eingefallen:
Der Zielrechner hat zwei Netzwerkkarten die mit demselben Netzwerk 192.168.1.0 verbunden sind. Eine kurze Überprüfung hat dann gezeigt, wo es vermutlich schief geht:

ip r s
default via 192.168.1.1 dev enp4s0 proto dhcp src 192.168.1.18 metric 100
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.19 metric 101
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.18 metric 100
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.19 metric 101

Die Pakete kommen per Portweiterleitung vom Router auf 192.168.1.19 an und werden vermutlich über 192.168.1.18 zurückgeschickt. Das geht vermutlich schief.
Ich habe um den verdacht zu bestätigen erstmal die Netzwerkkarte mit 192.168.1.18 deaktiviert und rebootet. Jetzt sieht es so aus:

ip r s
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.19 metric 100
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.19 metric 100

Jetzt komme ich per SSH von extern auf den Rechner drauf.
Super! Das Problem ist zumindest besser verständlich. Ich muss jetzt überlegen ob ich die erste Netzwerkkarte dauerhaft deaktiviert lasse. Trotzdem schonmal vielen Dank für die gute Unterstützung au dem Forum bis hierher.

 

[Meikel_B]

Randbemerkung: ich hatte die Portweiterleitung vor etwa 10 Tagen eingerichtet. Damals hatte der Zugang per SSH von außerhalb meines Heimnetzes einwandfrei funktioniert. Ich habe meines Wissens nach seither nichts an der Konfiguration geändert, lediglich der Zielrechner 192.168.1.19 war seit dem letzten Test heruntergefahren und ausgeschaltet, ich habe diesen erst heute wieder eingeschaltet.

Ich schätze, dass ich mich in diesem Punkt geirrt habe. Bei der Einrichtung der Portweiterleitung war damals nur eine Netzwerkkarte aktiv. Nachdem alles funktionierte habe ich die zweite Netzwerkkarte aktiviert und nicht mehr den Zugriff von außerhalb via Internet geprüft.

 

[Barungar]

Was versprichst Du Dir von zwei aktiven Netzwerkkarten mit IPs im gleichen Subnetz?

Der Grund dafür, dass es mit den beiden Netzwerkkarten nicht funktioniert hat war, dass Du die .19 auf der zweiten Netzwerkkarte hast und die .18 auf der ersten Netzwerkkarte. Und da beide ins gleiche Subnetz mit dem gleichen Standard Gateway gehen, hat in diesem Fall die erste Netzwerkkarte, die mit der .18, auf Grund der Routing-Metriken "gewonnen". Folglich sind alle Antworten über diese Karte rausgegangen. Das konnte der Router dann aber nicht mehr der eigehenden NAT-Verbindung zuordnen, weshalb der Client ein Timeout beim Verbindungsaufbau erhalten hat.

Es müsste funktionieren, wenn Du die Portweiterleitung auf die .18 im Router einstellst, so wäre wenn sich nichts an den Routing-Metriken ändert, sichergestellt, dass die Antwort so beim Router ankommt, dass er es der NAT-Verbindung zuordnen kann.

 

[Meikel_B]

Was versprichst Du Dir von zwei aktiven Netzwerkkarten mit IPs im gleichen Subnetz?

Dass ich mit zwei aktiven Netzwerkkarten im gleichen Subnetz angebunden bin ist keiner speziellen Anforderung geschuldet. Ich hatte es eingerichtet um zu prüfen ob beide Netzwerkkarten funktionieren und weil ich mich nicht entscheiden konnte, welche der beiden Buchsen ich verkabeln will, habe also einfach beide mit dem Router verbunden. Wie gesagt, es gibt keine Anforderung die diesen "Unsinn" erfordern würde. Aber zum Lernen war es hilfreich Vielleicht probiere ich demnächst aus, Bonding einzurichten, dann sind die beiden Netzwerkkarten "sinnvoll" genutzt. Aber auch eher nur zum Lernen, es ist nichts was ich in meinem Heimnetz brauche. Ich schreibe gleich nochmal in einem weiteren Post ein paar Worte zur Netzwerktopologie.

Es müsste funktionieren, wenn Du die Portweiterleitung auf die .18 im Router einstellst, so wäre wenn sich nichts an den Routing-Metriken ändert, sichergestellt, dass die Antwort so beim Router ankommt, dass er es der NAT-Verbindung zuordnen kann.

Das kann ich bestätigen. Ich hatte das gestern Abend direkt ausprobiert: erste Netzwerkkarte wieder aktiviert und rebootet, Port-Weiterleitung geändert von .19 auf .18, ich komme aus dem Internet per SSH drauf.

 

[blurrrr]

Aber auch eher nur zum Lernen

Na dann... zum lernen: ubuntuusers.de - Netzwerkkarten bündeln

 

[Meikel_B]

Könntest auch ein bisschen mehr über die Infrastruktur erzählen (Netzwerk-Plan?), dann könnte man da ggf. auch besser ansetzen.

Auch wenn das Problem gelöst ist, der Vollständigkeit halber nachfolgend doch noch ein paar Worte zur Topologie bzw. zum Szenario.

Der Zeilrechner ist ein altes NAS (QNAP TS-269 Pro) auf dem ich das Betriebssystem durch Rocky Linux 8 ersetzt hatte, weil ich mich mit RHEL-basierenden Lösungen besser auskenne. Das NAS befindet sich in Frankreich in meinem Heimnetz und steht irgendwo unauffällig in der hintersten Ecke und ist normalerweise heruntergefahren. Es hängt hinter dem besagten von Orange bereitgestellten Router "Livebox". Ich kann es bei Bedarf per Wake-on-LAN aus dem Heimnetz aufwecken.

Ich will einen Workflow einrichten der es mir erlaubt, von Zeit zu Zeit per Hand (!!!) folgende Schritte aus meinem Heimnetzwerk in Frankreich ausführen:

• Aufwecken des NAS per Wake-on-LAN
• Remote Login auf meinem Heimserver im deutschen Heimnetz
• Von dort Kopieren der Daten aus dem deutschen Heimnetzwerk auf das NAS im französischen Heimnetzwerk (Datensicherung)
• NAS wieder bis zur nächsten Datensicherung herunterfahren
• Gelegentlich im NAS die Platte tauschen, damit die Sicherungen auf verschiedene Platten gehen