Tailscale: Bygg Zero Trust-VPN i 11 Steg [2026]

Kontorsnätverk med en enda brandväggsöppning och ett VPN-lösenord för alla anställda hör till det förflutna. När en anställd loggar in med samma VPN-koncentrator som tusen andra, och den koncentratorn i sin tur ger tillgång till hela det interna nätverket, räcker ett stulet lösenord för att en angripare ska kunna röra sig fritt. Tailscale löser problemet annorlunda: varje enhet får sin egen identitet, varje anslutning krypteras punkt till punkt med WireGuard, och åtkomst styrs av regler som aldrig litar på var du befinner dig i nätverket. Den här guiden visar hur du bygger ett sådant zero trust-nätverk med Tailscale från grunden, med riktiga kommandon, ACL-policyer, SSH-åtkomst och ett självhostat alternativ för dig som vill äga hela kontrollplanet själv.

Tailscale byggdes av två tidigare Google-ingenjörer, David Crawshaw och Avery Pennarun, som ett sätt att lösa ett problem de såg upprepas i företag efter företag. ”First, we found a pattern of business software that was written to trust the network, which had been made unsafe by a world where we can no longer trust physical networks,” säger Crawshaw i en intervju med Cybernews. Resten av artikeln går igenom exakt hur du undviker den fällan: installation, policyer, SSH, subnetroutrar, extern exponering och säkerhetsläget hösten 2026.

Guiden passar både den enskilda utvecklaren som vill nå sin hemserver från jobbet utan att öppna portar i routern, och IT-avdelningen som planerar att fasa ut en åldrande VPN-koncentrator till förmån för en modell som skalar bättre med distansarbete, molnvärdar på flera kontinenter och tillfälliga konsulter som bara ska ha åtkomst i några veckor. Samtliga kommandon nedan är testade mot den klientversion som gäller vid publiceringstillfället, och varje steg bygger vidare på föregående, så följ dem i ordning första gången du går igenom guiden.

Google · Föredragna källor

Missa inga nya tech-nyheter på Google

Lägg till Shattered en gång i Google-appen så syns våra artiklar i dina förslag.

Lägg till nu

Vad är Tailscale och varför slår zero trust en traditionell VPN

Tailscale är ett mesh-VPN byggt ovanpå WireGuard-protokollet. Istället för att skicka all trafik genom en central koncentrator bygger Tailscale krypterade punkt-till-punkt-tunnlar direkt mellan varje par av enheter som behöver prata med varandra. Ovanpå den WireGuard-grunden lägger Tailscale ett koordineringslager som sköter identitet, NAT-genomgång, nyckelutbyte och centraliserad policyhantering för hela din ”tailnet”, det samlade namnet på alla enheter som hör till ditt konto.

Skillnaden mot en traditionell VPN handlar om förtroendemodellen. En klassisk VPN-koncentrator ger oftast brett nätverksåtkomst så snart tunneln är uppe, vilket betyder att en kapad bärbar dator kan nå nästan allt. Zero Trust Network Access vänder på det. Varje anslutning verifieras individuellt mot identitet, enhetsstatus och en uttrycklig policy, oavsett om trafiken kommer från kontoret, hemmet eller ett café. Det här synsättet följer NIST:s ramverk SP 800-207 för zero trust-arkitektur, som bygger på kontinuerlig verifiering istället för att lita på nätverkets plats.

Tailscale-medgrundaren Avery Pennarun beskriver tanken bakom modellen rakt på sak: ”In a small network of humans or computers, if you can establish trust between them then most security problems will go away.” Han har också påpekat att resultatet ofta blir en bonus snarare än ett offer: ”What’s very strange about tailscale, and very strange in the security world in general, is that when you use tailscale to solve that problem, you accidentally make your system more secure”, enligt en intervju publicerad av Last Week in AWS. När det säkra alternativet blir det enklaste alternativet väljer de flesta anställda det automatiskt, utan att behöva tvingas dit med strikta regler.

WireGuard och Noise-protokollet i botten

WireGuard i sig är ett minimalistiskt tunnelprotokoll. Det använder Curve25519 för nyckelutbyte, ChaCha20 för kryptering av själva datan och Poly1305 för att verifiera att paketen inte manipulerats på vägen, allt samlat i ett handslag som bygger på Noise-protokollramverket. Fördelen med den enkelheten är att hela kodbasen är liten nog att granska i sin helhet, till skillnad från äldre VPN-stackar med decennier av tillägg och specialfall som sällan någon enda person längre förstår fullt ut.

Tailscale lägger inte till ett eget kryptoprotokoll ovanpå det. Istället hanterar bolagets kontrollplan fördelningen av WireGuard-nycklar mellan enheter, så att varje par av maskiner som behöver prata med varandra får sina publika nycklar utbytta automatiskt, utan att en administratör manuellt behöver klistra in nyckeltexter i konfigurationsfiler som i en klassisk WireGuard-installation. Nycklarna roteras periodiskt, och om en enhet tas bort ur tailnet slutar den omedelbart att vara betrodd av övriga enheter, eftersom kontrollplanet helt enkelt slutar dela ut dess nyckel till andra.

Hur en tailnet skiljer sig från ett klassiskt företagsnät

I ett klassiskt företagsnät definieras tillhörighet av fysisk plats: är du ansluten till kontorets switch eller har du en giltig VPN-session, så räknas du som ”intern”. En tailnet struntar helt i den distinktionen. Två kollegor kan sitta i samma rum på samma wifi och ändå kommunicera genom en krypterad WireGuard-tunnel som om de satt i olika länder, eftersom förtroendet är knutet till enheten och identiteten, inte till nätverkskabeln. Det låter kanske som ett onödigt steg när alla redan är i samma lokal, men det betyder också att en angripare som får fysisk åtkomst till kontorsnätet, till exempel genom ett löst uttag i ett konferensrum, inte automatiskt får något alls, eftersom hela det ”interna” nätet aldrig litade på nätverksplatsen i första hand.

Förutsättningar: det här behöver du innan du börjar

Innan du sätter igång behöver du några saker på plats. Listan nedan täcker både programvara och konton, så att du inte fastnar halvvägs genom installationen.

Tailscale-klient version 1.98.9 eller senare. Tailscales säkerhetsbulletin TS-2026-006 beskriver en brist i Tailscale SSH som åtgärdades i just den versionen, så kör aldrig en äldre klient i produktion.
Ett konto för inloggning via Google, Microsoft, GitHub eller ett eget SSO-system. Tailscale kräver inget separat lösenord, utan återanvänder en identitetsleverantör du redan litar på.
Linux-server med systemd, till exempel Ubuntu 22.04/24.04 eller Debian 12, för de steg som installerar Tailscale som nod på en server.
macOS 13 eller senare, respektive Windows 10/11 om du ska installera klienten på arbetsstationer.
Root- eller sudo-åtkomst på servrar där du ska aktivera IP-vidarebefordran för subnetroutrar och exit-noder.
Docker 24 eller senare om du vill följa Headscale-avsnittet och köra ditt eget kontrollplan.
Cirka 90 minuter om du följer samtliga steg i ordning, inklusive test och felsökning.

Steg 1 och 2: Skapa en tailnet och installera din första klient

Allt börjar med att registrera dig på tailscale.com och logga in med ett konto från en identitetsleverantör du redan använder. Det skapar automatiskt din första ”tailnet”, det namn Tailscale ger åt den samling enheter som delar policy och kryptografiskt förtroende under ditt konto. Nästa steg är att installera klienten på den första enheten, vilket på Linux görs enklast via det officiella installationsskriptet.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --accept-dns=true

Kommandot tailscale up skriver ut en inloggningslänk i terminalen. Öppna den i webbläsaren, godkänn enheten mot ditt konto, och enheten dyker upp i din tailnet inom några sekunder. På macOS och Windows laddar du istället ner klienten från Tailscales webbplats och loggar in genom det grafiska gränssnittet, men principen är identisk: enheten får en kryptografisk identitet knuten till ditt konto, inte till ett delat lösenord.

När klienten är igång tilldelas enheten en fast IP-adress inom intervallet 100.x.x.x, Tailscales interna CGNAT-utrymme, samt ett MagicDNS-namn som min-laptop.ditt-tailnet.ts.net. Verifiera att allt fungerar med:

tailscale status
tailscale ping min-laptop.ditt-tailnet.ts.net

Mobila klienter: iOS, Android och Chrome OS

Samma tailnet omfattar också mobila enheter. Installationen sker genom App Store respektive Google Play, och inloggningen följer exakt samma flöde som på datorn: öppna appen, välj identitetsleverantör, godkänn, och telefonen dyker upp i adminkonsolen som en vanlig nod. Det praktiska värdet syns tydligast när en anställd behöver komma åt ett internt administrationsgränssnitt eller en intern wiki från mobilen utan att företaget behöver bygga en separat mobil-VPN-lösning eller exponera tjänsten publikt bakom ett lösenord. Eftersom policyn ligger centralt i ACL-filen gäller exakt samma regler för mobilen som för den bärbara datorn, vilket sparar ett helt separat regelverk som annars ofta glöms bort eller hamnar på efterkälken när mobila enheter hanteras av ett annat verktyg än resten av nätverket.

Steg 3 och 4: Installera på en Linux-server och godkänn fler enheter

Nästa steg är att lägga till servrarna som ska vara en del av nätverket, till exempel en databasserver, en byggserver eller en NAS. Processen är identisk med enheten du redan satt upp, men du vill oftast ge servrar en tagg direkt vid installationen istället för att hantera dem som en vanlig användarenhet.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --advertise-tags=tag:server --ssh

Flaggan --advertise-tags kräver att taggen redan finns deklarerad i din ACL-policy (nästa steg), annars avvisar kontrollplanet begäran. Flaggan --ssh aktiverar Tailscale SSH direkt. I adminkonsolen under fliken ”Machines” ser du samtliga enheter, deras taggar, senaste anslutningstid och klientversion, vilket är en bra plats att kontrollera att ingen enhet fortfarande kör en gammal version innan du går vidare.

Steg 5: Bygg din ACL-policy med taggar och grupper

Det här är nätverkets verkliga hjärta. En Tailscale ACL (access control list) definierar exakt vilka användare, grupper, taggar eller enheter som får koppla upp mot vilka destinationer och portar, och kontrollplanet översätter policyn till regler för käll-IP, mål-IP och port under huven. Taggar används för att gruppera icke-mänskliga enheter, som servrar, molninstanser och nätverksutrustning, och en tagg måste först deklareras under tagOwners innan den kan användas i en regel.

Policyn redigeras som en textfil i adminkonsolen, under ”Access controls”. Ett realistiskt exempel för ett litet företag med utvecklare, en supportgrupp och en handfull servrar ser ut ungefär så här:

{
  "tagOwners": {
    "tag:server":    ["group:devops"],
    "tag:database":  ["group:devops"],
    "tag:exitnode":  ["group:devops"]
  },
  "groups": {
    "group:devops":  ["[email protected]", "[email protected]"],
    "group:support": ["[email protected]"]
  },
  "acls": [
    {
      "action": "accept",
      "src":    ["group:devops"],
      "dst":    ["tag:server:*", "tag:database:5432"]
    },
    {
      "action": "accept",
      "src":    ["group:support"],
      "dst":    ["tag:server:22"]
    }
  ],
  "ssh": [
    {
      "action": "check",
      "src":    ["group:devops"],
      "dst":    ["tag:server"],
      "users":  ["root", "autogroup:nonroot"]
    }
  ]
}

Lägg märke till att supportgruppen bara får nå port 22 på servrar, medan devops-gruppen får full åtkomst till både servrar och databasens port 5432. Det är precis den granulariteten som gör zero trust meningsfullt i praktiken: en kapad supportdator kan aldrig nå databasen, oavsett hur den anslöt till nätverket.

För större organisationer blir ACL-filen snabbt lång, och här är det värt att känna till några av de inbyggda hjälpvariablerna. autogroup:member syftar på alla inloggade användare oavsett grupp, vilket är användbart för regler som ska gälla alla anställda, medan autogroup:tagged syftar på alla enheter som har någon tagg, oavsett vilken. Wildcard-notationen tag:server:* betyder att samtliga portar på servern är öppna för den aktuella regeln, vilket bör användas sparsamt och bara för grupper som verkligen behöver bred åtkomst, eftersom varje wildcard-regel i praktiken är en liten lucka i annars granulär segmentering.

Steg 6: Aktivera Tailscale SSH för lösenordsfri åtkomst

Tailscale SSH applicerar din tailnet-policy direkt på SSH-anslutningar och begränsar vilka användare som får koppla upp mot vilka operativsystemkonton, utan att du behöver distribuera eller rotera separata SSH-nycklar. Det använder befintliga kontokonton på servern istället för att skapa egna SSH-användare, vilket gör funktionen enkel att infoga i en miljö som redan har en kontohanteringsprocess.

När du redan satt ssh-blocket i ACL-policyn ovan återstår bara att koppla upp med tailscale ssh istället för vanlig ssh:

tailscale ssh [email protected]

Autentiseringen sker mot din identitetsleverantör, inte mot en lösenordsfil eller en statisk nyckel, och varje session loggas centralt om du aktiverat flow-loggar (det kommer vi till längre ner). Viktigt att komma ihåg: just den här funktionen var målet för TS-2026-006, så dubbelkolla alltid klientversionen innan du förlitar dig på SSH-begränsningarna i produktion.

Steg 7: Konfigurera en subnetrouter för hela kontorsnätverket

Ibland vill du ge tailnet-åtkomst till enheter som inte själva kör Tailscale, exempelvis en gammal skrivare, en IoT-sensor eller ett helt internt IP-intervall på kontoret. Lösningen är en subnetrouter: en enhet i nätverket som annonserar en hel rutt till övriga tailnet.

sudo sysctl -w net.ipv4.ip_forward=1
sudo tailscale up --advertise-routes=192.168.1.0/24 --advertise-tags=tag:server

Innan rutten blir aktiv måste du godkänna den manuellt i adminkonsolen under ”Subnets”, vilket är en medveten säkerhetsspärr så att ingen kan annonsera en rutt till ett produktionsnät utan att en administratör klickar godkänn. Glömmer du ip_forward-inställningen kommer paket att nå servern men aldrig vidarebefordras, ett av de vanligaste misstagen i hela guiden, som vi återkommer till i fallgropsavsnittet.

Steg 8: Sätt upp en exit node för säker surfning på öppna nätverk

En exit node fungerar som motsatsen till en subnetrouter: istället för att ge åtkomst till ett internt nät, dirigerar den en klients hela internettrafik genom en annan enhet i tailnet, ungefär som en traditionell VPN-gateway. Det är praktiskt när en anställd sitter på ett öppet wifi-nätverk på en flygplats eller ett hotell och vill att all trafik ska lämna nätet via en betrodd punkt istället.

sudo tailscale up --advertise-exit-node
tailscale up --exit-node=exit-server.ditt-tailnet.ts.net --exit-node-allow-lan-access

Precis som subnetroutrar måste exit-noder godkännas av en administratör innan de syns som valbara för andra enheter. Flaggan --exit-node-allow-lan-access är användbar för resenärer som fortfarande behöver nå en lokal skrivare eller Chromecast samtidigt som internettrafiken går via exit-noden.

Steg 9: Exponera en tjänst säkert med Tailscale Funnel

Tailscale Funnel vänder på hela modellen tillfälligt: istället för att bara släppa in enheter i din tailnet, låter Funnel dig göra en specifik lokal tjänst nåbar från det öppna internet, via en Tailscale-hanterad TLS-ändpunkt, utan att öppna en port i brandväggen eller exponera resten av nätverket. Det är användbart för att dela en demo, ta emot en webhook från en extern tjänst, eller låta en kund testa en intern applikation tillfälligt.

sudo tailscale funnel --bg 443
tailscale funnel status

Till skillnad från subnetroutrar och exit-noder, som vidgar vem som får komma in i nätverket, gör Funnel exakt motsatsen för en enskild tjänst: den punkterar ett minimalt, namngivet hål utåt, medan resten av tailnet förblir precis lika stängt som innan. Använd funktionen sparsamt och stäng av den så snart demon eller testet är klart, eftersom varje aktiv Funnel-ändpunkt är en permanent attackyta så länge den körs.

Steg 10: Koppla in SSO, MFA och flödesloggar

Eftersom Tailscale återanvänder din befintliga identitetsleverantör ärver kontot automatiskt den multifaktorautentisering och de villkorliga åtkomstregler du redan har konfigurerat i exempelvis Google Workspace, Microsoft Entra ID eller Okta. Du behöver alltså inte bygga en separat MFA-lösning för nätverksåtkomst, bara se till att identitetsleverantören själv kräver MFA för alla konton, inklusive administratörer.

På de högre prisnivåerna kan du dessutom strömma flow-loggar, metadata om vilka enheter som pratat med varandra, till ett externt SIEM-system för granskning. Det ger ett spårbart revisionsspår utan att Tailscale själv behöver se innehållet i trafiken, eftersom all data redan är krypterad punkt till punkt mellan klienterna.

Steg 11: Headscale som självhostat alternativ till kontrollplanet

Allt ovan har förutsatt att du litar på Tailscales molnbaserade kontrollplan för att koordinera nycklar och policyer. Om organisationen av regulatoriska skäl, eller bara av princip, vill äga hela infrastrukturen själv finns Headscale, ett öppen källkod-projekt som implementerar en kompatibel kontrollserver som vanliga Tailscale-klienter kan ansluta till. Projektet har fortsatt aktiv utveckling, med en release taggad v0.29.5 enligt projektets egna GitHub-releasesida, och löpande arbete kring DNS, exit-noder, subnetroutrar och behörighetsregler.

Att komma igång med Headscale via Docker ser ut ungefär så här:

mkdir headscale && cd headscale
docker run -d --name headscale \
  -v $(pwd)/config:/etc/headscale \
  -v $(pwd)/data:/var/lib/headscale \
  -p 8080:8080 \
  headscale/headscale:latest headscale serve

docker exec headscale headscale users create mitt-foretag

Klienterna pekas sedan mot din egen server med tailscale up --login-server=https://din-server.exempel.se istället för Tailscales publika kontrollplan. Nackdelen är att du själv ansvarar för drift, patchning och tillgänglighet av kontrollservern, en avvägning som bara är rätt för organisationer som redan har kapacitet att driva kritisk infrastruktur dygnet runt.

I produktion bör Headscale-instansen placeras bakom en omvänd proxy med giltigt TLS-certifikat, snarare än att exponeras direkt på port 8080 som i exemplet ovan, och databasen som lagrar enhetsregistret bör säkerhetskopieras precis som alla andra kritiska datalager. Glöm inte heller att dokumentera vem i organisationen som har root-åtkomst till servern som kör Headscale, eftersom den personen i praktiken sitter på nycklarna till hela zero trust-nätverkets förtroendekedja, ett ansvar som annars ligger hos Tailscale när ni använder den molnbaserade varianten.

Headscales begränsningar jämfört med Tailscales molntjänst

Innan en organisation väljer den självhostade vägen är det värt att vara ärlig om vad som faktiskt byts bort. Tailscales molnbaserade kontrollplan sköter global nyckeldistribution, DERP-reläer för enheter som inte kan nå varandra direkt, och kontinuerlig drift över flera regioner, allt utan att ni behöver tänka på det. Headscale implementerar kärnfunktionerna i samma protokoll, men ni blir själva ansvariga för tillgänglighet, backup av databasen som lagrar enhetsregistret, och övervakning av att kontrollservern faktiskt svarar, eftersom hela tailneten slutar fungera för nya anslutningar om den egna Headscale-instansen går ner.

Headscale saknar också vissa av de funktioner som finns i de betalda Tailscale-nivåerna, som just-in-time-åtkomst och inbyggd rapportering via ett grafiskt gränssnitt, eftersom projektet i första hand fokuserar på att vara protokollkompatibelt med klienterna snarare än att återskapa hela admingränssnittet. För en organisation med starka krav på datasuveränitet, exempelvis en myndighet som inte får låta ett amerikanskt bolag koordinera sitt interna nätverk, kan den avvägningen fortfarande vara rätt, men det bör vara ett medvetet val snarare än ett som görs enbart för att spara licenskostnader.

Varför Norden behöver zero trust nu: VPN som attackyta

Traditionella VPN-koncentratorer har blivit ett av de mest utnyttjade måltavlorna för ransomware-grupper under 2026, och det är inte en slump. En koncentrator som Check Point, Cisco eller SonicWall sitter per definition exponerad mot internet, och en enda kritisk sårbarhet i den programvaran kan ge en angripare samma breda nätverksåtkomst som en legitim anställd skulle fått. Mönstret upprepar sig gång på gång i incidentrapporter: en obekant VPN-sårbarhet dyker upp, patchen släpps, men innan hela organisationen hunnit uppdatera har en angripare redan etablerat sig innanför den enda säkerhetsbarriären som fanns.

Zero trust-modellen begränsar skadan av just det scenariot på två sätt. Dels minskar den attackytan genom att inte ha en enda koncentrator som alla måste passera, vilket tar bort det mest frestande enskilda målet. Dels begränsar ACL-policyn vad en kapad identitet faktiskt kan nå, så att även om en angripare lyckas ta över ett konto blir skadan begränsad till precis de resurser det kontot redan hade behörighet till, snarare än hela nätet. Det är också därför NIS2-direktivet, som redan omfattar tusentals svenska företag inom kritisk infrastruktur, energi och transport, lyfter fram granulär åtkomstkontroll och spårbarhet som centrala krav snarare än bara kryptering i transit.

Det är värt att påpeka att zero trust inte eliminerar patchningsbehovet. Tailscales egen klient måste fortfarande uppdateras, vilket TS-2026-006 visade tydligt. Skillnaden är att konsekvenserna av att missa en patch blir mindre katastrofala, eftersom varje enhet och identitet redan är begränsad till ett minimum av vad den behöver, istället för att en enda sårbar koncentrator ger nyckeln till hela riket.

Tailscale jämfört med andra ZTNA-lösningar

Tailscale är inte ensamt i kategorin zero trust-nätverksåtkomst. Molnleverantörer som erbjuder en reverse proxy-baserad modell, där trafiken proxas genom leverantörens globala nätverk istället för att gå punkt till punkt, representerar ett annat arkitekturval. Den modellen passar bra för att skydda webbaserade interna applikationer utan att installera en klient alls, men ger i regel inte samma direktanslutning mellan enheter som ett mesh-nätverk gör, och kan innebära högre latens eftersom trafiken passerar leverantörens infrastruktur även när två enheter sitter i samma byggnad.

Andra verktyg i samma kategori fokuserar specifikt på administrativ åtkomst till servrar och databaser, med inbyggd sessionsinspelning och granulär behörighetshantering per databas eller kommando, snarare än att vara ett generellt nätverkslager för alla typer av enheter. Valet mellan de olika modellerna handlar i praktiken om vad organisationen redan har: ett team som bara behöver säker administratörsåtkomst till ett fåtal servrar kan klara sig med ett smalare verktyg, medan ett team som vill ersätta hela sitt interna nätverk, inklusive skrivare, IoT-enheter och mobila klienter, oftast är bättre betjänt av ett mesh-baserat alternativ som Tailscale eller det självhostade Headscale.

Ett praktiskt sätt att utvärdera vilken modell som passar är att kartlägga hur många av era interna system som faktiskt behöver nås av fler än en enda personalkategori. Om svaret är ”nästan allt, av nästan alla”, talar det för en bred mesh-lösning med en välskriven ACL-policy. Om svaret istället är ”ett fåtal specifika databaser, av ett fåtal specialister”, kan ett smalare verktyg med inbyggd sessionsgranskning vara enklare att införa och underhålla över tid, eftersom ni då slipper bygga upp ett helt taggsystem för resurser som bara ett par personer någonsin kommer röra.

Tailscale vs traditionell VPN: skillnaderna i praktiken

Tabellen nedan sammanfattar de praktiska skillnaderna mellan en traditionell VPN-koncentrator och ett mesh-baserat zero trust-nätverk som Tailscale, baserat på hur arkitekturerna faktiskt fungerar snarare än marknadsföringsmaterial.

Egenskap	Traditionell VPN	Tailscale (zero trust-mesh)
Trafikväg	All trafik genom en central koncentrator	Punkt-till-punkt direkt mellan enheter när möjligt
Åtkomst efter anslutning	Ofta brett nätverksåtkomst	Per enhet och port via ACL-policy
Protokoll	IPsec, OpenVPN eller SSL-VPN	WireGuard med Noise-baserat nyckelutbyte
Administration	Central brandväggskonfiguration	Deklarativ policyfil i adminkonsolen
Identitet	Delat lösenord eller certifikat	SSO mot befintlig identitetsleverantör
Extern exponering	Kräver portöppning eller reverse proxy	Tailscale Funnel för enskilda tjänster
Självhostat alternativ	Egen VPN-server	Headscale (öppen källkod)

Priser: vad kostar Tailscale i praktiken

Personal-nivån är gratis permanent, stödjer upp till sex användare, och inkluderar obegränsat antal enheter per användare samt upp till tre ACL-grupper, 50 taggade resurser och 1 000 minuter ephemeral-resurser per månad, vilket räcker gott för ett litet team eller en familj. För företag som växer ur den gränsen visar en genomgång av Tailscales egen prissida, publicerad av ssdnodes.com, att nästa betalda nivå kostar 8 dollar per användare och månad, medan Premium-nivån kostar 18 dollar per användare och månad och höjer gränsen till 300 ACL-grupper och 10 000 ephemeral-minuter per månad, samtidigt som den lägger till just-in-time-åtkomst, utökad Tailscale SSH, flow-loggar och regional routing. Enterprise-nivån saknar ett fast pris och förhandlas istället individuellt utifrån antal enheter, avtalslängd och servicenivåavtal.

Jämfört med den totala kostnaden för en traditionell VPN-lösning är bilden mer nyanserad än priset per användare ensamt antyder. En klassisk VPN-koncentrator kräver oftast dedikerad maskinvara eller en virtuell instans som ska driftas, licenser som förnyas årligen, samt arbetstid för att hantera certifikat, brandväggsregler och kapacitetsplanering när antalet samtidiga anslutningar växer. Tailscales modell flyttar en stor del av den driftskostnaden till leverantören, vilket gör att den fasta månadskostnaden per användare i praktiken ofta konkurrerar väl med den dolda driftskostnaden av en egen koncentrator, särskilt för organisationer som annars hade behövt anställa eller avsätta en hel tjänst för att sköta VPN-infrastrukturen löpande.

Nivå	Pris	ACL-grupper	Extra funktioner
Personal	0 dollar, upp till 6 användare	3	Grundläggande ACL, MagicDNS
Nästa nivå (betald grundnivå)	8 dollar/användare/månad	Högre gräns än Personal	Fler taggade resurser
Premium	18 dollar/användare/månad	300	Just-in-time-åtkomst, flow-loggar, regional routing
Enterprise	Anpassad prissättning	Förhandlingsbart	SLA, dedikerad support, anpassade avtal

Säkerhetsläget hösten 2026: CVE, patchar och zero trust-anpassning

Säkerhetsbulletinen TS-2026-006 är det viktigaste du bör känna till just nu om du redan kör Tailscale SSH i produktion. Bristen handlade om att Tailscale SSH accepterade numeriska användar-ID:n, vilket gjorde att en användare med icke-root SSH-åtkomst i teorin kunde adressera UID 0 och därmed nå root trots att ACL-policyn uttryckligen skulle ha nekat det. Tailscale beskriver att den underliggande otydligheten åtgärdades via kontrollplanet för samtliga klienter redan den 29 oktober 2025, och att klientuppdateringar därefter släpptes för att avvisa rent numeriska användarnamn och UID:n. Fixen ingår i version 1.98.9 eller senare, vilket är ännu ett skäl att alltid tvinga fram klientuppdateringar centralt istället för att förlita sig på att varje anställd uppdaterar manuellt.

Ur ett bredare perspektiv speglar hela den här bristen varför zero trust-tänket är mer än ett modeord. Policyn i sig var korrekt skriven, men implementationen av hur den tolkade identiteter innehöll en lucka, precis det scenario som kontinuerlig verifiering och minsta-möjliga-behörighet ska begränsa skadan av. En angripare som utnyttjat luckan hade ändå varit begränsad till de specifika servrar som det kapade kontot redan hade ACL-åtkomst till, snarare än att kunna röra sig fritt över hela nätverket som i en traditionell flat VPN-topologi.

Det här mönstret, att en leverantör själv hittar och åtgärdar en brist innan den blir allmänt känd och utnyttjad i stor skala, är i grunden det bästa scenariot i säkerhetsbranschen, men det befriar inte driftansvariga från eget ansvar. En organisation som aldrig uppdaterar sina klienter centralt, utan förlitar sig på att varje anställd själv trycker på uppdateringsknappen, kommer statistiskt alltid ha en andel enheter som ligger kvar på en sårbar version veckor eller månader efter att patchen släppts. Bygg därför in automatiska klientuppdateringar som en del av er standardkonfiguration redan vid utrullning, snarare än att behandla det som ett separat projekt att ta tag i senare.

Vanliga fallgropar att undvika

Glömma att aktivera IP-vidarebefordran. Utan net.ipv4.ip_forward=1 annonserar subnetroutern en rutt som aldrig faktiskt vidarebefordrar paket, vilket ger tyst dataförlust snarare än ett tydligt felmeddelande.
Annonsera en rutt men glömma att godkänna den. Både subnetroutrar och exit-noder måste manuellt godkännas i adminkonsolen, och många administratörer missar det steget och undrar varför rutten inte dyker upp hos andra klienter.
Köra olika klientversioner i produktion. En blandning av gamla och nya klienter gör det svårt att veta om hela nätet faktiskt skyddas av senaste säkerhetsfixarna, som i fallet med TS-2026-006.
Skriva alltför breda ACL-regler ”för att slippa problem”. En regel som "dst": ["*:*"] för en hel grupp eliminerar hela poängen med zero trust och återskapar i praktiken en traditionell flat VPN.
Lämna en Funnel-ändpunkt aktiv permanent för en tjänst som bara behövde delas tillfälligt, vilket skapar en bestående attackyta utan affärsvärde.
Inte deklarera taggen i tagOwners innan den används. Kontrollplanet avvisar annars --advertise-tags-kommandot med ett felmeddelande som är lätt att missförstå som ett nätverksproblem.
Glömma MFA på identitetsleverantören. Eftersom Tailscale ärver autentiseringen från SSO-leverantören blir hela nätverkets säkerhet bara så stark som den svagaste länken i den identitetskedjan. Ett konto utan MFA är fortfarande ett konto utan MFA, oavsett hur väl skriven ACL-policyn är.
Behandla taggade enheter som permanenta utan att se över dem. En testserver som fick taggen tag:server för ett halvårs sedan behåller sin åtkomst för evigt om ingen rensar bort den, vilket med tiden skapar precis den typen av bortglömd attackyta som zero trust-modellen var tänkt att eliminera.
Dela ACL-filen i ett delat dokument utanför versionskontroll. Policyn bör behandlas som infrastrukturkod, med historik och granskning via pull request, inte redigeras direkt i adminkonsolen av vem som råkar ha behörighet den dagen.

Felsökning: vanliga problem och lösningar

Nedan är de problem som oftast dyker upp när ett team sätter upp Tailscale för första gången, tillsammans med konkreta kommandon för att diagnostisera dem.

”Connection refused” trots att status visar online. Kontrollera att ACL-policyn faktiskt tillåter trafiken med tailscale status och jämför mot din policyfil. Ett nej i ACL ger exakt samma nätverksbeteende som en stängd brandvägg.
Subnetrouter syns inte som valbar rutt. Gå till adminkonsolens flik ”Subnets” och kontrollera att rutten faktiskt är godkänd, inte bara annonserad.
Tailscale SSH nekar anslutning trots korrekt ACL. Kör tailscale ssh med -v-flaggan och verifiera att klienten är uppdaterad till minst 1.98.9, särskilt efter TS-2026-006.
Exit-noden fungerar men lokal utskrift slutar funka. Lägg till flaggan --exit-node-allow-lan-access så att lokalt nätverk fortfarande är nåbart samtidigt som internettrafiken går via exit-noden.
MagicDNS löser inte namn korrekt. Kontrollera att --accept-dns=true sattes vid uppkoppling, och att klientens egna DNS-inställningar inte skriver över Tailscales DNS-konfiguration.
Headscale-klienter kan inte registrera sig. Verifiera att --login-server-flaggan pekar mot exakt rätt URL inklusive protokoll, och att TLS-certifikatet på Headscale-instansen är giltigt.
Funnel fungerar lokalt men inte från internet. Kontrollera med tailscale funnel status att tjänsten faktiskt är exponerad, och att brandväggen inte blockerar utgående anslutningar som behövs för att etablera Funnel-relän.
Taggad server visas som ”needs approval” permanent. Det betyder oftast att taggen i --advertise-tags inte matchar en tagg som redan är deklarerad i tagOwners, eller att användaren som kör kommandot inte äger taggen.
Klienten verkar hänga på ”Starting Tailscaled” vid uppstart. Kontrollera att tjänsten faktiskt är aktiverad i systemd med systemctl status tailscaled, och starta om den med sudo systemctl restart tailscaled om den av någon anledning kraschat tyst vid serverns senaste omstart.
Två enheter ser varandra online men trafiken är långsam. Kör tailscale ping mellan dem och se om anslutningen går direkt eller via ett DERP-relä. Om anslutningen reläas trots att båda enheterna borde kunna nå varandra direkt, kontrollera att inga symmetriska NAT-brandväggar blockerar den UDP-trafik WireGuard behöver för en direktanslutning.

Avancerade tips för produktionsmiljöer

När grundkonfigurationen är på plats finns ett antal justeringar som gör skillnad i en större organisation. Använd autogroup:member och autogroup:tagged i policyn istället för att räkna upp enskilda e-postadresser, så att nya anställda automatiskt får korrekt åtkomst den dag de läggs till i identitetsleverantören, utan att någon behöver komma ihåg att uppdatera ACL-filen manuellt.

För team som kör containrar eller Kubernetes-kluster finns ett sidecar-mönster där Tailscale körs som en egen container i samma pod eller nätverksnamnrymd, vilket ger varje arbetsbelastning sin egen tailnet-identitet utan att hela noden behöver exponeras. Kombinera det med korta, ephemeral-nycklar för CI/CD-pipelines, så att en byggagent automatiskt försvinner ur tailnet när jobbet är klart istället för att lämna en permanent, oanvänd enhet kvar i policyn.

Exportera flow-loggar till det SIEM-system ni redan använder för övrig säkerhetsövervakning, istället för att låta dem bli ett isolerat verktyg som bara en person i teamet tittar på. Zero trust-modellen ger bättre data att korrelera mot, men bara om den datan faktiskt flödar in i samma larmkedja som resten av incidenthanteringen.

Separera dessutom ACL-policyn för produktionsmiljön från den för utvecklings- och testmiljön, även om båda körs inom samma tailnet. Ett enkelt sätt är att ge produktionsservrar en egen tagg, exempelvis tag:prod-server, med en strängare regel som bara devops-gruppen får nå, medan en bredare tag:dev-server-regel tillåter fler utvecklare att experimentera fritt i testmiljön. Det förhindrar att ett misstag i en testmiljö av misstag ger bred åtkomst till produktionsdata, ett mönster som annars lätt smyger sig in när hela teamet ursprungligen bara hade en enda, odifferentierad devops-grupp.

Slutligen bör policyfilen granskas med samma regelbundenhet som en brandväggskonfiguration. Sätt upp en återkommande påminnelse, kvartalsvis eller vid varje större personalförändring, för att gå igenom vilka taggar, grupper och regler som faktiskt fortfarande behövs. En ACL-policy som aldrig krymper, bara växer, tenderar över tid att samla på sig regler som en gång var motiverade men som ingen längre minns varför de finns kvar.

Komplett färdigt projekt: hela konfigurationen i sammanfattning

Sätter du ihop stegen ovan får du ett fullständigt fungerande zero trust-nätverk med följande komponenter: en tailnet med godkända klienter på bärbara datorer och servrar, en ACL-policy som separerar devops från support ned till portnivå, Tailscale SSH för lösenordsfri serveråtkomst, en subnetrouter som exponerar det interna 192.168.1.0/24-nätet, en exit-node för resande anställda, en tillfällig Funnel-ändpunkt för demos, SSO/MFA ärvt från den befintliga identitetsleverantören, och, om ni valt den vägen, en självhostad Headscale-instans istället för Tailscales molnbaserade kontrollplan.

Den fullständiga ACL-filen för projektet, redo att klistras in i adminkonsolen eller i Headscales konfiguration, ser ut så här i sin helhet:

{
  "tagOwners": {
    "tag:server":    ["group:devops"],
    "tag:database":  ["group:devops"],
    "tag:exitnode":  ["group:devops"]
  },
  "groups": {
    "group:devops":  ["[email protected]", "[email protected]"],
    "group:support": ["[email protected]"]
  },
  "acls": [
    { "action": "accept", "src": ["group:devops"],  "dst": ["tag:server:*", "tag:database:5432"] },
    { "action": "accept", "src": ["group:support"], "dst": ["tag:server:22"] },
    { "action": "accept", "src": ["autogroup:member"], "dst": ["tag:exitnode:*"] }
  ],
  "ssh": [
    { "action": "check", "src": ["group:devops"], "dst": ["tag:server"], "users": ["root", "autogroup:nonroot"] }
  ]
}

Testa alltid en policyändring med kommandot tailscale status och en kontrollanslutning innan den rullas ut till hela organisationen, och håll en administratörssession öppen i ett separat fönster medan nya regler testas, så att ingen låser sin egen åtkomst om en regel visar sig vara för restriktiv.

Vanliga frågor

Är Tailscale gratis att använda?
Ja, Personal-nivån är permanent gratis för upp till sex användare och ett obegränsat antal enheter per användare, vilket räcker för de flesta privatpersoner, hemmanätverk och mycket små team.

Behöver jag öppna portar i brandväggen för att använda Tailscale?
Nej. Tailscale bygger på WireGuard och använder NAT-genomgångstekniker för att etablera direktanslutningar även bakom restriktiva brandväggar, utan att manuellt öppna inkommande portar.

Vad är skillnaden mellan en subnetrouter och en exit-node?
En subnetrouter ger tailnet åtkomst till ett internt IP-intervall, medan en exit-node gör motsatsen genom att dirigera en klients hela internettrafik via en annan enhet i nätverket.

Kan Tailscale köras helt utan Tailscales moln?
Ja, via Headscale, ett öppen källkod-projekt som implementerar ett kompatibelt kontrollplan som du själv hostar och ansvarar för, med standardklienterna oförändrade.

Är Tailscale SSH säkrare än vanlig SSH med nycklar?
Tailscale SSH centraliserar policyn och kopplar den till samma identitet som resten av nätverket, vilket eliminerar risken för kvarglömda eller läckta statiska SSH-nycklar, men förutsätter samtidigt att klienten alltid hålls uppdaterad, vilket TS-2026-006 visade varför.

Kräver Tailscale Funnel ett betalt konto?
Funnel är tillgängligt även på lägre nivåer, men varje exponerad ändpunkt bör stängas av så snart den tillfälliga användningen är klar, oavsett prisnivå, för att inte lämna en onödig attackyta öppen.

Fungerar Tailscale med Kubernetes?
Ja, genom ett sidecar-mönster där Tailscale körs som en egen container inom samma pod, vilket ger enskilda arbetsbelastningar en egen tailnet-identitet utan att hela klustrets nätverk behöver exponeras.

Vad händer om en ACL-regel skrivs för brett av misstag?
Nätverket fungerar fortfarande tekniskt, men hela säkerhetsvinsten med zero trust försvinner eftersom en kapad enhet då kan nå mer än den borde. Testa alltid nya regler i en separat session innan de rullas ut brett, och granska policyn regelbundet precis som en brandväggskonfiguration skulle granskas.

Ersätter Tailscale behovet av en traditionell brandvägg helt?
Nej. Tailscale styr åtkomst mellan enheter i tailnet, men servrar bör fortfarande ha en lokal brandvägg som bara tillåter trafik från Tailscales nätverksgränssnitt, så att ett misstag i Tailscale-konfigurationen inte automatiskt exponerar tjänsten mot hela det öppna internet.

Kan flera team dela samma tailnet utan att se varandras trafik?
Ja, så länge ACL-policyn är skriven för att separera dem. Tailnet-medlemskap i sig ger ingen åtkomst alls mellan enheter, det är uteslutande ACL-reglerna som avgör vem som faktiskt kan nå vad, vilket gör det fullt möjligt att låta flera avdelningar dela samma tailnet utan att de kan nå varandras resurser.

Hur vet jag om min organisation är redo att byta bort den gamla VPN-koncentratorn helt?
Ett bra tecken är att ni redan vet exakt vilka anställda och system som behöver nå vilka resurser, eftersom det är precis den kartläggningen som blir er ACL-policy. Organisationer som istället förlitar sig på att ”alla som är inloggade på VPN:et får nå allt” bör göra kartläggningen som ett separat förarbete innan migreringen, snarare än att försöka göra den samtidigt som den tekniska övergången.