Add some more content
This commit is contained in:
@@ -128,9 +128,17 @@ runcmd:
|
|||||||
{% end %}
|
{% end %}
|
||||||
|
|
||||||
## 2. Extend ipv-proxy
|
## 2. Extend ipv-proxy
|
||||||
In its original state, the ipv-proxy could only do "manual" forwarding.
|
In its original state, the ipv-proxy could only do "manual" forwarding and connect to a single consul address, which both needs to be reworked.
|
||||||
Therefore I first extended it, to support different backends for performing the actual forwarding.
|
|
||||||
It also now supports multiple addresses for consul, which it will try round-robin style, until one works.
|
The first change, was to add support for different backends that perform the actual forwarding.
|
||||||
|
Previously it was pretty hard-coded how the forwarding worked, but now all the behaviour for the forwarding is abstracted away and the core logic just
|
||||||
|
gets something that knows how to do all the forwarding specific stuff.
|
||||||
|
This allowed me to easily add a jool backend, which just needs to implement the corresponding trait and integrate it into CLI, but the rest of the logic is left untouched.
|
||||||
|
Another benefit, that I hope to utilize soon, is that I can also pass in dummy/mock/test implementations for forwarding, to test the core logic and its interaction with the forwarding.
|
||||||
|
|
||||||
|
The second change, was more subtle and in the pursuit of better reliability, as it now supports having multiple consul addresses.
|
||||||
|
Previously one could only pass a single address and if that had issues, then the ipv-proxy was basically not working anymore.
|
||||||
|
However now, I can pass the addresses of all my consul servers and it will try all of them until one responds, which means I no longer have a single point of failure in this regard.
|
||||||
|
|
||||||
## 3. Wireguard setup
|
## 3. Wireguard setup
|
||||||
TODO
|
TODO
|
||||||
|
|||||||
Reference in New Issue
Block a user