Live data from Hacker News

Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

im.salty.fish

51–60 of 66 posts

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#51
post #26

Meta: Huh. I don’t use “shallow dive” enough. “Deep dive” of course, everyone loves a good deep dive. But what about a shallow dive, or even just “getting your feet wet”? These are useful concepts too. This headline alone revealed a blind spot for me.

Maybe we can expand X in Y minutes beyond programming languages?

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#53
post #41

Earlier quoted context omitted.

Probably the most common use case is letting Avahi/Bonjour/etc. or DHCP work across a tunnel.

Bonjour is built on top of DNS. You don't need a layer 2 tunnel to make it work. However, it normally does rely on multicast. Rather than trying to bridge broadcast domains (which is going to cause performance issues), a more efficient option is to setup an Avahi mDNS reflector on either end of the tunnel to rebroadcast mDNS packets. See, for example: https://www.reddit.com/r/WireGuard/comments/g80bxf/comment/h... Al…

You are technically correct (best kind of correct) however, in reality, I see folks using L2 tunnels to solve for bonjour etc all the time. Usually those without networking knowledge to solve the forwarding.

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#54
post #30
post #19

Earlier quoted context omitted.

Since WireGuard is Layer 3, what would is everyone's use case of doing Layer 2 on it? Or, what can it improve over existing solutions? I have tried to do the same for a bit while still learning networking, but ran into Layer 3 limitations.

One example usecase would be to try to tunnel something like BOOTP/DHCP/PXE/TFTP stack, which iirc is bit tricky with only L3 tunneling.

Yes, this is common among those who don't understand how DHCP Relay works

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#55

>I always felt, and still feel, that applied Linux networking is difficult to get started with, mainly due to lack of good guidance. Most of the time I had to dig through small pieces of documentation scattered throughout the internet, trying to put them together to form a systematic overview of the network stack in Linux. ... >It is extremely frustrating when somebody interested in setting up their own network infra…

I found WireGuard to actually be especially frustrating, because it doesn't really log anything. If you do a single configuration misstep the packets just won't flow. Then good luck figuring out whether it's the authentication that's wrong (or any of the cert checks in the chain), rounting, MTU, firewall or anything inbetween.

It's kinda horrible. Not that IPsec is any better. OpenVPN at least yells something at you.

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#56
> We will be using the local IPv6 addresses fc00::/7 for routing inside our WireGuard network. For example, if we use the subnet fc00:0:0:160::/64, this can be the new Address config on Server:

> Address = 192.168.160.2, fc00:0:0:160::2

Please don't do this. fc00::/7 has been assigned for "Unique Local Unicast" and address ranges must be generated as specified in RFC 4193: https://www.google.com/search?hl=en&q=ipv6%20ula%20generator

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#57

>I always felt, and still feel, that applied Linux networking is difficult to get started with, mainly due to lack of good guidance. Most of the time I had to dig through small pieces of documentation scattered throughout the internet, trying to put them together to form a systematic overview of the network stack in Linux. ... >It is extremely frustrating when somebody interested in setting up their own network infra…

When you ask for help and the person responds with "It's all in the man pages."

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#58
post #41

Earlier quoted context omitted.

Bonjour is built on top of DNS. You don't need a layer 2 tunnel to make it work. However, it normally does rely on multicast. Rather than trying to bridge broadcast domains (which is going to cause performance issues), a more efficient option is to setup an Avahi mDNS reflector on either end of the tunnel to rebroadcast mDNS packets. See, for example: https://www.reddit.com/r/WireGuard/comments/g80bxf/comment/h... Al…

You are technically correct (best kind of correct) however, in reality, I see folks using L2 tunnels to solve for bonjour etc all the time. Usually those without networking knowledge to solve the forwarding.

Yeah, you can do it the right way...or you can just tunnel layer 2 and forget about it. I see it done a fair bit for both Bonjour/Avahi and DHCP (why?).

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#59
post #30

Earlier quoted context omitted.

One example usecase would be to try to tunnel something like BOOTP/DHCP/PXE/TFTP stack, which iirc is bit tricky with only L3 tunneling.

Yes, this is common among those who don't understand how DHCP Relay works

Many don't, and I suspect searching for "how to do on VPN" yields "turn on Layer 2 tunneling."

Re: Linux Networking Shallow Dive: WireGuard, Routing, TCP/IP and NAT

#60
post #55

>I always felt, and still feel, that applied Linux networking is difficult to get started with, mainly due to lack of good guidance. Most of the time I had to dig through small pieces of documentation scattered throughout the internet, trying to put them together to form a systematic overview of the network stack in Linux. ... >It is extremely frustrating when somebody interested in setting up their own network infra…

I found WireGuard to actually be especially frustrating, because it doesn't really log anything. If you do a single configuration misstep the packets just won't flow. Then good luck figuring out whether it's the authentication that's wrong (or any of the cert checks in the chain), rounting, MTU, firewall or anything inbetween. It's kinda horrible. Not that IPsec is any better. OpenVPN at least yells something at you.

I'm wondering whether one can get these notifications through netlink. Not having any way to get the kinds of feedback you're mentioning from a stateful thing is horrible user experience. It doesn't need to cover the firewall part, mtu rejects, etc. Because if it's actually modular, you're supposed to be able use the usual tools (/proc/net and /sys/net for stats and netlink for firewall logs?), hopefully they're usable...
Post reply on HN