Re: [PATCH] ipvs: skip ipvs snat processing when packet dst is not vip
Duan Jiong <[email protected]> Wed, 21 May 2025 10:04:43 +0800
| Newsgroups | org.kernel.vger.lvs-devel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CALttK1SaxBT-iuRDixBd-2o8SF25DXujV+dfZEoR7bNOFFuPbA@mail.gmail.com> |
On Tue, May 20, 2025 at 9:45 PM Florian Westphal <[email protected]> wrote: > > Julian Anastasov <[email protected]> wrote: > > But the following packet is different from your > > initial posting. Why client connects directly to the real server? > > Is it allowed to have two conntracks with equal reply tuple > > 192.168.99.4:8080 -> 192.168.99.6:15280 and should we support > > such kind of setups? > > I don't even see how it would work, if you allow > > C1 -> S > C2 -> S > > ... in conntrack and you receive packet from S, does that need to > go to C1 or C2? > > Such duplicate CT entries are free'd (refused) at nf_confirm ( > conntrack table insertion) time. iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE Indeed, there is nothing wrong with this logic, but after I added the MASQUERADE rule, it seems that I did snat before confirm causing the source port to change