first version of the knowledge base :)
This commit is contained in:
124
40 - Guides/networking/tailscale-exit-nodes.md
Normal file
124
40 - Guides/networking/tailscale-exit-nodes.md
Normal file
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: Tailscale Exit Nodes
|
||||
description: Guide to publishing and using Tailscale exit nodes for internet-bound traffic
|
||||
tags:
|
||||
- networking
|
||||
- tailscale
|
||||
- vpn
|
||||
category: networking
|
||||
created: 2026-03-14
|
||||
updated: 2026-03-14
|
||||
---
|
||||
|
||||
# Tailscale Exit Nodes
|
||||
|
||||
## Introduction
|
||||
|
||||
An exit node is a Tailscale device that forwards a client's default route. When enabled, internet-bound traffic leaves through that node instead of the client's local network.
|
||||
|
||||
## Purpose
|
||||
|
||||
Exit nodes are commonly used for:
|
||||
|
||||
- Secure browsing on untrusted networks
|
||||
- Reaching the internet through a trusted home or lab connection
|
||||
- Testing geo-dependent behavior from another site
|
||||
- Concentrating egress through a monitored network path
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
With an exit node, the selected client sends default-route traffic through Tailscale to the exit node, which then forwards it to the public internet.
|
||||
|
||||
```text
|
||||
Client -> Tailscale tunnel -> Exit node -> Internet
|
||||
```
|
||||
|
||||
Important implications:
|
||||
|
||||
- The exit node becomes part of the trust boundary
|
||||
- Bandwidth, DNS behavior, and logging depend on the exit node's network
|
||||
- Local LAN access on the client may need explicit allowance
|
||||
|
||||
## Step-by-Step Guide
|
||||
|
||||
### 1. Prepare the exit node host
|
||||
|
||||
Choose a stable host with sufficient upstream bandwidth and a network path you trust. Typical choices are a home server, small VPS, or a utility VM.
|
||||
|
||||
### 2. Advertise the node as an exit node
|
||||
|
||||
On the node:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --advertise-exit-node
|
||||
```
|
||||
|
||||
You can combine this with tags:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --advertise-exit-node --advertise-tags=tag:exit-node
|
||||
```
|
||||
|
||||
### 3. Approve or review the role
|
||||
|
||||
Approve the exit node in the admin console if required by policy. Restrict who can use it with ACLs or grants.
|
||||
|
||||
### 4. Select the exit node on a client
|
||||
|
||||
From a client, choose the exit node in the Tailscale UI or configure it from the CLI:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --exit-node=<exit-node-name-or-ip>
|
||||
```
|
||||
|
||||
If the client still needs to reach the local LAN directly, enable local LAN access in the client configuration or UI.
|
||||
|
||||
## Configuration Example
|
||||
|
||||
Example for a dedicated Linux exit node:
|
||||
|
||||
```bash
|
||||
sudo tailscale up \
|
||||
--advertise-exit-node \
|
||||
--advertise-tags=tag:exit-node
|
||||
```
|
||||
|
||||
Client-side example:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --exit-node=home-gateway
|
||||
curl https://ifconfig.me
|
||||
```
|
||||
|
||||
## Troubleshooting Tips
|
||||
|
||||
### Internet access stops after selecting the exit node
|
||||
|
||||
- Confirm the exit node is online in `tailscale status`
|
||||
- Verify the exit node host itself has working internet access
|
||||
- Check the exit node's local firewall and forwarding configuration
|
||||
|
||||
### Local printers or NAS become unreachable
|
||||
|
||||
- Enable local LAN access on the client if that behavior is required
|
||||
- Split administrative traffic from internet egress if the use case is mixed
|
||||
|
||||
### Performance is poor
|
||||
|
||||
- Verify the client is using a nearby and healthy exit node
|
||||
- Check the exit node's CPU, uplink bandwidth, and packet loss
|
||||
- Avoid placing an exit node behind overloaded or unstable consumer hardware
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Use exit nodes for specific trust and egress requirements, not as a default for every device
|
||||
- Restrict usage to approved groups or devices
|
||||
- Keep exit nodes patched because they handle broad traffic scopes
|
||||
- Log and monitor egress hosts like any other shared network gateway
|
||||
- Separate personal browsing, admin traffic, and production service egress when the risk model requires it
|
||||
|
||||
## References
|
||||
|
||||
- [Tailscale: Exit nodes](https://tailscale.com/kb/1103/exit-nodes)
|
||||
- [Tailscale: What is Tailscale?](https://tailscale.com/kb/1151/what-is-tailscale)
|
||||
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)
|
||||
143
40 - Guides/networking/tailscale-subnet-routing.md
Normal file
143
40 - Guides/networking/tailscale-subnet-routing.md
Normal file
@@ -0,0 +1,143 @@
|
||||
---
|
||||
title: Tailscale Subnet Routing
|
||||
description: Guide to publishing LAN subnets into a Tailscale tailnet with subnet routers
|
||||
tags:
|
||||
- networking
|
||||
- tailscale
|
||||
- routing
|
||||
category: networking
|
||||
created: 2026-03-14
|
||||
updated: 2026-03-14
|
||||
---
|
||||
|
||||
# Tailscale Subnet Routing
|
||||
|
||||
## Introduction
|
||||
|
||||
Subnet routing allows Tailscale clients to reach devices that are not running the Tailscale agent directly. This is useful for printers, storage appliances, hypervisors, IoT controllers, and legacy systems on a homelab LAN.
|
||||
|
||||
## Purpose
|
||||
|
||||
Use subnet routing when:
|
||||
|
||||
- A device cannot run the Tailscale client
|
||||
- A full site-to-site VPN is unnecessary
|
||||
- Remote users need access to one or more internal networks
|
||||
- You want to publish access to a specific VLAN without exposing the entire environment
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
A subnet router is a Tailscale node with IP forwarding enabled. It advertises one or more LAN prefixes to the tailnet.
|
||||
|
||||
```text
|
||||
Remote client -> Tailscale tunnel -> Subnet router -> LAN target
|
||||
```
|
||||
|
||||
Recommended placement:
|
||||
|
||||
- One router per routed network or security zone
|
||||
- Prefer stable hosts such as small Linux VMs, routers, or dedicated utility nodes
|
||||
- Apply restrictive ACLs so only approved identities can use the route
|
||||
|
||||
## Step-by-Step Guide
|
||||
|
||||
### 1. Prepare the router host
|
||||
|
||||
Install Tailscale on a Linux host that already has reachability to the target subnet.
|
||||
|
||||
Enable IPv4 forwarding:
|
||||
|
||||
```bash
|
||||
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
If the subnet is IPv6-enabled, also enable IPv6 forwarding:
|
||||
|
||||
```bash
|
||||
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
### 2. Advertise the subnet
|
||||
|
||||
Start Tailscale and advertise the route:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --advertise-routes=192.168.10.0/24
|
||||
```
|
||||
|
||||
Multiple routes can be advertised as a comma-separated list:
|
||||
|
||||
```bash
|
||||
sudo tailscale up --advertise-routes=192.168.10.0/24,192.168.20.0/24
|
||||
```
|
||||
|
||||
### 3. Approve the route
|
||||
|
||||
Approve the advertised route in the Tailscale admin console, or pre-authorize it with `autoApprovers` if that matches your policy model.
|
||||
|
||||
### 4. Restrict access
|
||||
|
||||
Use ACLs or grants so only the necessary users or tagged devices can reach the routed subnet.
|
||||
|
||||
Example policy intent:
|
||||
|
||||
- `group:admins` can reach `192.168.10.0/24`
|
||||
- `group:developers` can only reach specific hosts or ports
|
||||
- IoT and management subnets require separate approval
|
||||
|
||||
## Configuration Example
|
||||
|
||||
Example server-side command for a dedicated subnet router:
|
||||
|
||||
```bash
|
||||
sudo tailscale up \
|
||||
--advertise-routes=192.168.10.0/24 \
|
||||
--advertise-tags=tag:subnet-router
|
||||
```
|
||||
|
||||
Example policy idea:
|
||||
|
||||
```json
|
||||
{
|
||||
"tagOwners": {
|
||||
"tag:subnet-router": ["group:admins"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Troubleshooting Tips
|
||||
|
||||
### Clients can see the route but cannot reach hosts
|
||||
|
||||
- Verify IP forwarding is enabled on the router
|
||||
- Confirm local firewall rules permit forwarding traffic
|
||||
- Make sure the router has normal LAN connectivity to the destination hosts
|
||||
- Check whether the destination host has a host firewall blocking the source
|
||||
|
||||
### Route does not appear in the tailnet
|
||||
|
||||
- Confirm the router is online in `tailscale status`
|
||||
- Check that the route was approved in the admin console
|
||||
- Review whether policy requires a specific tag owner or auto-approval
|
||||
|
||||
### Asymmetric routing or reply failures
|
||||
|
||||
- Make sure the subnet router is in the normal return path for the destination subnet
|
||||
- Avoid overlapping subnets across multiple sites unless routing precedence is intentional
|
||||
- Do not advertise broad prefixes when a narrower one is sufficient
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Advertise the smallest subnet that solves the use case
|
||||
- Run subnet routers on stable infrastructure, not laptops
|
||||
- Use separate routers for management and user-facing networks where possible
|
||||
- Combine routing with ACLs; route advertisement alone is not authorization
|
||||
- Monitor route health and document ownership of every advertised prefix
|
||||
|
||||
## References
|
||||
|
||||
- [Tailscale: Subnet routers](https://tailscale.com/kb/1019/subnets)
|
||||
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)
|
||||
- [Tailscale: Policy file syntax](https://tailscale.com/kb/1337/policy-syntax)
|
||||
Reference in New Issue
Block a user