Diplonat

Feature set

• (Re)Configure NAT via UPNP/IGD (prio: high)
• (Re)Configure nftable (prio: low)
• (Re)Configure DNS via ??? (prio: low)

Understand scope

• Reconfigure local environment when provisionning a cluster service
  • Reconfigure host on demand according to service needs (Firewall)
  • Reconfigure host local network according to service needs (Router NAT)
• Operate a global reconfiguration that associate the tuple (local environment information, a cluster service)
  • Reconfigure an external service with local info (DNS with public IP returned by the router via IGD)

Operate

cargo build
consul agent -dev # in a separate terminal

# adapt following values to your configuratio
export DIPLONAT_PRIVATE_IP="192.168.0.18"
export DIPLONAT_REFRESH_TIME="60"
export DIPLONAT_EXPIRATION_TIME="300"
export DIPLONAT_CONSUL_NODE_NAME="lheureduthe"
export RUST_LOG=debug
cargo run

Design Guidelines

Diplonat is made of a set of Components. Components communicate between them thanks to tokio::sync::watch transferring copiable messages. Each message must contain the whole state (and not a transition) as messages can be lost if a more recent message is received. This choice has been made to limit bugs. If you need to watch two actors and merge their content, you may use tokio::sync::select. When you read a value from source 1, you must cache it to be able to merge it later when you read from source 2.

About Consul Catalog

• We query the /v1/catalog/node/<node> endpoint
• We can watch it thanks to Blocking Queries

eg:

curl -vvv http://127.0.0.1:8500/v1/catalog/node/lheureduthe
# returns X-Consul-Index: 15
curl -vvv http://127.0.0.1:8500/v1/catalog/node/lheureduthe?index=15

Each time you do the request, the whole list of services bound to the node is returned.

To test the Consul Catalog part, you can do:

consul agent -dev #in a separate terminal, if not already running
consul services register -name=example -port=1337
consul services -id=example