I’m running opnsense on proxmox with some lxc containers and docker hosts.
I’ve never done internal DNS routing, just a simple DMZ with Cloudflare proxies and static entries for some external services. I want to simplify things and stop using my IPs from memory internally.
For example, I have the ports on my docker hosts memorized for the services I use, only a couple mapped hosts in opnsense, but nothing centralized.
What is the best way to handle internal DNS name resolution for both docker and the lxc containers? Internal CA certs? External unroutable (security)?
Focus on DNS for the host machine and it’s port mappings, not the individual containers.
If you’re instead asking “How can I easily map a DNS name to service and port?”, then you want a reverse proxy on your host machine, like nginx (simplest) or Traefik (more complex, but geared towards service discovery and containers).
In the latter scenario you setup a named virtual host for each service that maps back to the service port exposed for your containers. Example: a request for jellyfin.localdomain.com points to the host machine, nginx answers the request and maps the host name in the request, then proxies your session to the container.
It’s copy and paste for the most part once you get the first one going unless you’re dealing with streaming.
If you’re running a flexible platform on your router like OpenWRT, you could also do some port forwarding as a means to achieve the same thing.
@___ normally in the containers you can specify the dns server to use or include hosts directly in the static table, at the orchestrator level the ingress and egress options are used to specify interfaces and network configuration, although i think kubernetes stores everything in the etcd.
The steps below are high level, but should provide an outline of how to accomplish what you’re asking for without having to associate your IP address to any domains nor publicly exposing your reverse proxy and the services behind the reverse proxy. I assume since you’re running Proxmox that you already have all necessary hardware and would be capable of completing each of the steps. There are more thorough guides available online for most of the steps if you get stuck on any of them.
Purchase a domain name from a domain name registrar
Use NginxProxyManager, Traefik, or some other reverse proxy that supports automatic certificate renewals and wildcard certificates
Configure both the DNS provider and the reverse proxy to use the wildcard domain challenge
Setup a local DNS server (eg: PiHole, AdGuardHome, Blocky, etc.) and configure your firewall/router to use the DNS server as your DNS resolver
Configure your reverse proxy to serve your services via domains with a subdomain (eg: service1.domain.com, service2.domain.com, etc.) and turn on http (port 80) to https (port 443) redirects as necessary
Configure your DNS server to point your services’ subdomains to the IP address of your reverse proxy
Access to your services from anywhere on your network using the domain name and https when applicable
(Optional) Setup a VPN (eg: OpenVPN, WireGuard, Tailscale, Netbird, etc.) within your network and connect your devices to your VPN whenever you are away from your network so you can still securely access your services remotely without directly exposing any of the services to the internet
I have a similar setup except I use pfSense as my router and pihole for DNS, but I’m sure you can get the same results with your setup. I’m running HAProxy for my reverse proxy and configs for each of my docker containers so any traffic on 443 or 80 gets sent to the container IP on whatever unique port it uses. I then have DNS entries for each URL I want to access the container by, with all of those entries just pointing to HAProxy. Works like a charm.
I have HAProxy running on the pihole itself but there’s no reason you couldn’t just run that in it’s own container. pfSense also let’s you install an HAProxy package to handle it on the router itself. I don’t know if opensense supports packages like that though.
You can even get fancy and do SSL offloading to access everything over HTTPS.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
5 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #967 for this sub, first seen 11th Sep 2024, 19:25] [FAQ] [Full list] [Contact] [Source code]
Focus on DNS for the host machine and it’s port mappings, not the individual containers.
If you’re instead asking “How can I easily map a DNS name to service and port?”, then you want a reverse proxy on your host machine, like nginx (simplest) or Traefik (more complex, but geared towards service discovery and containers).
In the latter scenario you setup a named virtual host for each service that maps back to the service port exposed for your containers. Example: a request for jellyfin.localdomain.com points to the host machine, nginx answers the request and maps the host name in the request, then proxies your session to the container.
It’s copy and paste for the most part once you get the first one going unless you’re dealing with streaming.
If you’re running a flexible platform on your router like OpenWRT, you could also do some port forwarding as a means to achieve the same thing.
This is what I was think also. Just let the host rproxy the requests and just map the dns to the host in opnsense.
@___ normally in the containers you can specify the dns server to use or include hosts directly in the static table, at the orchestrator level the ingress and egress options are used to specify interfaces and network configuration, although i think kubernetes stores everything in the etcd.
The steps below are high level, but should provide an outline of how to accomplish what you’re asking for without having to associate your IP address to any domains nor publicly exposing your reverse proxy and the services behind the reverse proxy. I assume since you’re running Proxmox that you already have all necessary hardware and would be capable of completing each of the steps. There are more thorough guides available online for most of the steps if you get stuck on any of them.
https://youtu.be/liV3c9m_OX8
This should help
This is very nice. Thanks!
I have a similar setup except I use pfSense as my router and pihole for DNS, but I’m sure you can get the same results with your setup. I’m running HAProxy for my reverse proxy and configs for each of my docker containers so any traffic on 443 or 80 gets sent to the container IP on whatever unique port it uses. I then have DNS entries for each URL I want to access the container by, with all of those entries just pointing to HAProxy. Works like a charm.
I have HAProxy running on the pihole itself but there’s no reason you couldn’t just run that in it’s own container. pfSense also let’s you install an HAProxy package to handle it on the router itself. I don’t know if opensense supports packages like that though.
You can even get fancy and do SSL offloading to access everything over HTTPS.