Neither helps if the line that you're using drops mid-call, but there are ways to deal with that, if you have high speed available at a datacenter. For instance, I've set up routing of a small public subnet via tinc (https://www.tinc-vpn.org) over two routing machines, each with their own Internet connection, with CARP so that packets can go through either machine. This makes handing off from one to the other transparent so that connections don't need to be reestablished.
Can you explain more about the setup above? I don’t understand how tinc comes into play. What OS and physical configuration are you using?
Starting with how it works and physical setup, you have tinc running, attached to a tap interface, bridged to an ethernet interface. The ethernet interface is configured on your LAN to route (not NAT) for your local computer(s) / VoIP devices.
What's good about this is that a machine on your local network (seeable from the ethernet that's part of the bridge) can be on a 100% public address, if you want, or on a private IP range. When routing, as opposed to NAT, only the endpoints care about the existence / state of any connections, which is one of the reasons the Internet is so resilient (your intermediate hops can change without needing to renegotiate sessions).
This means that intermediate machines, including the ones running tinc, can be down for a minute - even restarted - and, if the machines are patient, the endpoint machines will just see a temporary pause.
So take two machines, each running tinc, each configured with CARP, sharing the gateway IP for the public subnet from the upstream machine. Your local machine running your video conferencing software (or, perhaps VoIP phone) communicates through the primary (active) CARP local machine. Suddenly, a shot rings out! And the primary CARP machine dies, and the maid screams, but before the scream the secondary CARP machine takes over the IP and is routing those video (or SIP) packets, so we can hear the maid scream.
There are ways to failover NAT, but they're complicated because the primary and the failover machines need to constantly share the NAT state table. Even if you're routing (not NATing) private IP subnets, so long as you're doing NAT upstream, it still works.
Comments
Can you explain more about the setup above? I don’t understand how tinc comes into play. What OS and physical configuration are you using?
Sure :)
I'm running tinc on NetBSD.
Starting with how it works and physical setup, you have tinc running, attached to a tap interface, bridged to an ethernet interface. The ethernet interface is configured on your LAN to route (not NAT) for your local computer(s) / VoIP devices.
What's good about this is that a machine on your local network (seeable from the ethernet that's part of the bridge) can be on a 100% public address, if you want, or on a private IP range. When routing, as opposed to NAT, only the endpoints care about the existence / state of any connections, which is one of the reasons the Internet is so resilient (your intermediate hops can change without needing to renegotiate sessions).
This means that intermediate machines, including the ones running tinc, can be down for a minute - even restarted - and, if the machines are patient, the endpoint machines will just see a temporary pause.
So take two machines, each running tinc, each configured with CARP, sharing the gateway IP for the public subnet from the upstream machine. Your local machine running your video conferencing software (or, perhaps VoIP phone) communicates through the primary (active) CARP local machine. Suddenly, a shot rings out! And the primary CARP machine dies, and the maid screams, but before the scream the secondary CARP machine takes over the IP and is routing those video (or SIP) packets, so we can hear the maid scream.
There are ways to failover NAT, but they're complicated because the primary and the failover machines need to constantly share the NAT state table. Even if you're routing (not NATing) private IP subnets, so long as you're doing NAT upstream, it still works.
Does that make sense?