Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
Container Networking with Vxlan, BGP and WireGuard
21–30 of 45 posts
Re: Container Networking with Vxlan, BGP and WireGuard
#22Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
http://www.tarsnap.com/spiped.html
This still has the same problems as distributing certs and setting everything up :/ was looking for something that "encrypts literally everything" when it goes out to another machine on the cloud
Re: Container Networking with Vxlan, BGP and WireGuard
#23This article uses Quagga - they really should be using FRRouting, which was forked from Quagga in 2017 by the core Quagga developers and has 4 times as many commits (16000[0] vs 4000[1]), far more features, bugfixes, etc. Quagga has been dead for over a year. [0] https://github.com/FRRouting/frr [1] http://gogs.quagga.net/Quagga
For a more full fledged use case FRRouting may be the way to go. We are using Quagga here mainly to maintain internal routes with iBGP and route reflectors. This is a fairly simple use case.
Quagga is available in the default package managers of most distros so its a good place to start.
Re: Container Networking with Vxlan, BGP and WireGuard
#24Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Tcpcrypt
How does opportunistic encryption prevent a MITM from forcing the session into unencrypted mode when its established?
It doesn't, but that's not the point of it. It's to prevent passive spying, like opportunistic TLS for SMTP.
I merely pointed it out because the OP was talking about encryption done at the TCP layer. :)
Re: Container Networking with Vxlan, BGP and WireGuard
#25One does not simply go from a flat network to overlays. Overlays are slow, difficult, cause really odd failures and are often hilariously immature. They are the experimental graph database of the network world.
Just have a segregated network, and let the VPC/dhcp do all the hard stuff.
Have your hosts on the default VLAN(or Interface if your cloudy), with its own subnet (Subnets should only exist in one VLAN.) Then if you are in cloud land, have a second network adaptor on a different subnet. If you are running real steel, then you can use a bonded network adaptor with multiple VLANs on the same interface. (The need for a VLAN in a VPC isn't that critical because there are other tools to impose network segregation.)
Then use macvtap, or macvlan(or which ever thing that gives each container a macaddress) to give each container its own IP. This means that your container is visible on that entire subnet, either inside the host or without.
There is no need to faff with routing, it comes for free with your VPC/network or similar. Each container automatically has a hostname, IP, route. It will also be fast. As a bonus it call cane be created at the start using cloudformation or TF.
You can have multiple adaptors on a host, so you can separate different classes of container.
Look, the more networking that you can offload to the actual network the better.
If you are ever re-creating DHCP/routing/DNS in your project, you need to take a step back and think hard about how you got there.
70% of the networking modes in k8s are batshit insane. a large amount are basically attempts at vendor lock in, or worse someone's experiment thats got out of hand. I know networking has always been really poor in docker land, but there are ways to beat the stupid out of it.
The golden rule is this:
Always. Avoid. Network. Overlays.
Re: Container Networking with Vxlan, BGP and WireGuard
#26In my mind, a "layer 2 subnet" really doesn't mean anything. Subnets are things that happen in IP, that is, layer 3, and layer 2 is the physical connection, ie. Ethernet or WLAN, which don't have the concept of subnets. Edit: also the OSI layer model was specified in the eighties, and isn't all that accurate in 2019 to describe how our networks actually work.
I'd argue that the closest thing to a layer 2 subnet is a VLAN.
Re: Container Networking with Vxlan, BGP and WireGuard
#27Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
> just talk to each other using wiregaurd by default
I don't understand why you'd want to do this?
I use wireguard to join machines on disparate networks into one.
However to do it inside the same VPC, I just don't get. If you don't trust your VPC surely you need to be moving off the cloud?
Re: Container Networking with Vxlan, BGP and WireGuard
#28Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
> just talk to each other using wiregaurd by default I don't understand why you'd want to do this? I use wireguard to join machines on disparate networks into one. However to do it inside the same VPC, I just don't get. If you don't trust your VPC surely you need to be moving off the cloud?
I agree with your viewpoint but I'm also aware of several security standards that explicitly specify all traffic between hosts needs to be encrypted. Sometimes it's easier to meet the standard verbatim than try and justify an exception. If you already use a configuration management tool it shouldn't be a lot more overhead to install some certificates.
Re: Container Networking with Vxlan, BGP and WireGuard
#29Can we have a version using IPv6 instead of legacy IPv4? It would make things a lot simpler (no need for any fancy routing or nat).
IPv6 doesn't save you from any routing problems that IPv4 won't save you from. While IPv6 tries to hide the layer 2/layer 3 distinction from you, it doesn't actually make your physical network magically work differently. Internally IPv6 tries to implement this hiding using multicast - same as the VXLAN suggestion in the article. If you overload your network infrastructure's multicast support, at best you fall back to…
> If you don't have multicast support at all in your network infrastructure, which as the article points out isn't common to have on cloud networks,
Huh? Are you assuming large flat L2 networks addressed with IPv6?
IPv6 works great at scale, just route everything everywhere, stick with unicast & anycast, and don't roll large L2 domains. Multicast is entirely unnecessary aside from the small amount needed for ND/RA between host and ToR.
And, for operations, a routed IPv6 network without NAT, VXLAN, or VLANs spanned across switches is much easier to troubleshoot and generally has fewer moving parts to fail.
Re: Container Networking with Vxlan, BGP and WireGuard
#30Earlier quoted context omitted.
http://www.tarsnap.com/spiped.html
This still has the same problems as distributing certs and setting everything up :/ was looking for something that "encrypts literally everything" when it goes out to another machine on the cloud
At the end of the day, there needs to be a trust root.