From: Sabrina Dubroca <sd@queasysnail.net>
To: Antonio Quartulli <antonio@openvpn.net>
Cc: netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Donald Hunter <donald.hunter@gmail.com>,
Shuah Khan <shuah@kernel.org>,
ryazanov.s.a@gmail.com, Andrew Lunn <andrew+netdev@lunn.ch>,
Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
Xiao Liang <shaw.leon@gmail.com>
Subject: Re: [PATCH v21 18/24] ovpn: add support for peer floating
Date: Wed, 5 Mar 2025 12:20:15 +0100 [thread overview]
Message-ID: <Z8gzbz6YjdeGPqgu@hog> (raw)
In-Reply-To: <9c919407-fb91-48d7-bf2d-8437c2f3f4da@openvpn.net>
2025-03-05, 00:19:32 +0100, Antonio Quartulli wrote:
> On 04/03/2025 19:37, Sabrina Dubroca wrote:
> > 2025-03-04, 01:33:48 +0100, Antonio Quartulli wrote:
> > > A peer connected via UDP may change its IP address without reconnecting
> > > (float).
> >
> > Should that trigger a reset of the peer->dst_cache? And same when
> > userspace updates the remote address? Otherwise it seems we could be
> > stuck with a cached dst that cannot reach the peer.
>
> Yeah, that make sense, otherwise ovpn_udpX_output would just try over and
> over to re-use the cached source address (unless it becomes unavailable).
Not just the source address, the routing entry too. I'm more concerned
about that: trying to reuse a a cached routing entry that was good for
the previous remote address, but not for the new one.
[adding your next email]
> I spent some more time thinking about this.
> It makes sense to reset the dst cache when the local address changes, but
> not in case of float (remote address changed).
>
> That's because we always want to first attempt sending packets using the
> address where the remote peer sent the traffic to.
> Should that not work (quite rare), then we have code in ovpn_udpX_output
> that will reset the cache and attempt a different address.
I don't think the code in ovpn_udpX_output will reset the cache unless
it was made invalid by a system-wide routing table update (see
dst_cache_per_cpu_get).
rt = dst_cache_get_ip4(cache, &fl.saddr);
if (rt)
goto transmit;
...
transmit:
udp_tunnel_xmit_skb(rt, sk, skb, fl.saddr, fl.daddr, 0,
ip4_dst_hoplimit(&rt->dst), 0, fl.fl4_sport,
fl.fl4_dport, false, sk->sk_no_check_tx);
So it seems that as long as dst_cache_get_ip4 gets us a dst (which
AFAIU will happen, unless we did a dst_cache_reset or something else
made the cached dst invalid -- and ovpn's floating/endpoint update
doesn't do that), we'll just use it.
> > > +void ovpn_peer_endpoints_update(struct ovpn_peer *peer, struct sk_buff *skb)
> > > +{
> > > + struct hlist_nulls_head *nhead;
> > > + struct sockaddr_storage ss;
> > > + const u8 *local_ip = NULL;
> > > + struct sockaddr_in6 *sa6;
> > > + struct sockaddr_in *sa;
> > > + struct ovpn_bind *bind;
> > > + size_t salen = 0;
> > > +
> > > + spin_lock_bh(&peer->lock);
> > > + bind = rcu_dereference_protected(peer->bind,
> > > + lockdep_is_held(&peer->lock));
> > > + if (unlikely(!bind))
> > > + goto unlock;
> > > +
> > > + switch (skb->protocol) {
> > > + case htons(ETH_P_IP):
> > > + /* float check */
> > > + if (unlikely(!ovpn_bind_skb_src_match(bind, skb))) {
> > > + if (bind->remote.in4.sin_family == AF_INET)
> > > + local_ip = (u8 *)&bind->local;
> >
> > If I'm reading this correctly, we always reuse the existing local
> > address when we have to re-create the bind, even if it doesn't match
> > the skb? The "local endpoint update" chunk below is doing that, but
> > only if we're keeping the same remote? It'll get updated the next time
> > we receive a packet and call ovpn_peer_endpoints_update.
> >
> > That might irritate the RPF check on the other side, if we still use
> > our "old" source to talk to the new dest?
> >
> > > + sa = (struct sockaddr_in *)&ss;
> > > + sa->sin_family = AF_INET;
> > > + sa->sin_addr.s_addr = ip_hdr(skb)->saddr;
> > > + sa->sin_port = udp_hdr(skb)->source;
> > > + salen = sizeof(*sa);
> > > + break;
>
> I think the issue is simply this 'break' above - by removing it, everything
> should work as expected.
Only if the bind was of the correct family? Checking an IPv4 local
address (in the bind) against an IPv6 source address in the packet (or
the other way around) isn't going to work well.
> I thin this is a leftover from when float check and endpoint update were two
> different functions/switch blocks.
>
> > > + }
> > > +
> > > + /* local endpoint update */
> > > + if (unlikely(bind->local.ipv4.s_addr != ip_hdr(skb)->daddr)) {
> > > + net_dbg_ratelimited("%s: learning local IPv4 for peer %d (%pI4 -> %pI4)\n",
> > > + netdev_name(peer->ovpn->dev),
> > > + peer->id, &bind->local.ipv4.s_addr,
> > > + &ip_hdr(skb)->daddr);
> > > + bind->local.ipv4.s_addr = ip_hdr(skb)->daddr;
> > > + }
> > > + break;
--
Sabrina
next prev parent reply other threads:[~2025-03-05 11:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 0:33 [PATCH v21 00/24] Introducing OpenVPN Data Channel Offload Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 01/24] net: introduce OpenVPN Data Channel Offload (ovpn) Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 02/24] ovpn: add basic netlink support Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 03/24] ovpn: add basic interface creation/destruction/management routines Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 04/24] ovpn: keep carrier always on for MP interfaces Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 05/24] ovpn: introduce the ovpn_peer object Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 06/24] ovpn: introduce the ovpn_socket object Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 07/24] ovpn: implement basic TX path (UDP) Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 08/24] ovpn: implement basic RX " Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 09/24] ovpn: implement packet processing Antonio Quartulli
2025-03-04 19:02 ` Sabrina Dubroca
2025-03-04 23:35 ` Antonio Quartulli
2025-03-05 10:06 ` Sabrina Dubroca
2025-03-04 0:33 ` [PATCH v21 10/24] ovpn: store tunnel and transport statistics Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 11/24] ovpn: implement TCP transport Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 12/24] skb: implement skb_send_sock_locked_with_flags() Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 13/24] ovpn: add support for MSG_NOSIGNAL in tcp_sendmsg Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 14/24] ovpn: implement multi-peer support Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 15/24] ovpn: implement peer lookup logic Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 16/24] ovpn: implement keepalive mechanism Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 17/24] ovpn: add support for updating local UDP endpoint Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 18/24] ovpn: add support for peer floating Antonio Quartulli
2025-03-04 18:37 ` Sabrina Dubroca
2025-03-04 23:19 ` Antonio Quartulli
2025-03-05 0:19 ` Antonio Quartulli
2025-03-05 11:20 ` Sabrina Dubroca [this message]
2025-03-05 13:14 ` Antonio Quartulli
2025-03-05 16:56 ` Sabrina Dubroca
2025-03-06 10:02 ` Antonio Quartulli
2025-03-07 10:12 ` Sabrina Dubroca
2025-03-10 12:57 ` Antonio Quartulli
2025-03-10 22:32 ` Sabrina Dubroca
2025-03-04 0:33 ` [PATCH v21 19/24] ovpn: implement peer add/get/dump/delete via netlink Antonio Quartulli
2025-03-04 14:35 ` Sabrina Dubroca
2025-03-04 21:42 ` Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 20/24] ovpn: implement key add/get/del/swap " Antonio Quartulli
2025-03-04 12:00 ` Sabrina Dubroca
2025-03-04 12:11 ` Antonio Quartulli
2025-03-04 23:09 ` Sabrina Dubroca
2025-03-05 1:00 ` Antonio Quartulli
2025-03-05 10:11 ` Sabrina Dubroca
2025-03-05 13:17 ` Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 21/24] ovpn: kill key and notify userspace in case of IV exhaustion Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 22/24] ovpn: notify userspace when a peer is deleted Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 23/24] ovpn: add basic ethtool support Antonio Quartulli
2025-03-04 0:33 ` [PATCH v21 24/24] testing/selftests: add test tool and scripts for ovpn module Antonio Quartulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8gzbz6YjdeGPqgu@hog \
--to=sd@queasysnail.net \
--cc=andrew+netdev@lunn.ch \
--cc=antonio@openvpn.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ryazanov.s.a@gmail.com \
--cc=shaw.leon@gmail.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).