|
Hello,
Adding lvs-devel@ to CC...
On Mon, 19 May 2025, Duan Jiong wrote:
> Now suppose there are two net namespaces, one is the server and
> its ip is 192.168.99.4, the other is the client and its ip
> is 192.168.99.5, and the other is configured with ipvs vip
> 192.168.99.6 in the host net namespace, configuring ipvs with
> the backend 192.168.99.5.
>
> Also configure
> iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
> to avoid packet loss when accessing with the specified
> source port.
May be I don't quite understand why the MASQUERADE
rule is used...
>
> First we use curl --local-port 15280 to specify the source port
> to access the vip, after the request is completed again use
> curl --local-port 15280 to specify the source port to access
> 192.168.99.5, this time the request will always be stuck in
> the main.
>
> The packet sent by the client arrives at the server without
> any problem, but ipvs will process the packet back from the
> server with the wrong snat for vip, and at this time, since
> the client will directly rst after receiving the packet, the
> client will be stuck until the vip ct rule on the host
> times out.
>
> Signed-off-by: Duan Jiong <djduanjiong@xxxxxxxxx>
> ---
> net/netfilter/ipvs/ip_vs_core.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> index c7a8a08b7308..98abe4085a11 100644
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@ -1260,6 +1260,8 @@ handle_response(int af, struct sk_buff *skb, struct
> ip_vs_proto_data *pd,
> unsigned int hooknum)
> {
> struct ip_vs_protocol *pp = pd->pp;
> + enum ip_conntrack_info ctinfo;
> + struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
>
> if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
> goto after_nat;
> @@ -1270,6 +1272,12 @@ handle_response(int af, struct sk_buff *skb, struct
> ip_vs_proto_data *pd,
> goto drop;
>
> /* mangle the packet */
> + if (ct != NULL &&
> + hooknum == NF_INET_FORWARD &&
> + !ip_vs_addr_equal(af,
> + &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3,
> + &cp->vaddr))
> + return NF_ACCEPT;
Such check will prevent SNAT for active FTP connections
because their original direction is from real server to client.
In which case ip_vs_addr_equal will see difference? When
Netfilter creates new connection for packet from real server?
It does not look good IPVS connection to be DNAT-ed but not
SNAT-ed.
May be you can explain better what IPs/ports are present in
the transferred packets.
> if (pp->snat_handler &&
> !SNAT_CALL(pp->snat_handler, skb, pp, cp, iph))
> goto drop;
> --
> 2.32.1 (Apple Git-133)
Regards
--
Julian Anastasov <ja@xxxxxx>
|
