Die SSH-Verbindung kann nach erfolgreichem Austausch von Schlüsseln zu Ubuntu aus einigen Netzwerken nicht hergestellt werden

8

Nachdem ich von einem Land in ein anderes geflogen bin, kann ich jetzt nicht mehr auf mehrere meiner Digital Ocean Ubuntu-Server zugreifen. Ich kann mich jedoch weiterhin über Konsole und SSH von einer Box zur anderen anmelden (alle befinden sich im selben physischen Rechenzentrum).

Wenn Sie ssh mit -vvvv ausführen und den Befehl time damit ausführen, lautet die letzte Debug-Meldung:

debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Nach 1 Minute 37 Sekunden tritt eine Zeitüberschreitung auf.

Hier ist das Debug-Protokoll ab dem Punkt, an dem die SSH-Schlüsselauthentifizierung erfolgreich ist:

debug1: Authentication succeeded (publickey).
Authenticated to 128.199.170.168 ([128.199.170.168]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env MARKPATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env PS1
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env LOGNAME
debug3: Ignored env SCALA_HOME
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Die Verbindung ist nicht besonders langsam, meine Shell ist Bash (und ich kann mich immer noch über die Konsole und andere Netzwerk-SSH anmelden). Nichts scheint die SSH-Verbindung zu blockieren, da ich sehe, dass die Authentifizierung mit öffentlichem Schlüssel stattfindet.

Ich weiß nicht, welche Pipe geschrieben wird, die kaputt ist. FWIW Ich verbinde mich von OSX, hatte aber keine Probleme, bis ich in die USA flog.

Folgendes wird angezeigt auth.log, wenn Sie versuchen, sich anzumelden:

May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session opened for user root by (uid=0)
May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session closed for user root
May 17 12:28:02 db1 sshd[24955]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
May 17 12:28:04 db1 sshd[24955]: Accepted publickey for tomo from 24.210.28.151 port 63202 ssh2: DSA 3a:[redacted]
May 17 12:28:04 db1 sshd[24955]: pam_unix(sshd:session): session opened for user tomo by (uid=0)

Tcpdump-Erfassung des Verkehrs von Port 22 während eines Verbindungsversuchs:

    $ sudo tcpdump -i en0 port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:00:40.917870 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [S], seq 3430788632, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1286503697 ecr 0,sackOK,eol], length 0
19:00:41.211348 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [S.], seq 4135716624, ack 3430788633, win 28960, options [mss 1460,sackOK,TS val 898678531 ecr 1286503697,nop,wscale 8], length 0
19:00:41.211415 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1, win 4117, options [nop,nop,TS val 1286503989 ecr 898678531], length 0
19:00:41.215051 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1:22, ack 1, win 4117, options [nop,nop,TS val 1286503992 ecr 898678531], length 21
19:00:41.484824 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 22, win 114, options [nop,nop,TS val 898678606 ecr 1286503992], length 0
19:00:41.488532 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1:42, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 41
19:00:41.488616 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 42, win 4116, options [nop,nop,TS val 1286504260 ecr 898678609], length 0
19:00:41.490182 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], seq 22:1470, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 1448
19:00:41.490183 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1470:1614, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 144
19:00:41.491254 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], seq 42:1490, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 1448
19:00:41.592287 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1490, win 4096, options [nop,nop,TS val 1286504362 ecr 898678609], length 0
19:00:41.760341 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1490:1674, ack 22, win 114, options [nop,nop,TS val 898678676 ecr 1286504260], length 184
19:00:41.760401 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1674, win 4090, options [nop,nop,TS val 1286504527 ecr 898678676], length 0
19:00:41.762375 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1614, win 136, options [nop,nop,TS val 898678676 ecr 1286504261], length 0
19:00:41.762409 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1614:1638, ack 1674, win 4096, options [nop,nop,TS val 1286504529 ecr 898678676], length 24
19:00:42.027042 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1674:1826, ack 1638, win 136, options [nop,nop,TS val 898678743 ecr 1286504529], length 152
19:00:42.027103 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1826, win 4091, options [nop,nop,TS val 1286504789 ecr 898678743], length 0
19:00:42.028104 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1638:1782, ack 1826, win 4096, options [nop,nop,TS val 1286504790 ecr 898678743], length 144
19:00:42.300304 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1826:2546, ack 1782, win 148, options [nop,nop,TS val 898678812 ecr 1286504790], length 720
19:00:42.300357 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2546, win 4073, options [nop,nop,TS val 1286505053 ecr 898678812], length 0
19:00:42.302441 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1782:1798, ack 2546, win 4096, options [nop,nop,TS val 1286505055 ecr 898678812], length 16
19:00:42.600776 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1798, win 148, options [nop,nop,TS val 898678888 ecr 1286505055], length 0
19:00:42.600843 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1798:1850, ack 2546, win 4096, options [nop,nop,TS val 1286505349 ecr 898678888], length 52
19:00:42.857852 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 0
19:00:42.858552 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2546:2598, ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 52
19:00:42.858584 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2598, win 4094, options [nop,nop,TS val 1286505604 ecr 898678952], length 0
19:00:42.859131 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1850:1918, ack 2598, win 4096, options [nop,nop,TS val 1286505605 ecr 898678952], length 68
19:00:43.124310 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2598:2650, ack 1918, win 148, options [nop,nop,TS val 898679019 ecr 1286505605], length 52
19:00:43.124374 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2650, win 4094, options [nop,nop,TS val 1286505867 ecr 898679019], length 0
19:00:43.124473 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1918:2434, ack 2650, win 4096, options [nop,nop,TS val 1286505867 ecr 898679019], length 516
19:00:43.394690 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2650:2702, ack 2434, win 159, options [nop,nop,TS val 898679086 ecr 1286505867], length 52
19:00:43.394774 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2702, win 4094, options [nop,nop,TS val 1286506134 ecr 898679086], length 0
19:01:04.685580 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2434:2582, ack 2702, win 4096, options [nop,nop,TS val 1286527239 ecr 898679086], length 148
19:01:04.966270 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2702:2738, ack 2582, win 170, options [nop,nop,TS val 898684479 ecr 1286527239], length 36
19:01:04.966378 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2738, win 4094, options [nop,nop,TS val 1286527514 ecr 898684479], length 0
19:01:04.967018 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2582:2702, ack 2738, win 4096, options [nop,nop,TS val 1286527514 ecr 898684479], length 120
19:01:05.269214 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 2702, win 170, options [nop,nop,TS val 898684555 ecr 1286527514], length 0
19:01:06.027067 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2738:2790, ack 2702, win 170, options [nop,nop,TS val 898684744 ecr 1286527514], length 52
19:01:06.027144 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2790, win 4094, options [nop,nop,TS val 1286528563 ecr 898684744], length 0
19:01:06.027497 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286528563 ecr 898684744], length 460
19:01:06.603432 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286529135 ecr 898684744], length 460
19:01:07.552730 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286530077 ecr 898684744], length 460
19:01:09.250116 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286531762 ecr 898684744], length 460
19:01:12.442790 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286534930 ecr 898684744], length 460
19:01:18.634929 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286541067 ecr 898684744], length 460
19:01:24.068621 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286546451 ecr 898684744], length 460
19:01:34.714519 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286557019 ecr 898684744], length 460
19:01:45.384050 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286567587 ecr 898684744], length 460
19:01:56.051835 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286578155 ecr 898684744], length 460
19:02:06.715163 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286588723 ecr 898684744], length 460
19:02:17.355823 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286599291 ecr 898684744], length 460
19:02:28.042962 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286609859 ecr 898684744], length 460
19:02:38.690971 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [R.], seq 3162, ack 2790, win 4096, length 0

Einige andere Dinge, die ich versucht habe:

  • Das Reduzieren von MTU auf dem Server könnte ein Fehler in pmtu: sudo ip link set mtu 1280 dev eth0 sein
  • Reduzieren von MTU auf 1280 in OS X für meine WLAN-Schnittstelle
  • Reduzieren Sie ServerAliveInterval noch weiter auf 30, wenn die Verbindung immer noch unterbrochen wird, jedoch nicht mit einem Rohrbruch
  • Ausführen von ssh mit "cat" anstelle von "bash" oder "bash", jedoch ohne geladenes Profil / rc
  • Einstellen der IP-Adresse der OS X-WLAN-Schnittstelle manuell anstelle von DHCP
ssh Tomo Huynh
quelle
Offensichtliche Erklärungen sind defektes NAT, defekte Firewall und defekte PMTU-Erkennung. Welcher von ihnen es ist, würde wahrscheinlich durch eine Paketverfolgung aufgedeckt werden.
Kasperd
1
Eine MTU von 1480 ist nicht niedrig genug, um PMTU-Erkennungsprobleme auszuschließen. Auch wenn Sie das angekündigte MSS in beide Richtungen ändern können, ist das Reduzieren des MSS ein besserer Ansatz als das Ändern der MTU. Ein MSS von 1220 funktioniert fast immer. Wenn die Verbindung hängt, stellen Sie sicher, dass der OS X-Computer noch über die IP-Adresse verfügt, mit der die Verbindung hergestellt wurde. Ich habe gesehen, dass OS X in einigen Netzwerken zuerst die zuvor verwendete IP-Adresse aktualisiert und dann zwei Minuten später den DHCP-Server nach einer anderen IP-Adresse fragt.
Kasperd
Es wäre immer noch eine gute Idee, sich eine Paketerfassung anzusehen.
Kasperd
Ich habe versucht, die MTU auf beiden Seiten auf 1280 zu reduzieren, ohne Ergebnisse zu erzielen. Ich habe die Ausgabe auth.log angehängt, die zeigt, dass die Authentifizierung erfolgreich ist.
Tomo Huynh
Ich bin immer noch auf der Suche nach einer Paketerfassung.
Kasperd

Antworten:

9

In der Paketverfolgung sehen wir, dass Pakete mit maximaler Größe zu Beginn des Flusses in beide Richtungen ausgetauscht werden. Das hat keine Probleme verursacht, daher deutet nichts auf ein MTU-Problem hin.

Später während der Verbindung sehen wir, dass ein Paket vom Client zum Server mit den relativen Sequenznummern 2702: 3162 niemals eine ACK vom Server empfängt.

Mein unmittelbarer Gedanke ist, dass dieser Paketverlust durch eine fehlerhafte Middlebox (dh NAT, Firewall oder ähnliches) verursacht wird.

Ich habe über NAT-Boxen gesprochen, die während einer TCP-Verbindung keine Änderung der Nutzungsbedingungen verarbeiten können. Das Problem tritt in Ihrem Fall auf, nachdem der Client angibt, dass die Nutzungsbedingungen geändert wurden. Da tcpdump die Nutzungsbedingungen jedoch nicht anzeigt, kann ich nicht sicher sagen, ob dies genau der Punkt ist, an dem das Problem auftritt.

Für einen Test können Sie versuchen, -o ProxyCommand='nc %h %p'so zu verwenden, dass der ssh-Client die TCP-Verbindung nicht direkt steuert. Sie können die IPQoSOption auch ausprobieren . Wenn die Änderung der Nutzungsbedingungen das Problem ist, kann die Angabe -o IPQoS=cs0oder Funktion -o IPQoS=0funktionieren, aber jede andere Einstellung schlägt fehl. Dies liegt daran, dass ssh während der Authentifizierung 0 als QoS verwendet und nach der Authentifizierung zur ausgewählten QoS wechselt. Wenn Sie QoS auf 0 setzen, ändert sich der QoS-Wert nicht, um Middleboxes zu verwirren.

Kasperd
quelle
Vielen Dank, @kasperd. Die Verbindung mit "-o ProxyCommand = 'nc% h% p'" funktioniert (als Problemumgehung).
Tomo Huynh
1
@TomoHuynh Schön, dass dies ProxyCommandeine funktionale Problemumgehung ist. Ich habe IPQoSmir die Option etwas genauer angesehen und meine Antwort mit einer möglichen Einstellung für die IPQoSOption aktualisiert , von der ich denke, dass sie für Sie funktionieren wird. Wenn das Ändern IPQoSauch für Sie funktioniert, ist dies eine bessere Lösung für dieses Szenario als ProxyCommand.
Kasperd
2

Falls jemand anderes darauf stößt, hatte ich ein ähnliches Problem mit einem TP-Link Archer VR2600-Router / Modem (mit Firmware 1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n).

Das Ausführen mit -o IPQoS=0, wie von @kasperd vorgeschlagen, funktionierte und schlug ein QoS-Problem mit meinem Router vor. Ich habe das nächste aktiviert, was ich in den Router-Einstellungen finden konnte ( Erweitert → Bandbreitensteuerung) Einstellung der maximalen Bandbreite direkt unter dem, was in meiner Leitung verfügbar ist), unter der Annahme, dass der Router in diesem Fall möglicherweise auf die entsprechenden Flags achtet.

Dies schien zu funktionieren und meine Verbindungen kommen jetzt durch. Durch Umschalten dieser Option wird zuverlässig gesteuert, ob ich durchkommen kann.

Sam Mason
quelle
hey @ sam-mason, hast du jemals eine dauerhaftere Lösung gefunden? Ich habe genau das gleiche Modem. Im Moment verwende ich die Problemumgehung "ProxyCommand". Dies ist frustrierend, da dies kein wirklich billiger Router ist.
Leonardoborges
0

Haben Sie einen Benutzer ssh config (~ / .ssh / config)?

Wenn nicht, erstellen Sie eine und fügen Sie die folgenden Zeilen hinzu:

ServerAliveInterval 120 #ping the server every 120s
TCPKeepAlive no #do not set SO_KEEPALIVE on socket
Sclarson
quelle
Ich habe eine SSH-Konfiguration und sie hatte bereits die Einstellung ServerAliveInterval. Ich habe die TCPKeepAlive-Einstellung hinzugefügt (und festgestellt, dass der ssh-Client keine Kommentare in derselben Zeile akzeptiert, also habe ich sie entfernt), ohne Erfolg. Ich möchte klarstellen, dass es kein Problem ist, eine normale Verbindung herzustellen und nach Inaktivität eine Zeitüberschreitung zu erzielen. Das Problem ist, dass die Verbindung fast hergestellt ist, mich aber am Ende nicht wirklich in eine Shell startet.
Tomo Huynh
Haben Sie Zugriff auf das Authentifizierungsprotokoll oder die SSHD-Protokollierung auf dem Remote-System? Auch wie oben erwähnt, ist 1480 nicht niedrig genug, um ein MTU-Problem auszuschließen.
Sclarson
Ja, auth.log zeigt mir, wie ich mich anmelde. Ich habe versucht, die MTU ebenfalls auf 1280 zu senken.
Tomo Huynh
0

Ich habe auch einen TP-Link-Router (C9). Die direkte Verbindung von meinem Laptop zu meinem (Internet-) Server funktioniert manchmal nicht oder hängt nicht, aber wenn ich eine Verbindung zu einem anderen Server im selben Netzwerk herstelle, in dem sich mein Laptop befindet, habe ich keine Probleme. Der Laptop ist immer über WLAN, meinen internen Server, direkt mit dem Router verbunden.

Leider hat -o IPQoS = 0 und -o ProxyCommand = 'nc% h% p' nicht geholfen.

Also habe ich mir meine Router-Einstellungen angesehen und "NAT Boost" und Viola deaktiviert. Es funktionierte perfekt mit direkten Verbindungen. Um zu überprüfen, ob es wirklich diese Einstellung war, habe ich sie wieder aktiviert und: funktioniert immer noch :-(

Ich vermute, dass der Neustart des Routers das Problem für mich "behoben" hat. Bisher läuft es 3 Tage und hatte nach wie vor keine Probleme beim Verbinden oder Aufhängen von Verbindungen.

Ich habe jetzt ein Skript, das die Verbindung ständig testet, und werde meine Ergebnisse aktualisieren, wenn ich die Probleme erneut habe. Vielleicht möchten Sie testen, ob Ihnen auch ein einfacher Neustart des Routers hilft.

Malasa
quelle
0

Leider habe ich hier nicht genug Ruf, um über Sam Masons Antwort oben abzustimmen oder sie zu kommentieren, aber ich möchte nur öffentlich +1, was er gesagt hat. Ich habe auch einen VR2600 und ich hatte auch die gleiche Erfahrung:

  1. Die Verbindung (ssh, sftp usw.) wird hergestellt, scheint dann aber nur zu hängen
  2. tshark zeigt TCP Spurious Retransmits
  3. Das Setzen von -o IPQoS = 0 (für sich allein) auf der Clientseite hat nichts bewirkt
  4. Das Aktivieren der Einstellung Erweitert-> Bandbreitensteuerung auf dem Router (zuvor deaktiviert) mit den höchstmöglichen Grenzwerten (= effektiv unbegrenzt) scheint den Router so zu reparieren, dass das IPQoS-Flag berücksichtigt wird
  5. tshark zeigt keine TCP Spurious Retransmits mehr an und die Verbindung hängt nicht mehr (ssh-, sftp- usw. Clients funktionieren jetzt mit einem Server hinter dem VR2600-Router).

Es scheint auf einen signifikanten Fehler im VR2600-Router hinzudeuten. Leider (zum Zeitpunkt des Schreibens) bin ich auf der neuesten Firmware (1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n, genau wie Sam), und dieser Router scheint nicht mit DD-WRT kompatibel zu sein / mit DD-WRT getestet zu sein .

Um das oben Gesagte zu ergänzen, werde ich jedoch auch sagen:

  1. Nachdem ich die Schritte 1 bis 5 ausgeführt habe, kann ich jetzt auch ohne Angabe von "-o IPQoS = 0" eine erfolgreiche Verbindung herstellen.

Mit anderen Worten:

Das bloße Aktivieren der Option Erweitert-> Bandbreitensteuerung in den Router-Optionen (auch bei maximal hoher Obergrenze) scheint ausreichend zu sein, damit sich das NAT des Routers wie erwartet verhält. Wenn die Bandbreitensteuerung deaktiviert ist, tritt das im OP (und ausführlich von @malasa) beschriebene Problem auf.

Unklar, ob das Mittel darin besteht, diese Option einfach zu aktivieren, oder ob Sie mindestens einmal eine Verbindung mit der Option -o hergestellt haben müssen. In jedem Fall kann ich bestätigen, dass nach Aktivierung dieser Option, wenn ich dann diese Option Erweitert-> Bandbreitensteuerung deaktiviere , mein ssh / sftp / etc wie zuvor beschädigt ist. Wenn ich diese Option Erweitert-> Bandbreitensteuerung aktiviere , scheint alles wieder wie erwartet zu funktionieren. Und (nachdem diese Option aktiviert wurde) scheint auch bei Neustarts des Routers alles einwandfrei zu funktionieren.

Aus meiner Sicht ist es also eine ziemlich gute Problemumgehung / Korrektur, die keine clientseitigen Änderungen oder Wartungsarbeiten erfordert (um die Bedenken von @leonardoborges zu beantworten).

Dave Hooper
quelle