On Thu, Jul 08, 2021 at 12:18:09PM -0400, Brian Brombacher wrote:
[..]
> Are you changing the default TCPKeepAlive setting? It defaults to yes. It exists as options in sshd_ and ssh_config. Additionally, ClientAliveInterval and ServerAliveInterval might be handy. A sysctl also exists to turn TCP keep alive on for all connections by default.
>
I didn't change that setting but I have this on pod's sshd_config:
#TCPKeepAlive yes
> Not sure it???ll help. Does your download crawl to a halt, then after a period of time, you get the FIN?
So what I'm doing is 'scp pod:Backup/*gz .' to the local directory on arda
(local host).
In the tcpdump the packets go by fairly rapidly in fact there is a lot of
packets before the FP (fin packet) even makes it through to arda (because there
is at least a dozen packets in flight).
One note here: I applied the IPSEC to escape any in-band attacks, however when
I did that last week, the very first time I tried to scp my backups the
connection did indeed crawl to a halt. It was just sitting there. I worried
back then that someone spoofed WIN 0's into the IPSEC'ed stream somehow but
I applied anti-spoof rules on IPSEC so that can't happen and the fear was
probably unfounded in retrospect. I still don't have an explanation for myself
for that though. Perhaps it was the missing scrub to lower the MTU on enc0
which isn't adjustable? Anyhow last week then I did manage to download the
4 GB of backups, but doing so this week proved to not work.
> (Note: I don???t have any Hetzner hosts and I???m just guessing based on my experience with Azure)
>
> -Brian
Thanks. I looked over my firewall rules on enc0 a little and did notice I have
a scrub rule that changes the mss to 1240 I'm not sure tough if that will
cause this behaviour. It wasn't used anyhow when I just did the plain scp
without wrapping IPSEC around it, and then it still FIN'ed and subsequent
RST'.
Best Regards,
-peter
No comments:
Post a Comment