←back to thread

634 points david927 | 1 comments | | HN request time: 0.21s | source

What are you working on? Any new ideas that you're thinking about?
Show context
rudasn ◴[] No.41347161[source]
I'm experimenting to figure out the simplest setup possible that allows me to expose an internal web service (eg localhost:3000) to the public Internet (eg app.example.com).

A million ways to do this, of course, but I'm focused on using wireguard so that eg only my wireguard peers can get access to my local service, and for internal traffic (ie vpn).

At the moment I'm settling on having a simple script that I can run on a host alongside wireguard. The script will function like `wg-quick`, parsing a wireguard config file and handilng the routing stuff behind the scenes, and returning a cleaned up config to be passed to `wg`.

Ideally, the wireguard configs could be generated by some other tool or service, like https://wirehub.org, and automatically fetched and applied to the running wg interface.

So, a one liner on a server with a public IP and the services exposed by your wireguard peers can be accessed via a custom domain name while still respecting internal wireguard routing rules (based on AllowedIPs).

If anyone finds this interesting and wants to chat about it, I would love to! My contact info is in my profile.

replies(1): >>41347203 #
hyperbolablabla ◴[] No.41347203[source]
This is what ngrok does right? I'm really interested in how this works, I've never looked into it before. Presumably it requires some kind of dynamic DNS updates if you don't have a static IP?
replies(1): >>41347260 #
1. rudasn ◴[] No.41347260[source]
ngrok, localtunnel, pyjamas, the list is endless..

Yeah, many ways to do it, one is running your own DNS server and have wireguard connections use that DNS server.

I want to avoid having DNS issues, so I'm thinking more like this:

1. DNS CNAME *.internal.example.com 123.23.45.67

2. On 123.23.45.67, run wg.

3. On 123.23.45.67 , run nginx. nginx must be in the same network to do geo blocking on Wireguard peer addressess.

4. Create one nginx server config per service to map domain names to upstream servers. Use variables for upstream servers, allow nginx to start even if upstreams unreachable. Add internal locations for custom errors (Forbidden, Unreachable, etc).

5. When connecting to 123.23.45.67 via Wireguard (ie, Peer Endpoint = 123.23.45.67), ensure 123.23.45.67 is in the range defined by Peer AllowedIPs.