AP Application Load Balancer (AP-ALB). Sophisticated monolithic Ansible role to manage standalone and clusters of cross-platform and multicloud load balancers. Abstract HAProxy + OpenResty + On-the-fly auto HTTPS. Dedicated to Public Domain.
This issue is strongly related to ALB v0.8.x and clustering related options #17.
While I was working on the clustered AP-ALB demo, different from the version where nodes does not need talk with each other beyond the internal routing, the clustered version or would require lots of documentation related to security OR just at least give some option to implement any VPN. Both decisions would require time (and the second one maybe not really much, even in the short term) so this issue is about deliver one demo with this option.
I stopped a few hours yesterday and was looking for what to use to implement:
Some alternatives (at time of writting)
OpenVPN
No. Not for this. It's neither designed for "mesh networks" (it somewhat would require star networks, it means SPoF) and is not even easy to implement to worth the time.
IPSec++ (++ = with extensions)
This would be the most industry standard to implement. It's not trivial to get done right, but is one of the most efficient. Even if not done for now, is something to consider or at least leave room in the configurations to implement later.
I actually liked the Tinc. It by design do something near of what we want. Not hard to implement as OPenVPN and IPSec++ (even have some playbooks with this). It also allows featues like if direct route from one node to another is blocked, it can decide on the fly to use other nodes until get to destiny.
Wireguard is both fast, have a very clean code base, is VPN at kernel level (like IPSec) and (this is very, very impressive) even the Linus Tovards make comparison saying this code base was much better than IPSec and OpenVPN and was interested to get it merged to the linux kernel. I even read the discussions thread, and the code was not implemented yet both because of some code refactoring was need (and the authors of Wireguard are working hard to make it) and also had complains that it was "not audited like the others". The main author of Wireguard complained that even the others where not audited (and maybe the Wireguard was getting more pression to refactoring than any other in the past).
Also, some complains about Wireguard was not merged was because he re-implementing some funcions already done by other parts of the kernel. Some he already is fixing but others he on the linux maillist literaly get references of the authors of other VPNs or algorithms admitting errors or have issues for years and noting getting done. Not that the Wireguard seems to be bullied in special, no, I'm not saying this, but the standard way people who approve code to be merged to the kernel is very perfectionist. This also maybe explain why the website of Wireguard, at this exact moment, make serious disclamer that even if is used for years it still cannot be called safe to use. Not that it was worse than alternatives, but for sure Jason Donenfeld is trying be from start better and more responsible than others.
Here some links. Note that there is a lot, even more than Tinc.
This issue is strongly related to ALB v0.8.x and clustering related options #17.
While I was working on the clustered AP-ALB demo, different from the version where nodes does not need talk with each other beyond the internal routing, the clustered version or would require lots of documentation related to security OR just at least give some option to implement any VPN. Both decisions would require time (and the second one maybe not really much, even in the short term) so this issue is about deliver one demo with this option.
I stopped a few hours yesterday and was looking for what to use to implement:
Some alternatives (at time of writting)
OpenVPN
No. Not for this. It's neither designed for "mesh networks" (it somewhat would require star networks, it means SPoF) and is not even easy to implement to worth the time.
IPSec++ (++ = with extensions)
This would be the most industry standard to implement. It's not trivial to get done right, but is one of the most efficient. Even if not done for now, is something to consider or at least leave room in the configurations to implement later.
Tinc
I actually liked the Tinc. It by design do something near of what we want. Not hard to implement as OPenVPN and IPSec++ (even have some playbooks with this). It also allows featues like if direct route from one node to another is blocked, it can decide on the fly to use other nodes until get to destiny.
Wireguard
Wireguard is both fast, have a very clean code base, is VPN at kernel level (like IPSec) and (this is very, very impressive) even the Linus Tovards make comparison saying this code base was much better than IPSec and OpenVPN and was interested to get it merged to the linux kernel. I even read the discussions thread, and the code was not implemented yet both because of some code refactoring was need (and the authors of Wireguard are working hard to make it) and also had complains that it was "not audited like the others". The main author of Wireguard complained that even the others where not audited (and maybe the Wireguard was getting more pression to refactoring than any other in the past).
Also, some complains about Wireguard was not merged was because he re-implementing some funcions already done by other parts of the kernel. Some he already is fixing but others he on the linux maillist literaly get references of the authors of other VPNs or algorithms admitting errors or have issues for years and noting getting done. Not that the Wireguard seems to be bullied in special, no, I'm not saying this, but the standard way people who approve code to be merged to the kernel is very perfectionist. This also maybe explain why the website of Wireguard, at this exact moment, make serious disclamer that even if is used for years it still cannot be called safe to use. Not that it was worse than alternatives, but for sure Jason Donenfeld is trying be from start better and more responsible than others.
Here some links. Note that there is a lot, even more than Tinc.