skills/deploying-tailscale-for-zero-trust-vpn/SKILL.md
Deploys and configures Tailscale (or self-hosted Headscale) as a WireGuard-based zero trust mesh VPN, setting up identity-aware ACLs, exit nodes, subnet routers, and MagicDNS for encrypted peer-to-peer connectivity. Use when replacing traditional VPN servers with an identity-authenticated mesh network or enforcing granular per-device access control lists.
npx skillsauth add mukul975/anthropic-cybersecurity-skills deploying-tailscale-for-zero-trust-vpnInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Tailscale is a zero trust mesh VPN built on WireGuard that creates encrypted peer-to-peer connections between devices without requiring traditional VPN servers or complex network configuration. Every connection in a Tailscale network (tailnet) is end-to-end encrypted using WireGuard's Noise protocol framework with Curve25519 key exchange. Tailscale implements zero trust networking by authenticating every connection request through identity providers, enforcing granular Access Control Lists (ACLs), and supporting features like exit nodes, subnet routers, MagicDNS, and Tailscale SSH. For organizations preferring self-hosted infrastructure, Headscale provides an open-source implementation of the Tailscale control server.
Tailscale Coordination Server
(or self-hosted Headscale)
|
Key Distribution
& NAT Traversal
|
+-----------------+-----------------+
| | |
+----+----+ +----+----+ +----+----+
| Node A |<---->| Node B |<---->| Node C |
| (Linux) | | (macOS) | |(Windows)|
+---------+ +---------+ +---------+
WireGuard WireGuard WireGuard
Encrypted Encrypted Encrypted
P2P Tunnel P2P Tunnel P2P Tunnel
Each node connects directly to every other node.
DERP relay servers used only when direct P2P fails.
# Add Tailscale repository and install
curl -fsSL https://tailscale.com/install.sh | sh
# Start Tailscale and authenticate
sudo tailscale up
# Check connection status
tailscale status
# View assigned IP address
tailscale ip -4
tailscale ip -6
# Windows: Download from https://tailscale.com/download/windows
# macOS: Install via Homebrew
brew install --cask tailscale
# Or download from https://tailscale.com/download/mac
# docker-compose.yml for Tailscale sidecar
version: '3.8'
services:
tailscale:
image: tailscale/tailscale:latest
container_name: tailscale
hostname: my-service
environment:
- TS_AUTHKEY=tskey-auth-xxxxx # Pre-auth key
- TS_STATE_DIR=/var/lib/tailscale
- TS_EXTRA_ARGS=--advertise-tags=tag:container
volumes:
- tailscale-state:/var/lib/tailscale
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: unless-stopped
volumes:
tailscale-state:
# Tailscale operator for Kubernetes
apiVersion: v1
kind: Secret
metadata:
name: tailscale-auth
namespace: tailscale
type: Opaque
stringData:
TS_AUTHKEY: "tskey-auth-xxxxx"
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: tailscale
namespace: tailscale
spec:
selector:
matchLabels:
app: tailscale
template:
metadata:
labels:
app: tailscale
spec:
containers:
- name: tailscale
image: tailscale/tailscale:latest
env:
- name: TS_AUTHKEY
valueFrom:
secretKeyRef:
name: tailscale-auth
key: TS_AUTHKEY
- name: TS_KUBE_SECRET
value: tailscale-state
- name: TS_USERSPACE
value: "true"
securityContext:
capabilities:
add: ["NET_ADMIN"]
Tailscale ACLs define who can access what within your tailnet using a declarative JSON format. The default policy is deny-all, making it zero trust by design.
{
"acls": [
// Engineering team can access development servers
{
"action": "accept",
"src": ["group:engineering"],
"dst": ["tag:dev-server:*"]
},
// SRE team can access production infrastructure
{
"action": "accept",
"src": ["group:sre"],
"dst": ["tag:production:22,443,8080"]
},
// Database access restricted to backend services
{
"action": "accept",
"src": ["tag:backend"],
"dst": ["tag:database:5432,3306,27017"]
},
// All employees can access internal tools
{
"action": "accept",
"src": ["group:employees"],
"dst": ["tag:internal-tools:443"]
}
],
"groups": {
"group:engineering": ["[email protected]", "[email protected]"],
"group:sre": ["[email protected]", "[email protected]"],
"group:employees": ["autogroup:members"]
},
"tagOwners": {
"tag:dev-server": ["group:engineering"],
"tag:production": ["group:sre"],
"tag:backend": ["group:sre"],
"tag:database": ["group:sre"],
"tag:internal-tools": ["group:sre"],
"tag:container": ["group:sre"]
},
"ssh": [
{
"action": "check",
"src": ["group:sre"],
"dst": ["tag:production"],
"users": ["root", "admin"]
},
{
"action": "accept",
"src": ["group:engineering"],
"dst": ["tag:dev-server"],
"users": ["autogroup:nonroot"]
}
],
"nodeAttrs": [
{
"target": ["autogroup:members"],
"attr": ["funnel:deny"]
}
]
}
# On the exit node machine
sudo tailscale up --advertise-exit-node
# On the client machine, use the exit node
sudo tailscale up --exit-node=<exit-node-ip>
# Verify exit node routing
curl ifconfig.me # Should show exit node's public IP
# Advertise local subnets through Tailscale
sudo tailscale up --advertise-routes=10.0.0.0/24,192.168.1.0/24
# Enable IP forwarding on Linux
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# Accept routes on client
sudo tailscale up --accept-routes
Tailscale SSH replaces traditional SSH key management with identity-based access.
# Enable Tailscale SSH on a server
sudo tailscale up --ssh
# Connect using Tailscale SSH (no SSH keys needed)
ssh user@hostname # Authenticates via Tailscale identity
# Session recording (audit logging)
# Configure in ACL policy:
# "ssh": [{"action": "check", "src": [...], "dst": [...], "users": [...]}]
# "check" action requires re-authentication and records sessions
# MagicDNS is enabled by default in new tailnets
# Access devices by hostname instead of IP
ping my-server # Resolves via MagicDNS
# Custom DNS configuration via admin console
# Split DNS: route specific domains to internal DNS servers
# Global nameservers: override default DNS resolution
# Install Headscale (open-source Tailscale control server)
wget https://github.com/juanfont/headscale/releases/latest/download/headscale_linux_amd64
chmod +x headscale_linux_amd64
sudo mv headscale_linux_amd64 /usr/local/bin/headscale
# Create configuration
sudo mkdir -p /etc/headscale
sudo headscale generate config > /etc/headscale/config.yaml
# Edit config for your environment
# Key settings:
# server_url: https://headscale.example.com
# listen_addr: 0.0.0.0:8080
# private_key_path: /etc/headscale/private.key
# db_type: sqlite3
# db_path: /var/lib/headscale/db.sqlite
# Start Headscale
sudo headscale serve
# Create user and pre-auth key
headscale users create myorg
headscale preauthkeys create --user myorg --reusable --expiration 24h
# Connect Tailscale client to Headscale
tailscale up --login-server https://headscale.example.com
# Set key expiry in admin console (default: 180 days)
# Force re-authentication periodically
# Disable key expiry for servers (use auth keys instead)
sudo tailscale up --authkey=tskey-auth-xxxxx
# Pre-auth keys for automated deployment
# Create ephemeral, single-use keys for CI/CD
{
"nodeAttrs": [
{
"target": ["autogroup:members"],
"attr": [
"mullvad:deny",
"funnel:deny"
]
}
],
"autoApprovers": {
"routes": {
"10.0.0.0/24": ["group:sre"],
"192.168.0.0/16": ["group:sre"]
},
"exitNode": ["group:sre"]
}
}
# Initialize network lock with signing keys
tailscale lock init
# Add trusted signing keys
tailscale lock add nodekey:xxxxx
# All new nodes require signing before joining
# Prevents unauthorized nodes from joining the tailnet
# View network status
tailscale status --json | jq '.Peer | to_entries[] | {name: .value.HostName, online: .value.Online, os: .value.OS}'
# Check connection quality
tailscale ping <peer-ip>
# View network map
tailscale netcheck
# Audit logs available in Tailscale admin console
# Integration with SIEM via webhook or API
# Tailscale as sidecar for service-to-service communication
# Each service gets a Tailscale identity
# ACLs enforce service-to-service access policies
# Example: API service can only reach database service
# ACL: tag:api -> tag:database:5432
# Use ephemeral auth keys in CI/CD
export TS_AUTHKEY=tskey-auth-xxxxx-ephemeral
tailscale up --authkey=$TS_AUTHKEY --hostname=ci-runner-$CI_JOB_ID
# Access internal resources during build/deploy
# Node automatically removed when container stops
tools
Executes authorized phishing simulation campaigns to assess an organization's susceptibility to email-based social engineering attacks. The tester designs realistic phishing scenarios, builds credential harvesting infrastructure, sends targeted phishing emails, and tracks open rates, click-through rates, and credential submission rates to measure human security awareness. Activates for requests involving phishing simulation, social engineering assessment, email security testing, or security awareness measurement.
development
Drive a federal system through the NIST Risk Management Framework (SP 800-37 Rev 2) to an Authorization to Operate (ATO): Prepare, Categorize (FIPS 199), Select a control baseline (FIPS 200 / SP 800-53 Rev 5), Implement, Assess (SP 800-53A), Authorize, and Monitor continuously. Use when a system needs an ATO or a renewal, when working a FISMA/FedRAMP authorization package, when building or reviewing an SSP, SAR, or POA&M, when categorizing a system as Low/Moderate/High impact, when selecting or tailoring a control baseline, or when standing up continuous monitoring (ConMon) after authorization. Covers ATO, conditional ATO (cATO), and the artifacts assessors expect. Keywords: NIST RMF, 800-37, ATO, authorization to operate, FISMA, FedRAMP, SSP, SAR, POA&M, FIPS 199, FIPS 200, 800-53, 800-53A, control baseline, security categorization, continuous monitoring, authorizing official, system boundary, ongoing authorization.
development
Executes authorized attack simulations against Active Directory environments to identify misconfigurations, weak credentials, dangerous privilege paths, and exploitable trust relationships that could lead to domain compromise. The tester uses BloodHound for attack path analysis, Mimikatz for credential extraction, and Impacket for protocol-level attacks including Kerberoasting, AS-REP Roasting, and delegation abuse. Activates for requests involving Active Directory pentest, AD attack simulation, domain compromise testing, or Kerberos attack assessment.
tools
Evaluates and selects Threat Intelligence Platform (TIP) products based on organizational requirements including feed integration capability, STIX/TAXII support, workflow automation, analyst interface, and total cost of ownership. Use when conducting a TIP procurement, migrating between TIP solutions, or assessing whether the current TIP meets program maturity requirements. Activates for requests involving ThreatConnect, MISP, OpenCTI, Anomali, EclecticIQ, or TIP procurement decisions.