Ich versuche, von einem Linux-Ubuntu-Clientcomputer aus über SSH auf einen Linux-Ubuntu-Server zuzugreifen.
Wenn sich Client und Server im selben Netzwerk befinden, funktioniert alles einwandfrei. Wenn ich versuche, per VPN – OpenVPN remote auf den Server zuzugreifen, werden Vollbildanwendungen wie MC-Midnight Commander nicht richtig angezeigt. Dies bedeutet, dass ich nur das Zeichen in der oberen rechten Ecke des angezeigten Bildschirms sehe und die Tastaturinteraktion anscheinend nicht funktioniert.
Außerdem lässt der für eine einfache Textdatei ausgeführte Cat-Befehl das Terminal hängen, ohne eine Ausgabe anzuzeigen.
Seltsamerweise funktioniert alles problemlos, wenn ich von meinem Android-Telefon aus über VPN mit einem Android OpenVPN-Client und einem Android SSH-Client auf denselben Server zugreife.
Auf meinem Ubuntu-Client-Rechner ist die Umgebungsvariable TERM auf „xterm-256color“ eingestellt, auf meinem Android-Telefon auf „linux“. Der Versuch, sie auf meinem Ubuntu-Client vor dem Starten der SSH-Sitzung auf „linux“ einzustellen, funktioniert, d. h. innerhalb der SSH-Sitzung sehe ich, dass das Terminal tatsächlich auf „linux“ eingestellt ist, aber es hat keine Auswirkung.
Auf dem Ubuntu-Client habe ich auch versucht, eine Verbindung über Putty herzustellen, aber das Ergebnis ist das gleiche.
Irgendeine Ahnung, warum das passiert?
Dank im Voraus!
Antwort1
Nun, ich habe die Lösung hierfür schließlich im OpenVPN-Handbuch gefunden, das sich hier befindet:
https://openvpn.net/community-resources/referenzhandbuch-fur-openvpn-2-4/
Das Problem hing offenbar damit zusammen, dass die Pfad-MTU-Erkennung nicht ordnungsgemäß funktionierte.
„Sowohl --fragment als auch --mssfix sind dafür gedacht, Fälle zu umgehen, in denen die Path-MTU-Erkennung auf dem Netzwerkpfad zwischen OpenVPN-Peers unterbrochen ist.
Das übliche Symptom eines solchen Ausfalls ist eine OpenVPN-Verbindung, die erfolgreich gestartet wird, dann aber während der aktiven Nutzung ins Stocken gerät. Wenn --fragment und --mssfix zusammen verwendet werden, übernimmt --mssfix seinen Standard-Max-Parameter von der --fragment-Max-Option.
Daher könnte man die maximale UDP-Paketgröße mit den folgenden Optionen auf 1300 senken (ein guter erster Versuch zur Lösung von MTU-bezogenen Verbindungsproblemen):
--tun-mtu 1500 --fragment 1300 --mssfix "
Das Hinzufügen dieser beiden Optionen sowohl auf der Server- als auch auf der Clientseite hat das Problem für mich gelöst.
Ich hoffe das hilft.