Handling switched IPv6 prefixes on virtual private servers (VPS)

Wednesday, December 30 2020 · Lesezeit: 2 Minuten · 401 Wörter Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

I’m currently migrating my LXC containers from my physical server at Hetzner to a KVM virtualized server at Netcup. Both providers allocated a /64 prefix to my server. But there is one major difference: Hetzner routes the traffic to my server and Netcup switches it.

What’s the problem your are talking about?

Let’s say my allocated prefix is 2001:db8:1337:420::/64. I divided that into /120 subnets:

• Host interface eth0: 2001:db8:1337:420::/120
• Host link-local address on eth0: fe80::69
• Bridge “lxc”: 2001:db8:1337:420::100/120
• Host test.veloc1ty.de on bridge lxc: 2001:db8:1337:420::105/120

At Hetzner they’ve configured a static route. Something like 2001:db8:1337:420::/64 via fe80::69. No matter what IP packet comes down the path it will be routed towards my server for further routing/processing.

At Netcup they don’t have a static route to my server. They’ll send out an neighbor solicitation message to find the host responsible for that IP address. But my server will only respond to it when the IP is configured on my hosts network interface. A LXC container never receives it, can’t respond to it and therefore is not reachable. Examples:

• My server will respond when 2001:db8:1337:420:: is requested
• My server will NOT respond, when 2001:db8:1337:420::105 is requested

I’ve done some research and switching the traffic seems to be the industry standard for virtual private servers. I personally like Hetzners approach more.

“Mitigation”

A very common solution you find in online forums is installing an NDP proxy. Depending on your configuration the proxy will respond to any neighbor solicitation for your prefix with a neighbor advertisement. This comes with a downside: If somebody scans your prefix your server will flood the neighbor table from your hosting provider.

But there is actually no need to install anything. You can solve it with board tools. If your container listens on 2001:db8:1337:420::105 and your LXC hosts network interface is eth0 you can add a proxy with the ip command:

ip neigh add proxy 2001:db8:1337:420::105 dev eth0

If a neighbor solicitation for that specific IP address hits your server it will respond to it. The traffic will hit your server and can forward it to the right container.

Pre-requirements are:

• sysctl net.ipv6.conf.eth0.proxy_ndp=1 to enable the NDP proxy feature
• sysctl net.ipv6.conf.eth0.forwarding=1 to enable IP forwarding

This also has a downside: You need to add a proxy for every IP you are using. If you are deploying LXC containers with an automation tool it’s basically a small addition to your deployment process.

Du hast einen Kommentar, einen Wunsch oder eine Verbesserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg) Zurück