So…in a short sentence…the title. I have a server in a remote location which also happens to be under CGNAT. I only get to visit this location once a year at best, so if anything goes off…It stays off for the rest of that year until I can go and troubleshoot. I have a main location/home where everything works, I get a fixed IP and I can connect multiple services as desired. I’d like to make this so I could publish internal servers such as HA or similar on this remote location, and reach them in a way easy enough that I could install the apps to non-tech users and they could just use them through a normal URL. Is this possible? I already have a PiVPN running wireguard on the main location, and I just tested an LXC container from remote location, it connects via wireguard to the main location just fine, can ping/ssh machines correctly. But I can’t reach this VPN-connected machine from the main location. Alternatively, I’m happy to listen to alternative solutions/ideas on how to connect this remote location to the main one somehow.

Thanks!

@iturnedintoanewt@lemm.ee
creator
link
fedilink
English
18M

Thanks…I think I have now both containers in the home and remote servers within the tailscale network, showing their own IPs. This will make the site accessible via SSH, if I get this right. I’m not sure though how to route whichever remote server I build to the home network

lemmyvore
link
fedilink
English
3
edit-2
8M

You mean how to expose the local services on the machine via Tailscale? You can use the TS_DEST_IP env var. Let me show you my compose.yaml:

services:
  tailscale:
    image: tailscale/tailscale:v1.62.0
    container_name: tailscale
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - TS_HOSTNAME=tailnet-node-name
      - TS_AUTHKEY=tailnet-node-key
      - TS_STATE_DIR=/var/lib/tailscale # see below for persistence
      - TS_ACCEPT_DNS=true # to resolve tailnet names (not necessary if you use IPs)
      - TS_USERSPACE=false # to be able to raise tailscale0 interface
      - TS_DEST_IP=local-ip # the IP where you bind services you want to expose
      - TS_ROUTES=192.168.1.0/24 # optionally expose other local devices 
    volumes:
      - "./data/var/lib/tailscale:/var/lib/tailscale" # persist daemon preferences
      - "/dev/net/tun:/dev/net/tun" # to be able to raise tailscale0 interface
    deploy:
      resources:
	 limits:
	   memory: 256M
	   pids: 100
    restart: always

With TS_USERSPACE=false Tailscale will use kernel access to raise tailscale0 and allocate the tailnet IP you’ve specificed in Tailscale admin.

(TS_USERSPACE=true doesn’t use a network interface at all, you have to use a forward HTTP or SOCKS5 proxy. If you use =true and set up a proxy you don’t have to use TS_DEST_IP.)

With TS_DEST_IP you can bridge the tailnet IP to a local IP. By choosing that local IP well you can expose services to Tailscale selectively.

The simplest approach is to have docker services listen on 0.0.0.0 (happens by default if you don’t specify IP in the “ports:” section, and put the machine’s loopback or LAN IP in TS_DEST_IP. That way you’ll expose all the services automatically.

But you can also expose things explicitly. Let’s say the machine LAN IP is 192.168.1.1. You make up 10.100.100.100 on the host specifically for Tailscale exposure so you say TS_DEST_IP=10.100.100.100. Then in your “ports:” section in compose you add ports explicitly depending on what you want them exposed on. Let’s say you want Jellyfin exposed on both LAN and Tailscale, you add an entry for - 192.168.1.1:8096:8096/tcp and one for - 10.100.100.100:8096:8096/tcp. You only want CUPS exposed on the LAN not on Tailscale so you only add - 192.168.1.1:631:631/tcp for it. For Deluge you want to use the web interface on the LAN so you say - 192.168.1.1:8112:8112/tcp but you want RCP over Tailscale so you can use a phone admin app so you say - 10.100.100.100:58846:58846/tcp.

You get the idea. Yeah it’s a bit more work to specify everything explicitly but it’s a lot more precise (and you can still use the default and listen on 0.0.0.0 for when you want to expose everywhere).

Create a post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

  • 1 user online
  • 260 users / day
  • 494 users / week
  • 1.09K users / month
  • 3.79K users / 6 months
  • 1 subscriber
  • 3.91K Posts
  • 79.2K Comments
  • Modlog