Answer the question
In order to leave comments, you need to log in
What are the proper ways to prevent SSH tunnels from dropping?
Hello Khabrovites. I am writing here in the hope of hearing really experienced people in system administration.
The situation is as follows - we have a lot of client PCs, almost all of them behind NATs. To bypass this, a classic scheme is used with remote forwarding of ports through a "white" server, after which these ports are written to the school base with auxiliary scripts, tied with local naming for further gestures. But that's not the point. Everything works flawlessly, but there's no way I can defeat the "blank" of the tunnels.
From what I was able to find out - if a certain thing does not go through the tunnel (it is not known for sure which one)time signal, then this connection becomes "hanging", but at the same time everything is active. I have indeed encountered this and continue to encounter it all over the place. I tried to deduce at least an approximate pattern for tunnel uptimes, client internet speeds, etc., but it does NOT exist (God, I really did this for a long time) .
And no, I was not banned in Google, but the problem is that under Windows there are no obvious ways to deal with this (like autossh in linux, for example) ... Well, either I didn’t find them
Client devices work under Windows, for forwarding, I use plink , which, as it turned out, does not have such a parameter as KeepAlive in principle, unlike the same PuTTY. In the back of the old forums, I came across a utility like MyEnTunnel . It operates with the same plink, but in addition to the port we need, it can forward the so-called. control port on which she drives packets (loopback pinging) . But here problems emerge - there are n * 2 ports, which is absolutely unacceptable for me, and the second one is a little more trivial - I absolutely do not understand how, by driving packets on another port, it will save ours from "sagging".
As a result, I am in despair and see only two options, and all of them with colossal compromises - the first is to load the saved profiles stored in the registry into plink with crutches, overwriting EVERY time the actual data for forwarding to this very registry (you can save everything in them settings, including KeepAlive), in the hope that this will help me at all.
Or reset the connection every +- half an hour and create a new one, thereby a DDOS server and provide for the possibility that a really active connection will be reset, which also does not fit the word at all.
I understand, a lot of words and confusion, but I hope that knowledgeable people understand the essence of the problem and clarify the available solutions to me
Answer the question
In order to leave comments, you need to log in
The options are - on Windows for a long time there is an openssh client that is able to keep alive. Maybe you should try it instead of putty & co?
And have you tried the method described here? https://stackoverflow.com/a/53175117
Some adaptation of the script may be required for Windows
I didn’t quite understand how all this works for you, but offhand, when raising an ssh connection using plink, also create fake port forwarding through the appropriate command line parameter and somehow periodically try to use it, at least the simplest one called from the scheduler a team like
echo | telnet localhost PORT
As a whim, the idea arose to limit KeepAlive on the server.
If I understand everything correctly, then if I put, conditionally:
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 0
kepalive windows , and for automation see the session parameters.
Yes, and most likely it can be written in the putty config, it's just a port from Linux,
Ps
At work win8, putty does not fall off by timeout, so most likely nat cuts tcp by timeout, you can get around just one ping every 30 seconds, maybe you will have to increase the size of the ping packet so that tcp considers it a data packet
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question