5 ms·
> NAT/STUN world you were trying to avoid The clean way to build this is with firewall configuration, opening ports, and static IPs. NAT/STUN and dynamic IPs a
by lo0dot0 2y ago
> NAT/STUN world you were trying to avoid
The clean way to build this is with firewall configuration, opening ports, and static IPs. NAT/STUN and dynamic IPs are just a hack and I don't understand why people pretend this is an acceptable solution for professional networking. Working around an infrastructure that isn't a natural law but can be changed at our will seems like a big waste of time.
- supermatt 2y ago> I don't understand why people pretend this is an acceptable solution for professional networking Because it IS acceptable for many cases. Many businesses don't operate in such a way as to have centralised infrastructure solely for providing internal networking, nor would they want to add the additional administrative or unnecessary routing overhead. Even locations that would traditionally be considered highly centralised often have some form of dynamic network fabric as an overlay. Pretty much the entirety of cloud infrastructure runs on such systems, and they seem to do OK.
- lo0dot0 2y agoDynamic IP addresses typically also have a forced disconnect at a regular interval. Not really what I want to host services on.
- supermatt 2y agoThat seems like even more reason to use an overlay - it abstracts all that instability away and gives you a consistent, secure network regardless of what the underlying IPs are doing. Obviously peers can have static IPs too if you think that makes them more stable to routing changes (it doesn't).
- lo0dot0 2y agoDo you really think that a tailscale VPN is necessary to deal with link failures? It is not BGP and SD-WAN or MPLS l2 VPN can do that.
- supermatt 2y agoI didn't mention Tailscale. I said "overlay", and both SD-WAN and MPLS L2 VPN are overlay networks.
- lo0dot0 2y agoIdk what you mean with routing instability. Changes to routing as a result of failures are a feature not the problem.
- supermatt 2y agoYou said "Dynamic IP addresses typically also have a forced disconnect at a regular interval.", which is false in pretty much every DHCP scenario I have ever seen. A change in an IP lease should result in no downtime whatsoever, because addressing is not the same as routing. A routing change would have exactly the same effect on a static IP. I then pointed out that an overlay network means you don't have to worry about that anyway. I think you need to reread whatever comments you think you are responding to, as there is clearly something out of sync with your replies.
- lo0dot0 2y agoAlso DERP relays having QOS that isn't controlled by myself and I have to hope to get bandwidth through doesn't exactly make me confident about the solution
- supermatt 2y agoSure, but your data is only getting relayed through DERP servers if it cant otherwise establish a direct p2p connection. This can usually be resolved at either side of the connection - if you know about it (which is what the parent was suggesting could be made more clear). As for your bandwidth concerns in the case of needing to relay, you can even set up your own relay (https://tailscale.com/kb/1118/custom-derp-servers https://tailscale.com/kb/1118/custom-derp-servers), which would satisfy your desire to be more centralised (i guess you could force all traffic through it, but cant think why you would want to) while still allowing the flexibility of the overlay that tailscale provides.
- lo0dot0 2y agoI never said I had a desire to be more centralised. I just said that static IPs and open ports remove the necessity for hole punching/STUN. You can have multiple sites without a central and all use static IPs and open ports.
- supermatt 2y agoI was replying to your comment about you wanting to control QoS for relaying.
- udev4096 2y agoWho said you can't do both? NAT makes things easier and you can still properly configure your firewall to keep track of all the NAT traversal rules