Wat is Tailscale en hoe werkt het?

Wat is Tailscale?

Tailscale is een VPN die uw machines rechtstreeks met elkaar verbindt in plaats van al het verkeer via één gateway te routeren die u zelf beheert. Elk knooppunt draait WireGuard, waardoor pakketten versleuteld van de ene server naar de andere reizen en niets in het pad deze kan lezen. Een gehoste coördinatieserver regelt de introducties. Deze slaat publieke sleutels op, verspreidt ze en vertelt elk knooppunt waar de andere zich bevinden. Ook pusht de server de toegangsregels die u heeft opgesteld.

Die splitsing vormt het volledige ontwerp. Het datavlak is peer-to-peer en versleuteld tussen knooppunten. Het controle-vlak is een dienst die Tailscale voor u beheert. Elke relevante vraag over Tailscale, inclusief de lastige vragen over vertrouwen, vloeit voort uit deze twee feiten. Als u al handmatig een WireGuard VPN op een VPS heeft opgezet, dan is Tailscale diezelfde tunnel, waarbij sleuteldistributie en firewall-traversal voor u zijn geregeld.

Hoe werkt Tailscale?

Uw privénetwerk van nodes wordt een tailnet genoemd. Er gebeuren vier dingen wanneer een machine lid wordt van zo'n netwerk.

1. De tailscaled daemon start, genereert een WireGuard sleutelpaar en slaat de status op in /var/lib/tailscale/tailscaled.state. De privésleutel blijft op die machine staan. Tailscale verwoordt dit expliciet: "de privésleutel verlaat nooit, onder geen beding, zijn node."
2. De node logt in op de coördinatieserver en uploadt zijn publieke sleutel, plus de adressen waarop de node denkt bereikbaar te zijn. Tailscale omschrijft die server als "een gedeelde dropbox voor publieke sleutels."
3. De coördinatieserver stuurt een netwerkkaart terug: de publieke sleutel, het tailnet-adres, de machinenaam en de kandidaat-eindpunten van elke node die deze node mag bereiken.
4. Elk paar nodes probeert vervolgens een directe WireGuard tunnel tussen elkaar op te bouwen. Wanneer dat mislukt, sturen ze de pakketten via een relay.

Elke node krijgt een stabiel adres uit 100.64.0.0/10, het carrier-grade NAT-bereik dat loopt van 100.64.0.0 tot 100.127.255.255. Tailscale gebruikt dat bereik omdat het gereserveerd is voor infrastructuur van providers, waardoor het zelden botst met de privéadressen die uw servers al gebruiken. Op Linux verschijnt de tunnel als een interface genaamd tailscale0.

De WireGuard-implementatie bevindt zich in tailscaled in userspace, niet in de kernelmodule. Daarom start Tailscale op container-virtualisatie waar sudo modprobe wireguard faalt met Operation not supported. Dit betekent ook dat het maximale doorvoervermogen op een bepaalde machine lager is dan bij kernel WireGuard; dit is een van de afwegingen die Tailscale versus standaard WireGuard bespreekt.

Twee commando's laten zien wat de status is.

tailscale ip -4
tailscale status

tailscale status toont één regel per node, en de laatste kolom is de belangrijkste.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct gevolgd door een adres en poort betekent dat de twee machines een pad naar elkaar hebben gevonden en dat het verkeer peer-to-peer verloopt. relay "fra" betekent dat het verkeer via een Tailscale relay in Frankfurt verloopt. Een - betekent dat er op dit moment geen actieve sessie met die node is, wat normaal is.

Wat de coördinatieserver wel en niet kan zien

De coördinatieserver beheert publieke sleutels en metadata. Deze server kent uw machinenamen, welke gebruiker of tag eigenaar is van elk knooppunt, het tailnet-adres van elk knooppunt, de publieke adressen waarop uw knooppunten bereikbaar zijn, wanneer elk knooppunt voor het laatst online was en het door u geschreven policy-bestand. Dit vormt een volledig overzicht van uw netwerk.

De server bevat geen privésleutels en kan daarom het verkeer tussen twee knooppunten niet ontsleutelen. Versleuteling vindt end-to-end plaats tussen de WireGuard-peers; de coördinatieserver is zelf geen peer.

Wat de server wel kan, is sleutels verstrekken. Elke coördinatieserver, of deze nu gehost of zelf beheerd wordt, wordt vertrouwd om uw knooppunten te informeren welke publieke sleutels bij het tailnet horen. Dit is het kernpunt van het dreigingsmodel verderop in dit document en de reden waarom Headscale, een open-source coördinatieserver die u zelf host bestaat.

Hoe twee servers achter verschillende firewalls direct communiceren

NAT (network address translation) zorgt ervoor dat meerdere machines één publiek adres kunnen delen. Uw VPS heeft meestal een eigen publiek adres, maar de andere machines die u in het tailnet wilt opnemen vaak niet: een thuisserver, een build runner op een kantoornetwerk of een systeem achter een firewall van een provider die u niet kunt aanpassen.

Tailscale vindt een pad met behulp van technieken die gebaseerd zijn op de STUN (session traversal utilities for NAT) en ICE standaarden. Elke node stuurt een klein UDP-pakket naar een STUN-server en leert zo het publieke adres en de poort die de router aan die socket heeft toegewezen. Beide nodes rapporteren deze kandidaten aan de coördinatieserver, die ze doorgeeft aan de andere kant. Vervolgens beginnen beide nodes tegelijkertijd pakketten naar elkaar te sturen. Elke router ziet eerst een uitgaand pakket, maakt daarvoor een mapping aan en accepteert het antwoord dat vanaf datzelfde adres binnenkomt. Geen van beide kanten heeft een inkomende firewallregel nodig.

De poorten zijn specifiek. Directe WireGuard-tunnels gebruiken UDP met een bronpoort die standaard op 41641 staat. STUN verloopt via UDP 3478 naar de relay-servers van Tailscale. De controleverbinding en eventuele relayed data gebruiken HTTPS op TCP 443. Meestal hoeft u geen inkomende poorten te openen, hoewel het op een netwerk met een complexe NAT de kans op een directe verbinding vergroot als u UDP 41641 inkomend toestaat.

tailscale netcheck

Lees twee regels van dat rapport. UDP: true betekent dat UDP de machine überhaupt verlaat, en UDP: false betekent dat elke verbinding vanaf deze node wordt gerelayed. MappingVariesByDestIP: true betekent dat de router per bestemming een andere publieke poort toewijst, waardoor de bovenstaande adresvoorspelling niet kan werken en die nodes meestal gerelayed blijven.

Wanneer Tailscale in plaats daarvan een DERP-relay gebruikt

DERP (designated encrypted relay for packets) fungeert als fallback. Tailscale beheert relays in vele regio's, bereikbaar via TCP 443. Een node die geen direct pad kan vinden, stuurt zijn WireGuard-pakketten via zo'n relay.

De pakketten blijven versleuteld. Tailscale stelt dit duidelijk: "er is voor een DERP-server nooit een manier om uw verkeer te ontsleutelen. Het stuurt enkel blindelings reeds versleuteld verkeer door van de ene node naar de andere." Een relay ziet enkel cijfertekst en ziet welke node met welke node communiceert.

Relays verwerken ook de eerste pakketten van de meeste verbindingen. Het vinden van een direct pad kost tijd, waardoor een sessie vaak via een relay start en ter plekke wordt opgewaardeerd zodra de twee nodes elkaar hebben gevonden. U kunt dit proces observeren.

tailscale ping db-1

De eerste antwoorden komen terug via DERP(fra), waarna een latere regel iets rapporteert zoals via 198.51.100.24:41641. Die wijziging is de upgrade naar een directe tunnel. Als dit nooit verandert, voer dan tailscale netcheck uit aan beide zijden. Een relay-pad werkt nog steeds. Het kost echter latentie, omdat elk pakket een omweg maakt via een derde machine.

Een VPS toevoegen aan uw tailnet

Het installatiescript ondersteunt Ubuntu en Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up geeft een URL weer. Open deze, verifieer uw identiteit en de node verschijnt in uw admin console. Controleer daarna of de daemon na een herstart weer opkomt, aangezien dit de stap is die vaak wordt vergeten.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled hoort enabled weer te geven en tailscale status moet de nieuwe node met het 100.x-adres tonen. Voor een server die via een script is opgezet, is een interactieve URL niet bruikbaar. Genereer een auth key in de admin console en geef deze mee, samen met een tag die vastlegt wat voor type machine dit is.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Een getagde node is eigendom van de tag in plaats van de persoon die het commando uitvoerde. Hierdoor blijft de node functioneren nadat het account van die persoon is verwijderd. De tag moet eerst in uw policy-bestand onder tagOwners worden gedeclareerd, anders wordt het commando geweigerd. Tagging verandert ook hoe de machine meetelt voor uw abonnement, omdat een getagde resource anders wordt geprijsd dan de eigen apparaten van een gebruiker. wat de gratis laag precies dekt zet uiteen waar die limieten liggen.

Twee instellingen zijn van belang voor een vloot aan machines. Node keys verlopen standaard na 180 dagen (stand augustus 2026). Wanneer een key verloopt, stoppen "verbindingen van/naar het betreffende eindpunt" totdat iemand opnieuw inlogt. Open daarom de rij van de machine in de admin console en kies Disable Key Expiry voor onbeheerde servers. MagicDNS, standaard ingeschakeld voor tailnets aangemaakt op of na 20 oktober 2022, geeft elke node een naam zoals db-1.yak-bebop.ts.net, die wordt omgezet door een stub resolver op 100.100.100.100. Gebruik de namen in plaats van de adressen, omdat een opnieuw opgebouwde node een nieuw adres krijgt maar zijn naam behoudt.

Als de installatie zelf faalt bij apt of bij de repository, behandelt de veelvoorkomende Tailscale-installatiefouten op Ubuntu de oplossingen.

Een service bereiken die aan localhost is gebonden

Dit is waar een tailnet nuttig wordt en waar gebruikers vaak vastlopen. Het toevoegen van een node aan het tailnet maakt een loopback-service niet automatisch bereikbaar.

ss -tlnp | grep 3000

Als dit 127.0.0.1:3000 weergeeft, accepteert de socket alleen pakketten waarvan de bestemming 127.0.0.1 is. Een verzoek van een andere node komt aan met het 100.x-adres van deze node als bestemming, waardoor de kernel geen luisterend proces vindt en antwoordt met een TCP reset. De client meldt Connection refused. De tunnel functioneert correct. De listener is het probleem.

Er zijn twee correcte oplossingen. Bind de service aan het tailnet-adres van de node; dit houdt de service weg van de publieke interface zonder tussenkomst van een proxy: gebruik --bind 100.101.102.104 of de equivalente optie in uw configuratie, en publiceer de poort voor een container als -p 100.101.102.104:3000:3000. Of laat de service op loopback staan en plaats Tailscale ervoor.

tailscale serve 3000

Dit proxiet verzoeken naar http://127.0.0.1:3000 en serveert ze binnen uw tailnet op een ts.net-naam via HTTPS, zodra HTTPS-certificaten zijn ingeschakeld voor het tailnet. Het blijft privé voor uw nodes. De publieke versie van hetzelfde concept is Funnel, en Tailscale serve tegenover funnel behandelt welke optie u nodig heeft.

Twee gerelateerde taken hebben hun eigen pagina's. Voor het bereiken van een volledig privénetwerk waarop geen Tailscale is geïnstalleerd, is een subnet router op een VPS nodig, en voor het sturen van het uitgaande internetverkeer van een node via een andere node is een exit node nodig.

Poorten sluiten die u niet langer nodig heeft

Zodra een beheerder de server via de tailnet bereikt, heeft de publieke poort 22 geen functie meer. Dit is het praktische voordeel: een gesloten poort kan niet worden aangevallen via brute force en uw logs raken niet langer gevuld met inlogpogingen.

De volgorde is van belang. Voeg eerst de tailnet-toegang toe, verifieer dat u via een tweede sessie kunt inloggen en verwijder pas daarna de publieke regel.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Verwijder daarna de publieke SSH-regel en maak opnieuw verbinding met behulp van de MagicDNS-naam. Let op wat ufw allow in on tailscale0 daadwerkelijk doet: het vertrouwt al het verkeer dat via de tunnel binnenkomt. Uw Tailscale-policybestand wordt daarmee de toegangscontrole in plaats van ufw. Houd hier rekening mee bij het schrijven van de policy.

Een waarschuwing voor iedereen die containers draait. Een gepubliceerde Docker-poort installeert eigen NAT-regels en omzeilt ufw, waardoor een ufw deny deze niet sluit. Docker gepubliceerde poorten die ufw omzeilen legt dit mechanisme uit. Door te publiceren naar het tailnet-adres, zoals hierboven beschreven, wordt dit omzeild.

Wat Tailscale beschermt en wat niet

Het is de moeite waard om dit helder te verwoorden, omdat de marketingversie de grens vervaagt.

Beschermd: verkeer tussen twee nodes is end-to-end versleuteld met WireGuard, en geen enkele relay in het midden kan dit lezen. Private keys verlaten nooit de machine die ze heeft gegenereerd. Nodes hebben geen inkomende publieke poort nodig, dus er is niets op poort 22 of 5432 dat het internet kan scannen. Toegang tussen nodes wordt bepaald door een beleidsbestand in plaats van door wie het adres kent.

Niet beschermd: de coördinatieserver ziet uw device graph. Die metadata is op zichzelf gevoelig, omdat machinenamen, eigenaren, adressen en online-tijden uw infrastructuur beschrijven. De server distribueert ook sleutels, wat het grotere risico vormt. Tailscale zegt het direct: "Als Tailscale kwaadwillend zou zijn en stiekem nieuwe nodes aan uw netwerk zou toevoegen, dan zou Tailscale verkeer naar uw bestaande nodes in leesbare tekst kunnen verzenden of ontvangen." Uw single sign-on provider bevindt zich in hetzelfde vertrouwenspad, omdat iedereen die daar een identiteit kan aanmaken, een node kan toevoegen. En een gecompromitteerde node is een peer binnen de tailnet, dus wat deze vervolgens kan bereiken, is afhankelijk van wat uw beleid toestaat. Of dit een acceptabel risico is, hangt af van tegen wie u zich verdedigt, en het volledige trust model loopt elk van die gevallen na, inclusief wat een gestolen identiteitsaccount daadwerkelijk kan doen.

Er zijn twee antwoorden op het risico van sleuteldistributie. Het eerste is tailnet lock, waarbij bestaande vertrouwde nodes een nieuwe node cryptografisch moeten ondertekenen voordat uw andere nodes deze accepteren. Een control plane die een node toevoegt zonder geldige handtekening wordt genegeerd. De admin console genereert de exacte tailscale lock init regel voor uw ondertekenende nodes, en elke node kan bevestigen wat deze ziet.

tailscale lock status

Alle nodes zouden dezelfde set vertrouwde ondertekeningssleutels moeten rapporteren. Het tweede antwoord is om de control plane zelf te draaien. Een zelfgehoste Headscale coördinatieserver spreekt hetzelfde protocol naar dezelfde clients, wat de device graph en de sleuteldistributie verplaatst naar hardware die u bezit. U bent dan ook verantwoordelijk voor de uptime van die server. Als u nog steeds zelfgehoste control planes vergelijkt in plaats van voor deze te kiezen, NetBird is een afzonderlijke mesh VPN waarvan u de server volledig op een eigen VPS draait.

Eén standaardinstelling die u op de eerste dag moet aanpassen. Een nieuwe tailnet wordt permissief uitgeleverd: "het standaard tailnet-beleidsbestand staat communicatie toe tussen alle apparaten binnen de tailnet." Zodra u een acls sectie toevoegt, verandert het model naar 'weigeren bij standaard' en worden alleen uw regels toegestaan.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Dat beleid staat tailnet-leden toe om SSH op getagde servers te bereiken en niets anders. Voeg per service een regel toe in plaats van de wildcard te laten staan, want de wildcard betekent dat één gestolen laptop-sleutel toegang geeft tot uw database.

Foutmodi en de meldingen die u zult zien

tailscale status geeft altijd relay aan. De twee nodes hebben nooit een direct pad opgebouwd. Voer tailscale netcheck uit aan beide kanten. UDP: false betekent dat UDP uitgaand wordt geblokkeerd, waardoor alleen een relay kan werken. MappingVariesByDestIP: true betekent dat een harde NAT in de weg zit; het toestaan van UDP 41641 inkomend aan de kant die u beheert, lost dit vaak op.

Een node die maandenlang werkte, is verdwenen. De node-sleutel is verlopen na de standaardtermijn van 180 dagen. De machine wordt als verlopen weergegeven in de beheerconsole en sudo tailscale up op de machine zelf herstelt de verbinding. Schakel het verlopen van sleutels op servers uit om dit te voorkomen.

Peers staan in de lijst, maar verbindingen lopen vast. De connectiviteit werkt, maar het beleid blokkeert het verkeer. Controleer de sectie acls voor een regel die deze bron, bestemming en poort dekt. Een geweigerd pakket wordt genegeerd in plaats van beantwoord; daarom krijgt u een time-out in plaats van Connection refused.

MagicDNS-namen worden niet omgezet. ping db-1 faalt terwijl ping 100.101.102.104 werkt. Iets heeft /etc/resolv.conf overschreven, waardoor zoekopdrachten de stub-resolver op 100.100.100.100 nooit bereiken. Controleer cat /etc/resolv.conf op 100.100.100.100 en kijk welke andere processen op de machine dat bestand aanpassen. Dit is hetzelfde type probleem als DNS-storing binnen een WireGuard-tunnel.

tailscale up weigert uw tag. De tag is niet gedeclareerd onder tagOwners in het beleidsbestand. Voeg deze daar toe en voer het commando opnieuw uit.

FAQ

Is Tailscale een VPN of een mesh-netwerk?

Beide termen zijn correct en beschrijven verschillende lagen. De tunnels maken gebruik van WireGuard, wat het een VPN maakt. De topologie is een mesh, omdat elk knooppunt direct een tunnel opbouwt naar elk ander knooppunt waarmee het communiceert, in plaats van elk pakket via één centrale server te sturen. De coördinatieserver bevindt zich in het controlepad, niet in het datapad. Als deze onbereikbaar wordt, blijven uw bestaande tunnels daarom gewoon verkeer verwerken. Wat tijdens een storing stopt, is het toevoegen van nieuwe knooppunten en het doorvoeren van wijzigingen in sleutels of beleid.

Kan Tailscale mijn verkeer inzien?

De inhoud niet. Verkeer wordt end-to-end versleuteld tussen knooppunten met WireGuard, privésleutels verlaten de knooppunten nooit en een DERP-relay stuurt pakketten door die het op geen enkele manier kan ontsleutelen. Tailscale ziet wel metadata: machinenamen, eigenaren, publieke sleutels, eindpuntadressen en wanneer elk knooppunt online is. Het distribueert ook sleutels, dus een gecompromitteerde coördinatieserver zou kunnen proberen een knooppunt toe te voegen dat uw netwerk vervolgens zou vertrouwen. Tailnet lock voorkomt dit door handtekeningen van uw eigen vertrouwde knooppunten te vereisen, en Headscale verwijdert het gehoste controlepaneel volledig uit de vergelijking.

Moet ik firewallpoorten openen voor Tailscale?

Vrijwel nooit voor inkomend verkeer. De richtlijn van Tailscale is dat u "meestal geen firewallpoorten hoeft te openen". Voor uitgaand verkeer heeft een knooppunt TCP 443 nodig naar de coördinatieserver en de relays, plus UDP 3478 voor STUN. Directe tunnels gebruiken UDP met een bronpoort die standaard op 41641 staat. Het toestaan van UDP 41641 voor inkomend verkeer is optioneel en helpt alleen om directe verbindingen op lastige netwerken te laten slagen.

Waarom kunnen andere knooppunten mijn service op poort 3000 niet bereiken?

Controleer eerst het bind-adres met ss -tlnp. Een listener op 127.0.0.1:3000 weigert verbindingen die aankomen op het 100.x tailnet-adres van het knooppunt, omdat die socket alleen de loopback-bestemming accepteert en de client Connection refused ziet. Bind de service aan het tailnet-adres of voer tailscale serve 3000 uit om het te proxen. Als de listener al op 0.0.0.0 staat en de verbinding time-out in plaats van wordt geweigerd, ligt de oorzaak bij een beleidsregel of een host-firewall in plaats van het bind-adres.

Moet ik Headscale draaien in plaats van de coördinatieserver van Tailscale?

Gebruik Headscale wanneer de apparaatgraaf of de sleuteldistributie op infrastructuur moet blijven die u zelf beheert, of wanneer het tailnet moet werken zonder afhankelijkheid van een externe dienst. De clients en het protocol zijn identiek. De keerzijde is dat u nu zelf de coördinatieserver beheert; bij een storing hiervan kunnen geen nieuwe knooppunten toetreden en worden beleidswijzigingen niet toegepast. Voor een klein netwerk is het gehoste controlepaneel met ingeschakelde tailnet lock meestal de betere keuze.