Was meinst du mit "Reverse" -Tunnel?
Der Parameter -R bezieht sich auf einen ferngesteuerten Tunnel und nicht auf den Parameter -L, der sich auf einen lokal initiierten Tunnel bezieht.
Aus Sicht des SSH-Clients wird der Parameter -R daher auf der Gegenseite (dh dem SSH-Server) auf Datenverkehr überwacht. Wenn der Computer, auf dem der SSH-Server ausgeführt wird, Datenverkehr an dem angegebenen Port (1122) empfängt, sendet dieser Computer diese Informationen über die SSH-Software. Insbesondere werden diese Informationen durch den SSH-Tunnel gesendet. Wenn die Informationen durch den SSH-Tunnel gesendet werden, werden sie wie der gesamte SSH-Verkehr verschlüsselt. Zu dieser Information wird auch eine kleine Anmerkung hinzugefügt, die (umschrieben hier um zu sagen) "den Verkehr an den localhost-Port 5000 senden".
Wenn der Datenverkehr am anderen Ende des SSH-Tunnels (in diesem Beispiel sprechen wir jetzt von dem Computer, auf dem der SSH-Client ausgeführt wird) den Datenverkehr empfängt, wird der Hinweis angezeigt, wohin der Datenverkehr gehen soll. Dann erreicht der Computer den localhost-Port 5000. Dies ist der Zeitpunkt, zu dem der Hostname von "localhost" aufgelöst wird. In diesem Beispiel verweist "localhost" auf den SSH-Client. (Wenn Sie dagegen stattdessen -L verwenden, wird die Verwendung von "localhost" vom endempfangenden Datenverkehr über den Tunnel dennoch interpretiert, sodass der Ausdruck "localhost" vom SSH-Server interpretiert wird.)
Nun ist es am besten, herauszufinden, warum der Tunnel ständig zusammenbricht. Ich habe in der Regel -L (lokale) Tunnel verwendet, aber ich habe sie viele Tage ignoriert, bevor (manchmal) entschieden wurde, einen zu verwenden, und es funktioniert gut. Ich würde davon ausgehen, dass der Tunnel an beiden Enden zusammengebrochen sein könnte. Überprüfen Sie beide Seiten auf Protokolle. Unter Umständen möchten Sie die OpenSSH-Dokumentation überprüfen, um zu sehen, ob es sich um eine Art Zeitüberschreitung handelt.
Wenn Sie den nicht bevorzugten Weg gehen wollen, das Problem zu umgehen (anstatt es zu beheben), indem Sie die sshd beenden und neu starten, könnten Sie dies tun. Wie bereits erwähnt, möchten Sie nicht verwenden, killall sshdda möglicherweise eine andere sshd-Verbindung besteht. Sie können versuchen pkill, alle Programme zu entfernen, die eine Verbindung zu 203.0.113.10 (oder ist es 10.34.23.12?) Oder die Portnummer (1122) herstellen, aber dies wiederum kann zu Fehlalarmen führen. Sie haben eine sicherere Möglichkeit, das Problem zu umgehen. Es geht sogar um den gleichen Ansatz, den Server neu zu starten.
Möglicherweise lässt sshd eine benutzerdefinierte Konfigurationsdatei ( -f configuration file) verwenden, oder Sie können Konfigurationsinformationen in der Befehlszeile angeben (using -o). z.B:
sshd -o PidFile /var/run/sshd-remPC-tunnel.pid
(Außerdem würden Sie Ihre anderen gewünschten Optionen in diese Befehlszeile aufnehmen.)
Dadurch wird die Prozess-ID-Nummer in diese Datei eingefügt, wenn Sie sshd starten. Dann kannst du:
kill $( cat /var/run/sshd-remPC-tunnel.pid )
(Hinweis: Möglicherweise müssen Sie mit Berechtigungen umgehen. Ich kümmere mich sehr absichtlich nicht darum, um meine Antwort einfach zu halten. Stellen Sie sicher, sshddass Sie die Datei erstellen können, und Sie können sie erfolgreich ausführen, catwenn Sie möchten kill. Führen Sie Tests und aus Nehmen Sie die gewünschten Änderungen vor.)
Hinweis: Möglicherweise möchten Sie den Tunnel NICHT alle 5 Minuten automatisch neu starten (um das Problem zu beheben). Denn wenn Sie eine erfolgreiche Verbindung haben, würde dies die erfolgreiche Verbindung unterbrechen. Ich kann mir vorstellen, dass dies etwas sein sollte, das manuell gemacht werden sollte.