A diagram of the relevant Hypervisor/VMs/containers + Network information would be helpful.
From where and how are you testing DNS? Did you use dig and specified the nameserver directly?
Jenseitsjens
joined 10 months ago
Zyxel AX7501 has one sfp+ 10G wan and one rj45 10G lan port. Should be around 350$ if you can buy it where you live. I work at an ISP am that's the device we're giving to our customers for 10G.
In general I don't think you'll get much lower than that even if you build your own router.
I was a bit surprised when I checked the docker docs that there's no mention of NAT for the bridge network driver, because that's what's happening.
Within your server, between the docker-bridge and your physical (and virtual wireguard) interface is a router which performs NAT (Network-Address-Translation). As a matter of fact, it's likely happening again on the other side of the wireguard tunnel, since you'll probably end up sharing the public IP with other ProtonVPN customers.
It's exactly the same mechanism your internet-router uses who likely only has a single public IPv4 Address. When you open a TCP connection from your computer, the router will store the combination of (src-ip, src-port, dst-ip, dst-port) into the NAT table and rewrites the src-ip to the public IPv4 address. Once a reply packet comes from the destination, it will look into its NAT table and if it finds a match, it'll rewrite the dst-ip to your personal machine.
This whole process can also happen twice or more times without issue. (Initiating connections from outside to inside becomes a problem though, that's why Port-Forwarding exists).
The wireguard tunnel might add to the confusion, but see it as a separate connection that needs to be established. Once the tunnel is made, all traffic flowing through the tunnel does not need to be aware of anything underneath the tunnel.
They defined it as above 1.6 tons (metric) for ICE/hybrid and 2 tons for EVs
That doesn't match my experience with AUR at all. Usually it pulls a specific git revision and checks the hash. This also ensures that the build shouldn't suddenly fail to some extent.
Though it's entirely possible that it's not like this for all packages, though I find it kind of counterintuitive since your package manager wouldn't know when to perform an update in this case.