perdian / blog-comments

Utterance repository for comments to blog entries on www.perdian.de/blog
0 stars 0 forks source link

blog/2022/02/21/setting-up-a-wireguard-vpn-using-kubernetes/ #2

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

Christian Seifert // Setting up a WireGuard VPN using Kubernetes

Setting up a WireGuard VPN using Kubernetes

https://www.perdian.de/blog/2022/02/21/setting-up-a-wireguard-vpn-using-kubernetes/

3deep5me commented 2 years ago

Thank you! I will definitely try this out. Do you have plans to push it in a git repository?

qqespqq commented 1 year ago

Useful example, thanks! However, setting "securityContext: privileged: true" significantly decreases security and breaks container isolation, thus increasing privilege escalation risks. Is this really needed, any suggestion to improve it?

perdian commented 1 year ago

setting "securityContext: privileged: true" significantly decreases security and breaks container isolation, thus increasing privilege escalation risks. Is this really needed, any suggestion to improve it?

I must admit for me this was a bit of cargo culting. It didn't work without the setting so that's what I added to actually make it work. If it's really necessary or if there is another way... I don't know.

thapoffice commented 1 year ago

Great! tried a lot but my wiregauard pod kept failing until I read your article, However, in my case kubectl get svc -n wireguard lists me the Private IP of my cluster node and not the Public IP

Did I miss something?

kubectl get svc -n wireguard NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE wireguard LoadBalancer 10.43.209.221 10.0.0.100 51820:30970/UDP 7m21s

perdian commented 1 year ago

Did I miss something?

Not really sure. Maybe there is no public IP assigned to the cluster itself?

sakmalh commented 1 year ago

@perdian I setup everything like you have mentioned. The client connects but has not internet access.

'''

[Interface] Address = 172.16.16.0/20 ListenPort = 51820 PrivateKey = OIviMX9BPHk1w/bvsXW0Qc2/mY3+HS3iS31aEtsn+Uc= PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ENI -j MASQUERADE PostUp = sysctl -w -q net.ipv4.ip_forward=1 PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ENI -j MASQUERADE PostDown = sysctl -w -q net.ipv4.ip_forward=0

[Peer] PublicKey = AOIzLd2C71DtY8DWgUfuMllRNa0iR1O3tO2WbFO7ICU= AllowedIPs = 172.16.16.10

'''

Used this

UntouchedWagons commented 1 year ago

I had to change where the wireguard-config volume is mounted at in the wireguard container from /etc/wireguard/ to /config/. The init container was fine however.

sholdee commented 6 months ago

Due to what I assume have been changes in how the container manages configurations, I had to modify the original instructions to get this working. I hope this helps anyone else who is trying to accomplish this. It will allow for wireguard to fully initialize with the default managed configuration that is generated at container runtime before swapping it out with your own configuration. Here are my sanitized manifests:

wireguard-namespace.yml https://pastebin.com/raw/hbxugbbu wireguard-secret.yml https://pastebin.com/raw/HJwx2MB2 wireguard-service.yml https://pastebin.com/raw/u2GEKvbe wireguard-deployment.yml https://pastebin.com/raw/nAtfSrSD

perdian commented 6 months ago

Thanks a lot @UntouchedWagons and @sholdee for the comments. I've updated the article with the latest changes made by LinuxServer.io. The configuration is working again with the examples given here.