Tailscale subnet router instellen op een VPS

Wat een Tailscale subnet router doet

Een Tailscale subnet router is een 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, ook al draait daar geen Tailscale. 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 netwerkverkeer van een apparaat via de VPS, 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 wijzigt het punt waarvandaan uw publieke verkeer het netwerk verlaat. Als u de tweede optie zoekt, lees dan hoe u een Tailscale exit node op een VPS draait. Het zijn afzonderlijke flags en één VPS kan beide tegelijk doen, 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 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. Niets anders op het segment verandert, en de database heeft nog steeds geen publiek adres. Als het enige dat u van dat segment nodig heeft een web-app op één poort is, dan is het adverteren van het volledige bereik meer dan nodig, en Tailscale serve plaatst HTTPS op die enkele poort in plaats daarvan. Dezelfde redenering geldt voor een daemon die bewust alleen aan localhost bindt, zoals dsh die headless onder systemd draait, waarbij een tailnet-adres op die VPS de SSH-tunnel vervangt die u anders open zou houden om de UI te bereiken.

Het andere scenario is een netwerk aan de andere kant van de VPS. Een LAN (lokaal netwerk) 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 als subnetrouter voor al het overige verkeer. Thuis is die machine vaak een kleine VM op een hypervisor die u al gebruikt, en de kostenberekening van een Proxmox-host thuis versus een gehuurde VPS is de afweging die u moet maken voordat u beslist aan welke kant van de tunnel uw services moeten draaien.

Beide scenario's delen één vereiste. 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 het 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, wat active zou moeten weergeven.

Controleer vóór alles 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, zoals 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Als de ping hier, op de router zelf, faalt, 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 behouden 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 vervalt bij de volgende herstart. Hierdoor functioneert de subnet-router wekenlang, totdat deze na een kernel-update en herstart plotseling stopt. Het verwarrende is dat er op het eerste gezicht 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, zorgt u ervoor dat de instellingen na een herstart behouden blijven.

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.

Adverteer de routes

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

Op een VPS die al is aangemeld bij uw tailnet, wijzigt u de instelling in plaats daarvan als volgt:

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 heeft herhaald, en de CLI blokkeert u met een foutmelding 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 plaatst u in één door komma's gescheiden lijst zonder spaties: --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 benoemt het voorvoegsel dat u waarschijnlijk bedoelde. Om het adverteren te stoppen, stelt u een lege lijst in met sudo tailscale set --advertise-routes=.

De route goedkeuren 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 rij, zoek de sectie subnets, bewerk de route-instellingen, vink de route aan en sla de wijzigingen op.

Goedkeuring vindt plaats per prefix. Adverteer vandaag 10.0.0.0/24 en volgende maand 192.168.50.0/24; de nieuwe prefix komt dan ongeautoriseerd binnen, terwijl de oude prefix blijft werken. Een goedgekeurde route en een genegeerde route zien er vanuit de VPS identiek uit, dus controleer 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 opnieuw ongeautoriseerd beginnen.

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 automatisch 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 kunnen verstoren dat de machine al afhandelt. 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-overeenkomend verkeer 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 ten onrechte dat --accept-routes niets heeft gedaan. ip route show table 52 is het commando dat de werkelijkheid toont, en dit zou het geadverteerde bereik op tailscale0 moeten weergeven.

Er is één uitzondering die het vermelden waard is. 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 standby-router in een high-availability-paar --accept-routes uitgeschakeld en gebruik alleen de advertentiefunctie.

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 gedeeltelijke uitval van het privénetwerk, terwijl de oorzaak een offline node is die de specifiekere prefix vasthoudt. Als u failover wilt, laat de router met het bredere bereik dan ook de nauwere prefixen adverteren, zodat beide dezelfde adressen dekken.

De andere vorm van overlap vindt dichter bij de client plaats. 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 die voorrang krijgt op die van Tailscale zelf, zodat lokale adressen de hoofdtabel gebruiken:

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

Deze regel is niet persistent en verdwijnt bij de volgende reboot. De definitieve oplossing is het kiezen van een privéreikwijdte die 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 specifiekere 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, terwijl u 10.0.0.0/24 heeft geadverteerd. De lookup slaagt, omdat DNS (domain name system) resolutie en IP-routing afzonderlijke stappen zijn die elkaar niet controleren. Het pakket naar 10.0.5.20 vindt vervolgens geen overeenkomstige route op het 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 lookup een adres teruggeeft, 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. Schakelt u de optie in die lokale DNS-servers overschrijft terwijl u naar een onbereikbare resolver wijst, dan verliest elk apparaat in het tailnet 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 pas de DNS-instelling. Als DNS binnen een tunnel het onderdeel is waar u tegen blijft aanlopen, dan behandelt de manier waarop DNS faalt 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) en het bestaat zodat antwoorden werken zonder dat er iets op het privénetwerk hoeft te worden aangepast: 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 informatie bieden.

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 terug nodig naar 100.64.0.0/10, het bereik dat Tailscale aan apparaten toewijst, 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 overdrachten vastlopen terwijl ssh en ping in orde zijn, is de oorzaak MSS (maximum segment size), het grootste gegevensblok dat een TCP-pakket bevat. 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 key-verloop 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 verbinden direct. 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. Wat iemand daadwerkelijk zou kunnen doen met een gecompromitteerd control plane of een gestolen identiteitslogin is iets om over na te denken voordat u het toegang geeft tot uw privénetwerk, en het vertrouwensmodel van Tailscale geeft aan waar die grens ligt. Kosten zijn zelden de reden waarom mensen afhaken, aangezien het gratis abonnement tot zes gebruikers met een onbeperkt aantal eigen apparaten dekt, hoewel een subnet router die u onder een tag opzet anders wordt geteld dan een router die met uw eigen account is aangemeld. Voorbij dat punt volgt de factuur het aantal personen in plaats van het aantal machines, dus wat een huishouden of een team van vijf personen daadwerkelijk betaalt zodra het gratis abonnement afloopt is het waard om uit te rekenen voordat u het account toevoegt dat de grens overschrijdt. 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 achter u te laten, en 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 oplevert en wat het kost.

FAQ

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

Een subnet router adverteert een bereik van privé-adressen, zodat apparaten in de tailnet 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 het 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 weergeeft en een werkende route lijkt te ontbreken.

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

Waarschijnlijk IP forwarding. Een waarde die is ingesteld met sysctl -w blijft niet behouden na een reboot; schrijf deze daarom naar /etc/sysctl.d/99-tailscale.conf en bevestig dit 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. Gebruik voor een echte standby-opstelling beide routers om dezelfde specifieke prefixen te 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 dat door geen enkele goedgekeurde route wordt gedekt, 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.