Ponowne łączenie tunelu SSH SOCKS za pomocą autossh
Używaj autossh z kontrolami żywotności SSH i pamiętaj, że ponowne połączenie tunelu nie przywraca starych połączeń aplikacji.
Proxy SSH SOCKS znika, gdy jego połączenie SSH się kończy. Nadzorca może ponownie uruchomić to połączenie, ale nie może wznowić każdego żądania witryny, które korzystało ze starego strumienia.
Dla już działającej konfiguracji SSH autossh może nadzorować przekazywanie dynamiczne, podczas gdy OpenSSH wykrywa serwer, który nie odpowiada:
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]-M 0 wyłącza osobny mechanizm portu monitorowania autossh. Polega on na zakończeniu SSH, aby nadzorca mógł zareagować. Opcje server-alive dają kontrolę żywotności na poziomie SSH; nie żądają strony od każdego miejsca docelowego, którego używasz.
Utrzymuj początkową konfigurację widoczną, dopóki uwierzytelnianie i przekazywanie nie zaczną działać. Zachowanie autossh w tle różni się od -f zwykłego SSH: uruchomienie bez nadzoru nie może się zatrzymać, aby zapytać o hasło lub frazę klucza. Jego udokumentowana brama startowa pozwala też odróżnić natychmiastowy błąd konfiguracji od później zerwanej sesji.
Po ponownym połączeniu lokalny nasłuchiwacz może znów być dostępny. Aplikacje mogą jednak nadal musieć ponowić własne nieudane operacje. Przesyłanie przerwane przed otrzymaniem odpowiedzi ma wynik na poziomie aplikacji do rozwiązania, a nie tylko brakujący tunel do ponownego uruchomienia.
Wreszcie zdrowy transport SSH nie dowodzi, że brama dotrze do konkretnej witryny. Oddziel nadzór nad tunelem od monitorowania zadania, które go używa.