https://tailscale.com/docs/features/tailscale-services
Then you can access stuff on your tailnet by going to http://service instead of http://ip:port
It works well! Only thing missing now is TLS
> tailscale serve --service=svc:web-server --https=443 127.0.0.1:8080
> http://web-server.<tailnet-name>.ts.net:443/ > |-- proxy http://127.0.0.1:8080
> When you use the tailscale serve command with the HTTPS protocol, Tailscale automatically provisions a TLS certificate for your unique tailnet DNS name.
So is the certificate not valid? The 'Limitations' section doesn't mention anything about TLS either:
https://tailscale.com/docs/features/tailscale-services#limit...
Problem solved ;)
I'm guessing this is 1Password 8 only, as I can't see this option in 1Password 7.
Matching on base domain as the default was surprising to me when I started using Bitwarden... treating subdomains as the same seems dangerous.
Actually it's mostly financial institutions that I've seen this happen with. Have to wonder if they all share the same web auth library that runs on the Z mainframe, or there's some arcane page of the SOC2 guide that mandates a minimum of 3 redirects to confuse the man in the middle.
You don't need to have any real/public DNS records on that domain, just own the domain so LetsEncrypt can verify and give you SSL certificate(s).
You setup local DNS rewrites in AdGuard - and point all the services/subdomains to your home servers IP, Caddy (or similar) on that server points it to the correct port/container.
With TailScale or similar - you can also configure that all TailScale clients use your AdGuard as DNS - so this can work even outside your home.
Thats how I have e.g.: https://portainer.myhome.top https://jellyfin.myhome.top ...etc...
1. your 1password gets a different entry each time for <service>.<yourdomain>.<tld>
2. you get https for free
3. Remote access without Tailscale.
4. Put Cloudflare Access in front of the tunnel, now you have a proper auth via Google or Github.
No open ports on my internal network, Tailscale handles routing the traffic as needed. Confirmed that traffic is going direct between hosts, no middleman needed.
DNS. SNI. RLY?
On Debian/Ubuntu, hosting local DNS service is easy as `apt-get install dnsmasq` and putting a few lines into `/etc/dnsmasq.conf`.
In homelab space you can also make wildcard DNS pretty easily in dnsmasq, assuming you also "own" your router. If not, hosts file works well enough.
There is also option of using mdns for same reason but more setup
For things like Home Assistant I use the following subdomain structure, so that my password manager does the right thing:
service.myhouse.tld
local.service.myhouse.tldBitwarden annoyingly ignores subdomains by default. Enabling per-sudomain credential matching is a global toggle, which breaks autocomplete on other online service that allow you to login across multiple subdomains.
If you expose something by mistake still should be fine.
Big problem with PW reuse is using the same for very different systems that have different operators who you cannot trust about not keeping your PW in plaintext or getting hacked.
Then, I use Tailscale to connect everything together. Tailscale lets you use a custom DNS, which gets pointed to the PiHole. Phone blocks ads even when im away from the house, and I can even hit any services or projects without exposing them to the general internet.
Then I setup NGINX reverse proxy but that might not be necessary honestly
In Bitwarden they allow you to configure the matching algorithm, and switching from the default to "starts with" is what I do when I find that it is matching the wrong entries. So for this case just make sure that the URL for the service includes the port number and switch all items that are matching to "starts with". Though it does pop up a big scary "you probably didn't mean to do this" warning when you switch to "starts with"; would be nice to be able to turn that off.