Yep @blackjid. YMMV
in your docker compose, define a network
- subnet: 126.96.36.199/24
now any container that you want to be able to communicate through the vpn should be on that network, with a static ip and the vpn also has to be on that network, e.g.
# NB if a service is on multiple networks,
# https://github.com/balena-io/balena-supervisor/issues/824, balena may
# constantly restart it if the networks are not in a 'particular' order
default: # if containers other than vpn need to communicate with this container, however it can't be resolved by the hostname webserver. A fix for this has been merged to balena supervisor but it is not in balenaos yet
now … lets say you have another device on your vpn and you want it to talk to webserver container
you need to route traffic from the vpn container to the webserver container. theres a few ways to do this (e.g. nginx, or ip tables)
with ip tables, add the rule as part of the vpn container startup, e.g.
iptables -t nat -I PREROUTING --src 0/0 --dst "THE VPN INTERFACE IP" -p tcp --dport 443 -j DNAT --to 188.8.131.52
traffic from any client on your vpn would now reach the webserver container, by forwarding packets destined for 443 on the vpn containers external vpn ip to the webserver container’s ip on the vpn network you created in docker-compose
if you need traffic to go back… you need routes to your webserver container so that vpn traffic is routed back through the vpn container
ip route add <YOUR_VPN_SUBNET> via 184.108.40.206