browser makes a HTTP request 2. The tailscale client picks this up and sends it to the destination node (if ACL’s or Grants permit it) 3. Tailscale serve on the destination node forwards the traffic onto the attached application 4. Application receives the request and does it’s thing. Simple architecture
headers onto the request as they pass through which can be used to identify the user making the request. • Tailscale-User-Login • Tailscale-User-Name • Tailscale-User-Profile-Pic (optional) But wait, there’s more!
change your application, or write specific integration code • No login screens, passwords, or OAuth obstacle courses - that’s already happened • Horizontal scaling is pretty simple The pros and cons • Additional infrastructure to manage (proxy node) • Limited ability to force an identity check (sudo mode) • Doesn’t tackle application permissions
browser makes a HTTP request 2. The tailscale client picks this up and sends it to the destination node (if ACL’s or Grants permit it) 3. The application itself is the destination node, so it receives the request and returns the response Simpler architecture
to manage • Still no login screens, etc • Lots of example applications to follow The pros and cons • Go is the only language with practical support right now for listening directly a tailnet* • Application capabilities are best accessed through Go* • Would require a proxy of some kind if you wanted to horizontally scale * libtailscale will hopefully improve on this