Tailscale subnet router op een VPS instellen

Wat een Tailscale subnet router doet

Een Tailscale subnet router is één machine die een volledig bereik van private IP-adressen adverteert aan uw tailnet, zodat elk apparaat op het tailnet adressen in dat bereik kan bereiken, zelfs als daar geen Tailscale op draait. Uw tailnet is uw private Tailscale-netwerk: de verzameling apparaten die zijn aangemeld bij één account of organisatie. Een exit node is de functie waarmee dit vaak wordt verward, maar deze voert de tegenovergestelde taak uit. Deze stuurt al het verkeer van een apparaat via de VPS naar buiten, waardoor de VPS de route van dat apparaat naar het publieke internet wordt.

Eén zin per punt. Een subnet router maakt een privaat netwerk bereikbaar vanaf het tailnet. Een exit node verandert het punt waar uw publieke verkeer het netwerk verlaat. Als u de tweede optie zoekt, lees dan hoe u een Tailscale exit node op een VPS draait in plaats daarvan. Het zijn afzonderlijke flags en één VPS kan beide tegelijk uitvoeren, maar ze lossen verschillende problemen op en falen op verschillende manieren.

Wanneer een VPS een subnetrouter nodig heeft

Het meest voorkomende scenario is een privaat netwerk dat u al van uw provider heeft gekregen. Uw VPS heeft een publiek adres en een tweede interface op een privaat segment, terwijl de andere servers op dat segment helemaal geen publiek adres hebben: een database op 10.0.0.20, een back-updoel op 10.0.0.30. Installeer Tailscale op één VPS, adverteer 10.0.0.0/24, en uw laptop bereikt die private adressen direct. Er verandert niets anders op het segment en de database heeft nog steeds geen publiek adres.

Het andere scenario is een netwerk aan de andere kant van de VPS. Een LAN (lokaal netwerk) bij u thuis of op kantoor achter een eigen router, of een rack met apparatuur waarop Tailscale niet kan draaien, zoals een managed switch of een oude NAS met vergrendelde firmware. Eén Linux-machine op dat netwerk fungeert dan als subnetrouter voor al het overige verkeer.

Beide scenario's hebben één vereiste gemeen. De subnetrouter moet het bereik dat hij adverteert al kunnen bereiken via zijn eigen routeringstabel en firewall. Tailscale bouwt die verbinding niet zelf op. Het transporteert verkeer naar de router en draagt dit over aan de kernel voor verdere afhandeling.

Tailscale installeren en het lokale pad controleren

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

Het script detecteert de distributie, voegt de pakketrepository van Tailscale toe, installeert het tailscale-commando en de tailscaled-daemon, en schakelt vervolgens de service in. Bevestig dit met systemctl is-active tailscaled; dit zou active moeten retourneren.

Controleer voordat u verdergaat of de VPS het netwerk kan bereiken dat u wilt adverteren.

ip route show
ping -c3 10.0.0.20

ip route show moet het privébereik op een fysieke interface tonen, bijvoorbeeld 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Als de ping hier, op de router zelf, mislukt, zal geen enkele Tailscale-vlag dit oplossen. Het probleem ligt dan bij de netwerkconfiguratie van de VPS of een firewall op de doelhost. Los dit eerst op, aangezien elke volgende test hiervan afhankelijk is.

IP-forwarding inschakelen en persistent maken na een herstart

Een Linux-machine negeert elk pakket dat niet aan het eigen adres is gericht, tenzij forwarding is ingeschakeld. Het doorsturen van pakketten van andere machines is de kerntaak van een subnet-router; deze stap is daarom verplicht.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Controleer de status met sysctl net.ipv4.ip_forward; dit zou net.ipv4.ip_forward = 1 moeten retourneren.

Deze stap wordt vaak slechts gedeeltelijk uitgevoerd. sudo sysctl -w net.ipv4.ip_forward=1 werkt direct, maar de instelling gaat verloren bij de volgende herstart. Hierdoor kan de subnet-router wekenlang functioneren, om vervolgens na een kernel-update en herstart plotseling te stoppen. Het verwarrende is dat er niets defect lijkt. tailscale status toont de node nog steeds als online, de admin-console geeft aan dat de route is goedgekeurd en clients hebben de route nog steeds geïnstalleerd. Pakketten komen aan bij de VPS, maar de kernel negeert ze zonder enige logging. Door de waarden naar /etc/sysctl.d/99-tailscale.conf te schrijven, blijven ze behouden na een herstart.

Als u routes adverteert terwijl forwarding is uitgeschakeld, waarschuwt tailscale up u op dat moment met een regel die lijkt op Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. Lees de uitvoer van dat commando in plaats van er voorbij te scrollen.

Routes adverteren

sudo tailscale up --advertise-routes=10.0.0.0/24

Wijzig de instelling op een VPS die al is aangemeld bij uw tailnet:

sudo tailscale set --advertise-routes=10.0.0.0/24

Gebruik tailscale set voor elke latere wijziging. Het opnieuw uitvoeren van tailscale up met slechts één vlag reset de vlaggen die u niet opnieuw opgeeft, waarna de CLI een foutmelding geeft dat het wijzigen van instellingen op deze manier vereist dat alle niet-standaard vlaggen worden vermeld. tailscale set wijzigt één instelling en laat de rest ongewijzigd.

Meerdere bereiken kunnen in één door komma's gescheiden lijst zonder spaties worden ingevoerd: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Elk item moet een netwerkadres in CIDR-notatie zijn (classless inter-domain routing, de 10.0.0.0/24-vorm). Het per ongeluk invoeren van uw eigen hostadres, 10.0.0.5/24, wordt geweigerd omdat de bits na het voorvoegsel niet nul zijn; de foutmelding noemt het voorvoegsel dat u waarschijnlijk bedoelde. Om het adverteren te stoppen, stelt u een lege lijst in met sudo tailscale set --advertise-routes=.

Keur de route goed in de admin console

Het adverteren van een route is een verzoek, geen wijziging. Zolang een beheerder dit niet goedkeurt, ontvangt geen enkele client de route en is niets binnen het bereik bereikbaar. Dit is een bewuste keuze, omdat een machine die zichzelf kan toevoegen aan de routeringstabel van iedereen, verkeer voor elk gewenst bereik kan onderscheppen.

Keur de route goed op de pagina Machines van de admin console. De VPS wordt daar vermeld met een subnet-badge. Open de betreffende rij, zoek de sectie subnets, bewerk de route-instellingen, vink de route aan en sla de wijzigingen op.

Goedkeuring vindt plaats per prefix. Adverteert u vandaag 10.0.0.0/24 en volgende maand 192.168.50.0/24, dan komt de nieuwe prefix ongeautoriseerd binnen terwijl de oude prefix blijft werken. Een goedgekeurde route en een genegeerde route zien er vanaf de VPS identiek uit; controleer daarom de console voordat u andere zaken gaat debuggen.

U kunt deze handmatige stap overslaan met een autoApprovers-blok in het tailnet-beleidsbestand:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Start de node vervolgens op met die tag, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, en de route wordt goedgekeurd zodra deze wordt geadverteerd. De tag moet eerst bestaan in de tagOwners-sectie van hetzelfde beleidsbestand. Dit is nuttig om in te stellen als u de VPS opnieuw opbouwt vanuit een script, omdat een opnieuw opgebouwde node als een nieuwe node wordt beschouwd en de routes daarvan standaard weer ongeautoriseerd zijn.

Waarom Linux-clients de route negeren zonder --accept-routes

De route wordt nu geadverteerd en goedgekeurd. Uw telefoon en uw Mac kunnen 10.0.0.20 bereiken. Uw Linux-laptop kan dit niet, en er is niets in de beheerconsole dat op een probleem wijst.

Het accepteren van een subnetroute betekent dat er vermeldingen in de routeringstabel van de client worden geschreven. Op Android, iOS, macOS, tvOS en Windows doet de Tailscale-client dit voor u. Op Linux gebeurt dit niet, omdat een Linux-machine vaak een server of router is waarvan de routeringstabel bewust is geconfigureerd. Het stilletjes invoegen van een /24 die via het netwerk is geleerd, zou verkeer dat de machine al afhandelt kunnen verstoren. Daarom kiest u op Linux per client expliciet voor deze optie:

sudo tailscale set --accept-routes

Controleer vervolgens waar de route is terechtgekomen:

ip route show table 52
ip route get 10.0.0.20

Tailscale op Linux plaatst geaccepteerde routes niet in de hoofdrouteringstabel. Het plaatst deze in routeringstabel 52 en installeert beleidsregels, zichtbaar met ip rule show in het prioriteitsbereik 5210 tot 5270, die niet-overeenkomende pakketten naar die tabel sturen. Daarom zal ip route show op zichzelf nooit 10.0.0.0/24 weergeven, en een lezer die alleen dat commando controleert, concludeert dat --accept-routes niets heeft gedaan. ip route show table 52 is het commando dat de waarheid toont, en dit zou het geadverteerde bereik op tailscale0 moeten weergeven.

Eén uitzondering is het vermelden waard. Als dit Linux-knooppunt zelf een tweede subnetrouter is voor zijn eigen lokale netwerk, zorgt --accept-routes ervoor dat het verkeer voor zijn eigen direct verbonden subnet via de andere router stuurt in plaats van via zijn eigen interface. Laat op een stand-by router in een high-availability-paar --accept-routes uitgeschakeld en adverteer alleen.

Foutmodus: twee routers adverteren overlappende bereiken

Twee subnet-routers mogen geen identieke bereiken adverteren. Overlappende bereiken met verschillende prefixlengtes zijn toegestaan, waarbij Tailscale de meest specifieke match kiest. Als router A 10.0.0.0/24 adverteert en router B 10.0.0.0/16, gaat verkeer naar 10.0.0.20 naar A.

Wat gebruikers vaak verrast, is het gedrag wanneer A offline gaat. Tailscale schakelt niet terug naar de minder specifieke route. Verkeer naar 10.0.0.20 stopt, terwijl verkeer naar 10.1.0.20 via B blijft werken. Het symptoom lijkt op een gedeeltelijk onbereikbaar privénetwerk, terwijl de oorzaak is dat een offline node de meer specifieke prefix vasthoudt. Als u failover wilt, laat de router met het bredere bereik dan ook de nauwere prefixen adverteren, zodat beide routers dezelfde adressen dekken.

De andere vorm van overlap treedt dichter bij de client op. Wanneer u zich op een hotelnetwerk bevindt op 192.168.1.0/24 terwijl uw subnet-router 192.168.1.0/24 adverteert, concurreren beide om dezelfde bestemmingen. Welke route wint, hangt af van het platform. Installeer op Linux een regel vóór die van Tailscale zelf, zodat lokale adressen de hoofdtabel gebruiken:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Die regel is niet persistent en verdwijnt bij de volgende reboot. De definitieve oplossing is het kiezen van een privébereik dat u in het wild niet zult tegenkomen. 192.168.0.0/24 en 192.168.1.0/24 zijn de standaardinstellingen op de meeste thuisrouters; kies daarom bewust iets binnen 10.0.0.0/8. Dezelfde botsing verstoort een standaard WireGuard VPN die u handmatig configureert, om dezelfde reden: de meer specifieke lokale route wint, waardoor het verkeer de tunnel nooit bereikt.

Foutmodus: DNS verwijst naar een adres zonder route

Dit probleem is lastig te debuggen, omdat er geen foutmelding wordt gegenereerd. De naam wordt omgezet, maar de verbinding loopt vast door een time-out.

Stel dat db.internal.example.com via uw private nameserver wordt omgezet naar 10.0.5.20, en u heeft 10.0.0.0/24 geadverteerd. De opzoekopdracht slaagt, omdat DNS (domain name system) resolutie en IP-routing gescheiden stappen zijn die elkaar niet controleren. Het pakket naar 10.0.5.20 vindt vervolgens geen overeenkomende route op de tailnet, verlaat het netwerk via de standaardgateway van de client en gaat verloren.

Twee commando's scheiden deze twee helften:

nslookup db.internal.example.com
ip route get 10.0.5.20

Als de opzoekopdracht een adres retourneert, maar ip route get niet antwoordt met dev tailscale0, dan is de naam correct maar ontbreekt de route. Adverteer een bereik dat het adres dekt, hetzij 10.0.0.0/16 of een tweede expliciet prefix, en keur daarna het nieuwe prefix goed in de console.

Er is een vergelijkbare valkuil op de nameserver zelf. Als u in de admin-console een globale nameserver instelt op een privaat adres zoals 10.0.0.53, dan moet dat adres binnen een goedgekeurde route vallen, anders kunnen uw apparaten de resolver helemaal niet bereiken. Schakel de optie in die lokale DNS-servers overschrijft terwijl u naar een onbereikbare resolver wijst, en elk apparaat in de tailnet verliest direct de naamresolutie, inclusief de apparaten die een seconde eerder nog werkten. Adverteer en keur eerst de route naar de resolver goed, en wijzig daarna de DNS-instelling. Als DNS binnen een tunnel het onderdeel is waar u tegen blijft vechten, dan behandelt de manier waarop DNS breekt over een WireGuard tunnel hetzelfde mechanisme zonder de coördinatielaag daarboven.

Source NAT en site-to-site verbindingen

Standaard herschrijft de subnet router het bronadres van elk doorgestuurd pakket naar zijn eigen privéadres. Dit is SNAT (source network address translation). Het is aanwezig zodat antwoorden werken zonder wijzigingen op het privénetwerk: de database op 10.0.0.20 antwoordt aan de VPS, die hij al weet te bereiken. Het nadeel is dat de database elke tailnet-verbinding ziet als afkomstig van de VPS, waardoor firewallregels per bron en toegangslogs geen bruikbare informatie bevatten.

Schakel dit op Linux uit wanneer u wilt dat het werkelijke tailnet-adres van de client behouden blijft:

sudo tailscale set --snat-subnet-routes=false

De hosts op het privénetwerk hebben vervolgens een route nodig terug naar 100.64.0.0/10, het bereik dat Tailscale toewijst aan apparaten, wijzend naar de subnet router. Zonder deze retourroute gaan hun antwoorden naar de standaardgateway en komen ze nooit aan, waardoor verbindingen na het eerste pakket blijven hangen. Voeg de statische route toe op de gateway van het privénetwerk, of laat SNAT ingeschakeld.

Een site-to-site verbinding bestaat uit twee subnet routers die dit tegelijkertijd doen, waarbij elk zijn eigen netwerk adverteert en dat van de ander accepteert:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Voer het bijbehorende commando uit op de andere router met zijn eigen bereik. De twee bereiken moeten verschillend zijn. Als grote bestandsoverdrachten vastlopen terwijl ssh en ping in orde zijn, is de oorzaak MSS (maximum segment size), het grootste gegevensblok dat een TCP-pakket kan bevatten. De overhead van de tunnel maakt doorgestuurde pakketten te groot voor een verbinding in het midden, en clamping lost dit op:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sla die regel op met iptables-persistent, anders verdwijnt deze bij de volgende opstart.

Onderhoud voor een stabiele werking

Node-keys verlopen standaard na 180 dagen, sinds augustus 2026. Wanneer de key op een subnet router verloopt, meldt de node zich af en wordt het volledige geadverteerde bereik onbereikbaar, zonder dat een configuratiewijziging dit verklaart. Schakel het verlopen van keys voor deze machine uit op de Machines-pagina van de admin console en noteer dat u dit heeft gedaan.

Tailscale geeft de voorkeur aan een directe verbinding tussen peers en valt terug op relay-servers wanneer dit niet lukt. De relays werken, maar voegen latentie toe. Een VPS met een publiek adres is het eenvoudigste scenario: sta inkomend UDP 41641 toe en de meeste peers maken direct verbinding. Als ufw de firewall beheert, behandelt de ufw-regels die een VPS daadwerkelijk nodig heeft de syntaxis.

Toegangsregels vormen de andere helft. In een standaard tailnet kan elk van uw apparaten elk ander apparaat bereiken, dus een goedgekeurde route werkt direct. Zodra u een ACL-beleid schrijft, moet de doelzijde van een regel het privébereik benoemen, omdat 10.0.0.20 geen tailnet-adres is en niet wordt gedekt door regels die zijn geschreven voor tailnet-IP's of tags.

Bepaal tot slot of u een coördinatieserver wilt die u niet zelf beheert. Het control plane van Tailscale is een gehoste dienst. Uw keys blijven op uw machines, maar het account en het beleidsbestand staan daar. Het draaien van Headscale, de zelfgehoste Tailscale control server houdt dit op uw eigen VPS, ten koste van het onderhoud ervan. Het andere antwoord op dezelfde zorg is om ook de clients van Tailscale achterwege te laten; het zelf hosten van de NetBird VPN server plaatst de coördinatielaag en de bijbehorende mesh-clients op één machine die u beheert. Als u nog twijfelt tussen dit model en handgeschreven configuraties, legt de vergelijking tussen WireGuard en Tailscale uit wat de coördinatielaag u biedt en wat de kosten daarvan zijn.

FAQ

Wat is het verschil tussen een subnet router en een exit node?

Een subnet router adverteert een bereik van privé-adressen, zodat tailnet-apparaten machines kunnen bereiken waarop Tailscale niet draait. Een exit node adverteert zichzelf als route naar het volledige internet, waardoor een apparaat al zijn verkeer via het publieke adres van die node verstuurt. Eén VPS kan beide rollen vervullen. Het zijn afzonderlijke vlaggen, --advertise-routes en --advertise-exit-node, en elk vereist een eigen goedkeuring in de admin console.

Waarom negeert mijn Linux-client de geadverteerde subnet-route?

Linux-clients accepteren geen subnet-routes tenzij u hen daartoe opdracht geeft. Voer sudo tailscale set --accept-routes uit op de client. Controleer daarna met ip route show table 52, niet met ip route show. Tailscale installeert geaccepteerde routes in routing table 52 en bereikt deze via policy rules, waardoor de hoofdtabel ze nooit toont en een werkende route lijkt te ontbreken.

Mijn subnet werkt niet meer na een herstart. Wat is er mis?

Waarschijnlijk IP forwarding. Een waarde die is ingesteld met sysctl -w overleeft een herstart niet, dus schrijf deze naar /etc/sysctl.d/99-tailscale.conf en bevestig met sysctl net.ipv4.ip_forward. Als forwarding is ingeschakeld en het bereik nog steeds onbereikbaar is, bekijk dan de node in de admin console. Node keys verlopen standaard na 180 dagen, en een verlopen subnet router oogt als een netwerkfout in plaats van een accountprobleem.

Kunnen twee subnet routers hetzelfde bereik adverteren?

Geen identieke bereiken. Overlappende bereiken met verschillende prefix-lengtes zijn toegestaan, waarbij de meest specifieke route voorrang krijgt. Failover vereist aandacht: wanneer de router met de meest specifieke prefix offline gaat, schakelt Tailscale niet automatisch over naar de bredere route, waardoor het verkeer stopt. Voor een echte standby-opstelling moeten beide routers dezelfde specifieke prefixen adverteren.

De hostname wordt omgezet, maar de verbinding time-out. Hoe komt dit?

DNS-resolutie en routing zijn afzonderlijke stappen. Een naam kan worden omgezet naar een adres waarvoor geen goedgekeurde route bestaat, waarna het pakket via de standaard gateway van de client naar buiten gaat. Voer ip route get <address> uit op de client. Als het antwoord dev tailscale0 niet bevat, adverteer dan een bereik dat dat adres dekt en keur de nieuwe prefix goed in de admin console.