SSH Verbindung nicht möglich über FB

[EarMaster]

Ich habe folgendes Problem, dass sich mir nicht so ganz erschließen will. Ich habe einen Intel NUC mit Proxmox ausgestattet und lasse darauf diverse Dienste laufen. Wenn ich den NUC am selben Switch angeschlossen habe, wie meinen Rechner an dem ich gerade sitze, dann ist es problemlos möglich sowohl direkt über die Shell als auch über das Webinterface mit SSH auf den NUC zuzugreifen. Sobald ich den NUC allerdings innerhalb des Netzwerkes (also kein Internet, VPN-Tunnel oder sonst was im Spiel) an seinen (eigentlichen) Platz neben der FritzBox im Keller stecke, dann ist keine Verbindung mehr möglich. Ich habe an der FritzBox auch schon unterschiedliche Ports ausprobiert, aber die Funktion Gast LAN ist im Interface deaktiviert und es macht auch keinen Unterschied. Die Dienste auf dem NUC sind jederzeit erreichbar und funktionieren auch. Ich erreiche auch das Proxmox Interface, kann jedoch keine Shells öffnen oder per SSH auf den NUC zugreifen.

Hat jemand eine Idee, die mir bisher entgangen ist? Ich bin relativ neu in der Fritz Welt, kenne mich aber was Netzwerktechnik angeht relativ gut aus. Ich hatte meine letzte Fritzbox Ende der 90er im Einsatz und bin jetzt wieder zurück gewechselt, daher bin ich mit den genauen Details von FritzOS nicht so ganz vertraut.

 

[pompom]

Hast du schon mal den NUC an den Repeater angeschlossen? nur mal um das Problem einzugrenzen?

 

[Barungar]

Es ist auf jeden Fall erst einmal ein kurioses Szenario. Sowohl die FritzBox als auch der FritzRepeater sollten hier nur als ISO/OSI Layer 2-Geräte in Aktion treten.

Der Vorschlag von pompom, den NUC mal an den zweiten LAN-Port des FritzRepeaters zu hängen wäre ein erster, möglicher Schritt.
Meine Vermutung wäre da eher die "Funkstrecke", aus Deiner Skizze entnehme ich, dass Du zwischen dem "kleinen LAN" des Netgear-Switches und der FritzBox eine "Funkstrecke" hast.

Der FritzRepeater läuft im Modus "WLAN-Brücke", richtig?

Funktioniert denn noch ein PING vom PC zum NUC, wenn der NUC an der FritzBox hängt? Ich hatte es so verstanden, dass SSH nicht mehr geht. Trifft es ab dem Moment, wo der NUC an der FritzBox hängt, auch die Web-Zugriffe?

Die IP(v4) des NUC bleibt unverändert durch den Umzug (vom Netgear Switch zur FritzBox)?

Je nachdem wie "firm" Du noch mit Netzwerktechnik bist, würde es sich ggf. auch anbieten von der FritzBox mal einen Paketmitschnitt des LAN-Ports machen zu lassen an dem der NUC hängt. Den könntest Du dann am PC mit Wireshark im Anschluss auslesen. Dann würde man ggf. sehen, ob die SSH-Anfragen vom PC überhaupt am FritzBox LAN-Port zum NUC ankommen, oder ob sie vorher schon "untergehen".

Eine andere "wilde" Idee, die mir noch einfällt wäre eventuell etwas mit den MAC-Forwarding Tabellen beim Netgear bzw. dem FritzRepeater. Auch, wenn es blöde klingt, hast Du mal versucht nach dem Umzug des NUC (vom NetGear zur FritzBox) den Netgear Switch und den FritzRepeater mal neuzustarten bevor Du testest?

Ich hatte mal ein ähnliches Phänomen in Verbindung mit einer LAN-WLAN-LAN-Strecke, da hatten die Cisco Switches zusammen mit LANCOM AccessPoints auch so eine kleine Schwierigkeit, wenn das Gerät vom "linken LAN" ins "rechte LAN" gewechselt ist. Da gab es 300 Sekunden Timer auf den MAC Forwarding Tabellen, die sich nicht immer 100%ig korrekt aktualisiert haben.

 

[blurrrr]

Sowas ist mir bisher eigentlich primär untergekommen, wenn irgendein Blödsinn mit der ARP-Tabelle war. Kannste unter der (adminstrativen) Eingabeaufforderung mittels "arp -a" prüfen, ob die Zuordnungen auch korrekt sind. Eventuell auch mal die ARP-Tabelle löschen ("arp -d") und dann den PVE-Host nochmal ansprechen.

Faktisch dürfte aber wohl das hier...

Paketmitschnitt

... das zielführenste sein (da muss dann auch nicht mehr geraten werden)

 

[EarMaster]

Danke erstmal für die hilfreichen Antworten.

Paketmitschnitt(e), ARP Tabelle und Umstecken an den Repeater werde ich heute Abend testen, wenn ich etwas mehr Zeit dazu hatte.

Zunächst noch ein paar Antworten auf Fragen: der NUC bekommt von der FritzBox immer die gleiche IP zugewiesen. Da gibt es auch keine Probleme soweit ich das feststellen kann.

Ping klappt in beiden Fällen, das Webinterface ist auch in beiden Fällen erreichbar. Das Problem ist (soweit ich es erlebt habe) begrenzt auf SSH (auf Standard Port 22 (könnte ich mal testweise ändern...)).

Der Netgear Switch ist ein einfacher 5 Port unmanaged Switch. Ich habe ihn hier lediglich erwähnt, weil er die einzige Variante ist, in der es nicht zu dem Fehler kommt.

Ihr habt das richtig interpretiert, dass zwischen FritzBox und FritzRepeater eine Funkstrecke liegt. Der Repeater wird im Meshmodus betrieben. Mein PC ist ebenfalls über diese Funkstrecke verbunden und hat zumindest keine Probleme mit SSH Verbindungen nach draußen zu diversen Webservern. Ich denke also nicht, dass es an der Zuverlässigkeit der W-LAN-Verbindung scheitert.

 

[blurrrr]

Das Problem ist (soweit ich es erlebt habe) begrenzt auf SSH

Dann vergiss das mit der ARP-Tabelle direkt wieder, das wäre nur von Relevanz gewesen, wenn ein Ping auch nicht funktioniert hätte Was bleibt wäre dann der Paketmitschnitt (mitunter auch bei allen 3 beteiligten Akteuren - Client - Fritzbox - PVE). Was den PVE-Host angeht, ich hatte mal hier etwas dazu geschrieben, wie es mit dem Remote-Mitschnitt funktioniert, das mit der sudoers-Datei kannst Du Dir aber sparen, da beim PVE-Host ja per default der root-Login aktiviert ist.

 

[EarMaster]

Also das Problem besteht auch, wenn der NUC an dem Repeater hängt, also vor der Funkstrecke. Ich habe euch mal drei Auszüge aus Wireshark angehängt. Ich habe die Auszüge gefiltert, so dass nur die Pakete, die an oder von der Zieladresse kommen drin stehen. Ich habe jeweils das folgende Kommando laufen lassen (home-alone ist der Name der Maschine):

ping -n 4 home-alone && ssh home-alone

Die ersten beiden Versuche (00 = NUC hängt an der FritzBox, 01 = NUC hängt am Repeater) schlugen mit einem Timeout fehl, der letzte Versuch (03 = NUC hängt am selben Switch wie mein Rechner) war erfolgreich. Was man jedoch sieht ist, dass die Verbindung offensichtlich zustande kommt und auch Daten (der Schlüssel) übertragen wird. Dann wird die Verbindung jedoch beendet. Ich werde jetzt mal noch das Netzwerkkabel zwischen Switch und Repeater prüfen. Das ist relativ lang und hat auch schon viel erlebt. Nicht das da der Wurm drin ist.

 

[Barungar]

Was mir sofort an den Wireshark-Captures aufgefallen ist, ist das sich die MAC-Adresse ändert!
Der Repeater macht irgendwas mit der MAC des NUC.

In der Datei 02 "reden" (30:85:a9:40:71:46) und (94:c6:91:a1:f2:2b) miteinander.
In den Dateien 01 und 00 sendet (30:85:a9:40:71:46) an (94:c6:91:a1:f2:2b), aber es antwortet immer (0c:72:74:be:3d:db).

Was läuft da? Ich kenne das Verhalten von Routing, aber eigentlich sollten da keine Routingoperationen laufen.
Warum ersetzt der Repeater die MAC des NUC durch eine andere?

 

[EarMaster]

Wie es dazu kommt kann ich nicht sagen, aber die MAC Adresse gehört der WLAN Schnittstelle der FritzBox (nicht die des Repeaters).

 

[Barungar]

Das ist sehr interessant... das würde dann doch bedeuten, dass in beiden Fällen (NUC am Repeater und NUC an FritzBox) scheinbar die Daten doch über die Funkstrecke laufen und dabei am WLAN-Interface der FritzBox etwas mit den Daten-Paket auf ISO/OIS-Layer 2 (MAC-Maskierung) erfolgt. Aber warum diese "Umschreibung" der MAC... wie gesagt, ich arbeite in der Praxis nicht mit AVM LAN-WLAN-LAN Kopplungen.

 

[Becker2020]

Ich würde die Fritzbox + Repeater mal neu starten. Manche Fehler verschwinden nach einen Neustart.

 

[EarMaster]

Neustart habe ich gestern Abend gemacht, als ich den NUC durch die Gegend getragen habe.

 

[Spielebernd]

Wie ist den das Verhalten wenn NUC und PC an der FB direkt hängen und dann weiter wenn der NUC an der FB und der PC am Repeater direkt hängen ohne Switch?

Wie rufst du den NUC über SSH auf über seine IP oder DNS eventuell sogar über extern? Hatte am Anfang irgendwas mit Ports gelesen

 

[Tommes]

Nur so eine Idee, aber ich vermute, das sich die MAC-Adresse deshalb ändert, weil an der FRITZ!Box 5590 eine reine LAN-Verbindung zum NUC stattfindet, der FRITZ!Repeater 3000 jedoch über eine WLAN-Brücke arbeitet und sich dann erst per LAN mit dem NUC verbindet. Vermutlich erhält der NUC deshalb zwei unterschiedliche MAC-Adressen, eine für's WLAN und eine für's LAN, da das Routing ja in beiden Fällen von der 5590 aus geht.

 

[EarMaster]

Wie rufst du den NUC über SSH auf über seine IP oder DNS eventuell sogar über extern? Hatte am Anfang irgendwas mit Ports gelesen

Ich rufe den NUC über seinen internen Hostnamen auf (der von der FritzBox aufgelöst wird). Ich kann aber auch die IP Adresse verwenden. Das ändert nichts.

Den PC direkt an die FB hängen ist schwierig da sind zwei Stockwerke dazwischen.

 

[Spielebernd]

Den PC direkt an die FB hängen ist schwierig da sind zwei Stockwerke dazwischen.

Kann ich gut verstehen um das ganze aber weiter einzugrenzen wirst du meiner Einschätzung nach nicht wirklich drumherum kommen.

Mir ist auch nicht bekannt das die FRITZ Produkte im im Heimnetz irgendwas blocken.

 

[EarMaster]

Wenn beide direkt an der FritzBox hängen klappt die Verbindung ebenfalls nicht. Beide am Repeater hatte ich bereits Anfang der Woche getestet. Gleiches Ergebnis.

 

[Barungar]

Interessant wäre, ob es auch nur an der FritzBox zu diesem "seltsamen MAC-Swap" kommt, den ich bisher mutmaßlich der Funkstrecke zugeordnet hatte. Insgesamt ist es allerdings sehr, sehr kurios und für mich auch unerklärlich, wieso zwei Geräte die direkt an der FritzBox hängen solche Probleme haben. Die FritzBox sollte in so einem Fall einfach nur ein kleiner "unmanaged Switch" sein.

 

[Spielebernd]

Hm ich würde hier nicht von Ursache in deinem Netzwerk ausgehen (außer z.B. Gastprofil oder unterschiedliche IP-Adressen was du sicher schon gecheckt hast).

 

[blurrrr]

Vielleicht mal einen Werksreset der Fritzbox durchführen... schlussendlich ist es halt, wie @Barungar es schon sagte: Die Fritzbox sollte in so einem Szenario einfach nur wie ein dummer Switch agieren. Das tut sie ja anscheinen derzeit nicht mehr (wie gewünscht), der Netgear-Switch hingegen scheint sich ja so zu verhalten, wie er soll - dort funktioniert nach Deiner Aussage ja auch alles problemlos.