W
W
Winseven2021-03-31 12:55:17
Computer networks
Winseven, 2021-03-31 12:55:17

The provider cuts TCP / UDP sessions after 240 seconds of inactivity, what should I do?

Good afternoon!
The situation is this: I connect to the server via SSH and if nothing is done, then after 240 seconds the connection hangs, although the status is "ESTABLISHED" on both sides. If you activate the "Dedicated IP" service, then there is no such problem. I believe that the provider's NAT clears the NAT table of inactive connections after 240 seconds, hence the loss of communication. The provider's technical support does not think so, and answers:
- Your request has been processed, it was recommended to change the keepalive interval in the client's ssh settings.
- From our side at the moment we do not see any restrictions.

For the second month I have been trying to find the truth - where my TCP / UDP sessions are lost ... I even recorded a video using NetCat as an example - https://youtu.be/k4B77s4detk

In my opinion, this is a violation of "RFC793 Forward Control Protocol - TCP", if there was no FIN packet, then the session should be active.
Checked through the mobile Internet - there are no problems with the loss of communication.
Maybe someone has experience in solving this problem, except how to activate the "Dedicated IP" service, use a VPN, or write "keepalive interval" everywhere?

Answer the question

In order to leave comments, you need to log in

5 answer(s)
V
Vladimir Dubrovin, 2021-03-31
@z3apa3a

There is always a timeout in any NAT / PAT table, otherwise if both ends of the connection fell off due to network problems or due to a reboot or poorly configured firewalls, the entry would remain in the table forever. In UDP, there is generally no mechanism for removing an entry from NAT / PAT, except for a timeout.
On the one hand, your provider is right - in any case, when working through NAT / PAT, you need to configure TCP KEEPALIVE, it is configured in any ssh client, for example https://songhuiming.github.io/pages/2019/02/28/how ... and this is the only guaranteed way to solve your problem.
On the other hand, 240 seconds is a very short timeout (usually about 10 minutes is used for UDP and about an hour for TCP) and not all clients can send TCP KEEPALIVE, so you should continue to swear with technical support so that the timeout or the size of the table or the range of NAT ports is increased to reasonable values.

A
Armenian Radio, 2021-03-31
@gbg

Hanging TCP and UDP sessions deliciously eat NAT ports for the provider (apparently, it is quite small and small-town), so it needs to get out somehow.
It does not violate any RFC - this is the Internet, connection disconnection is the norm.
What to do - set up KeepAlive, or use autossh, it constantly sends bytes in an additional connection

P
pfg21, 2021-03-31
@pfg21

Use mosh
, it uses UDP messages for communication and is not tied to maintaining a tcp channel.
more precisely, a tcp channel is needed only at the beginning to knock on the server via ssh and run the program to listen on the port.
they promise that mosh can even withstand switching the "internet channel" from wifi to a cellular channel, etc.

C
CityCat4, 2021-03-31
@CityCat4

If you activate the "Dedicated IP" service, then there is no such problem


I've been trying to find the truth for two months now

Is a static IP service fantastically expensive?

E
Exe Onid, 2021-04-09
@exeonid

very strange wishes from those who answered...
to debug based on words and assumptions... very engineering (no)
why no one suggested to dump the session and just look stupidly...
or how what is happening on the server (or whatever you have) is logged ?
make guesses based on assumptions

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question