xietangxin [off-list ref] wrote:

Thanks for your guidance. I’ve successfully fix the helper location
as you suggested, and it works fine for local traffic.

However, I realized that I had completely overlooked the forwarding scenario
(where SNAT acts as a middlebox gateway, e.g. Host A -> Gateway B -> Server C).
In this gateway scenario, when random-fully is enabled, the test results show
a massive performance degradation: the QPS drops from ~19000 down to ~10000.

I don't think the forwarding case is fixable.

Host S could be another NAT gateway, so it could be possible that
the connections originate from different physical machines and
timestamps differ due to different clocks, not per-connection
randomisation.

Since skb->sk is NULL on the forwarding gateway, my current approach of
updating tp->tsoffset in struct tcp_sock cannot be applied here.

Yes. I think the tp->tsoffset recalc is fine to handle local case.

For local case we do know that we're the end host and ts recalc is fine.

To be honest, I am currently stuck on how to handle this forwarding scenario
within the netfilter architecture without adding redundant overhead to the fast path.

Could you please give some advice on how the community would prefer to resolve this?
For instance, should we look into extending the Conntrack NAT extension to
track and adjust the TCP timestamps?

If we have some guarantee that internal network isn't doing any
snat at all, then yes, one could implement some TS adjustment
scheme similar to seqadj extension we already have to deal with
tcp sequence number adjustments.

We'd have to keep state and subtract the offset to get back the
right tsecr again on reverse direction.

I'm not keen to have something like this, it would breaks PAWS
as soon as the originating host is itself a nat gateway.

Is this really a problem to begin with?