Is Tailscale veilig? Het vertrouwensmodel uitgelegd

Is Tailscale veilig? Het korte antwoord

Is Tailscale veilig? Voor het deel waar de meeste mensen zich zorgen over maken: ja. De coördinatieserver die uw tailnet beheert, bezit nooit de privésleutels die uw verkeer versleutelen. Hierdoor kan deze niet lezen wat uw apparaten naar elkaar verzenden. De beveiligingspagina van Tailscale stelt het direct: "Privésleutels verlaten het apparaat nooit. Al het verkeer is altijd end-to-end versleuteld." De relevante vraag is echter anders. Een coördinatieserver die gecompromitteerd is, of onderworpen is aan een juridisch bevel, hoeft uw pakketten niet te lezen. De server bepaalt namelijk welke publieke sleutels uw apparaten vertrouwen, waardoor deze een apparaat kan toevoegen dat u nooit heeft goedgekeurd.

Dat is het vertrouwensmodel in één zin: versleuteling beschermt de data en het control plane bepaalt het lidmaatschap. Elke sectie hieronder benoemt één partij die u moet vertrouwen, beschrijft wat die partij daadwerkelijk kan doen en geeft de controle aan die dit beperkt. Als het product zelf nieuw voor u is, begin dan bij wat Tailscale is en hoe het mesh-netwerk werkt.

Het control plane en het data plane zijn gescheiden

Tailscale is een mesh VPN (virtual private network) gebaseerd op WireGuard, hetzelfde protocol dat u handmatig zou configureren op een zelfgehoste WireGuard VPS. Elk apparaat genereert lokaal zijn eigen WireGuard-sleutelpaar. De how it works-post van Tailscale noemt de coördinatieserver "een gedeelde dropbox voor publieke sleutels" en stelt: "De privésleutel verlaat nooit, onder geen beding, zijn node."

Het data plane is het versleutelde verkeer tussen uw apparaten. Dit reist rechtstreeks van apparaat naar apparaat, wanneer het netwerk dit toelaat. Het control plane is al het overige: welke apparaten tot de tailnet behoren, welke publieke sleutel bij welk apparaat hoort, het toegangsbeleid, de DNS-instellingen en de relay-lijst. Tailscale beheert het control plane als een gehoste dienst. U beheert het data plane op uw eigen machines.

Houd deze twee gescheiden en elke beveiligingsvraag hier wordt beantwoordbaar. Versleuteling is een eigenschap van het data plane. Lidmaatschap is een beslissing van het control plane. Geen enkele hoeveelheid versleuteling vertelt u wie als peer is toegestaan.

Wat kan een gecompromitteerde coördinatieserver doen?

Deze kan uw verkeer niet ontsleutelen. De sleutels die de versleuteling uitvoeren, worden op uw apparaten gegenereerd en nooit geüpload. Er is dus niets te onderscheppen of te lekken waarmee de tunnel kan worden geopend. Dit geldt ook voor relayed verkeer, wat verderop wordt behandeld.

Deze kan een node toevoegen. Toen Tailscale tailnet lock aankondigde, beschreef het bedrijf het risico in eigen woorden: een kwaadwillende server zou "een in het geheim toegevoegde node kunnen gebruiken om verkeer naar uw bestaande nodes te sturen of te ontvangen". Op dat moment "zou het niet uitmaken dat het verkeer versleuteld is, omdat de peer zelf kwaadwillend zou zijn". Uw apparaat vertrouwt een peer omdat het control plane heeft aangegeven dat de sleutel bij het tailnet hoort.

Deze kan wijzigen wat uw apparaten mogen bereiken. Het toegangsbeleid bevindt zich in het control plane en wordt gedistribueerd naar de nodes. De tailnet lock white paper van Tailscale stelt dat tailnet lock "niet voorkomt dat een gecompromitteerd control plane de connectiviteit in uw netwerk verstoort, bijvoorbeeld door het niet distribueren van nieuwe nodesleutels of het distribueren van een toegangsbeleid dat toegang tot alle nodes weigert."

Deze ziet in ieder geval verbindingsmetadata. De netwerkstroomlogs van Tailscale registreren gebeurtenissen voor het openen en sluiten van elke verbinding tussen machines. De documentatie stelt dat die logs "strikt genomen geen informatie bevatten over client-operaties of de inhoud van netwerkverkeer". Het control plane kan dus weten welke van uw apparaten met welke andere hebben gecommuniceerd, en wanneer. Het weet niet wat er is gezegd.

Slechts één punt op deze lijst gaat over versleuteling. De andere punten gaan over wie lid is en wat het beleid voorschrijft. Daarom zijn de controles die uw aandacht verdienen de controles die het toevoegen van nodes beheren.

Uw identity provider is de root of trust voor de tailnet

Tailscale beheert geen eigen wachtwoorddatabase. In de documentatie staat expliciet dat er geen Tailscale-wachtwoorden bestaan en dat het inloggen wordt gedelegeerd aan een identity provider (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin of een aangepaste OpenID Connect-provider.

Beschouw dit als een beveiligingsverklaring, want dat is het ook. Iedereen die kan inloggen op uw Google- of Microsoft-account, kan inloggen op uw tailnet. Uw multi-factor authenticatie (MFA) is gelijk aan wat de IdP afdwingt. Uw offboarding-proces is gelijk aan wat de IdP uitvoert wanneer een persoon de organisatie verlaat. Een gephisht IdP-account is een tailnet-account; de aanvaller hoeft WireGuard nooit aan te vallen: zij voegen een apparaat toe en erven alle rechten die uw beleid aan die gebruiker toekent.

Twee beheersmaatregelen staan tussen een gestolen identiteitsaccount en een werkend apparaat binnen uw tailnet: goedkeuring van apparaten en het verlopen van sleutels. Tailnet lock is een derde maatregel, die zich richt op het control plane in plaats van op het account.

Apparaatgoedkeuring: niets wordt toegevoegd zonder expliciete toestemming

De documentatie van Tailscale beschrijft apparaatgoedkeuring als een functie waarmee "netwerkbeheerders van Tailscale nieuwe apparaten kunnen beoordelen en goedkeuren voordat ze lid kunnen worden van uw Tailscale-netwerk". Een eigenaar, beheerder of IT-beheerder kan de goedkeuring verlenen. Een nieuw apparaat toont een "Needs approval"-badge op de Machines-pagina totdat iemand actie onderneemt.

Schakel dit in en het scenario van een gecompromitteerd account verandert. De aanvaller logt in, het apparaat registreert zich en wacht vervolgens, zonder toegang tot enige bron, naast een badge in uw beheerconsole die aangeeft dat een onbekende machine toegang vraagt. Automatisering blijft werken, omdat een auth key als vooraf goedgekeurd kan worden gemarkeerd bij het genereren, en apparaten via de API kunnen worden goedgekeurd.

Auth keys zijn de andere toegangsweg, dus behandel ze als inloggegevens. De documentatie van Tailscale is direct over de risicovolle variant: "Wees zeer voorzichtig met herbruikbare sleutels! Deze kunnen zeer gevaarlijk zijn als ze worden gestolen. Ze kunnen het beste worden bewaard in een product voor sleutelbeheer dat specifiek voor dit doel is ontworpen." Sinds augustus 2026 is het gedocumenteerde bereik voor het verlopen van sleutels 1 tot 90 dagen, en een niet-gespecificeerde verloopdatum valt standaard terug op het maximum van 90 dagen. Geef de voorkeur aan eenmalige sleutels, markeer ze als ephemeral voor machines die tijdelijk zijn, en bewaar elke herbruikbare sleutel versleuteld met Ansible Vault of in een secrets manager in plaats van in een shell-script.

Sleutelverloop: de timer die elke andere fout beperkt

Node-sleutels verlopen, wat ervoor zorgt dat een gestolen of vergeten apparaat slechts een tijdelijk probleem vormt. De documentatie van Tailscale stelt dat "Standaard zijn nieuwe domeinen ingesteld met een verlooptermijn van 180 dagen", en dat "Als er geen herauthenticatie plaatsvindt, verlopen de sleutels en zullen verbindingen van/naar het betreffende eindpunt stoppen met werken." U kunt een apparaat zelf opnieuw authenticeren:

tailscale up --force-reauth

De documentatie waarschuwt dat dit "de tailnet-verbinding kan verbreken en daarom niet op afstand via SSH of RDP moet worden uitgevoerd zonder een alternatieve manier om in te loggen als de verbinding verloren gaat." Voer dit uit met console-toegang open, of via een tweede pad naar de machine, omdat u op het punt staat het netwerk dat u gebruikt te onderbreken.

Servers zijn de plekken waar dit beheer wordt aangepast. Een machine die elke 180 dagen opnieuw moet authenticeren, zal om 3 uur 's nachts van het tailnet vallen wanneer niemand toekijkt, dus schakelen beheerders het sleutelverloop daarop uit. Dat verwijdert de timer die uiteindelijk een gestolen sleutel zou blokkeren. Een getagd apparaat is de betere oplossing voor een server, omdat een tag de machine bezit in plaats van een persoon, waardoor de machine blijft bestaan als die persoon het bedrijf verlaat. Wat u ook besluit, houd een lijst bij van welke machines geen sleutelverloop hebben: die sleutels blijven geldig totdat u het apparaat verwijdert.

Tailnet lock: de coördinatieserver uit de vertrouwensketen halen

Tailnet lock pakt het inschrijvingsprobleem direct aan. De documentatie over tailnet lock van Tailscale legt het mechanisme uit: "Wanneer een nieuwe node zich bij de tailnet voegt, vereist de publieke node-key een handtekening van een Tailnet Lock-key. De coördinatieserver distribueert de ondertekende publieke node-key naar peer-nodes." Uw bestaande apparaten verifiëren die handtekening voordat ze een peer accepteren, waardoor een node-key die door het control plane zelf is verzonnen, wordt geweigerd.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init schakelt de functie in en op dat moment wijst u uw signing nodes aan. Tailscale vereist bij initialisatie minimaal twee signing nodes en staat er maximaal 20 toe in een tailnet. Daarna heeft elk nieuw apparaat een handtekening van een van deze nodes nodig, wat een reële operationele last met zich meebrengt: voor het toevoegen van een telefoon moet u een commando uitvoeren op een laptop.

De limieten zijn gedocumenteerd en ze zijn belangrijker dan de beschrijving van de functie:

• Verliest u het disablement secret, dan is er geen herstel mogelijk. De documentatie stelt: "Als u uw disablement secrets verliest en u er geen aan de support van Tailscale heeft verstrekt, kan de tailnet niet worden hersteld."
• De signing key bevindt zich op een apparaat dat u bezit, waardoor het de beveiliging van dat apparaat erft. De documentatie is expliciet: "Als het apparaat is gecompromitteerd, kan de key worden verkregen."
• U kunt niet beide controles tegelijk uitvoeren. Tailscale stelt dat tailnet lock en device approval elkaar uitsluiten; het inschakelen van de een betekent dat u de ander moet opgeven.
• Het is trust on first use (TOFU). De initiële configuratie verloopt nog steeds via het control plane en het anker van vertrouwen verplaatst zich pas na die eerste stap naar uw eigen netwerk.

Tailnet lock beschermt het lidmaatschap. Het beschermt niet de beschikbaarheid, zoals ook in het white paper staat vermeld.

Stelt een relayed verbinding mijn verkeer bloot?

Nee. Wanneer twee apparaten elkaar niet rechtstreeks kunnen bereiken, valt het verkeer terug op een DERP-server (Designated Encrypted Relay for Packets). De documentatie van Tailscale stelt dit zonder voorbehoud: "Omdat private keys van Tailscale nooit het lokale apparaat verlaten waarop ze zijn gegenereerd, is het voor een DERP-server onmogelijk om uw verkeer te ontsleutelen. Een DERP-server stuurt blindelings reeds versleuteld verkeer door van het ene apparaat naar het andere."

Een relay kost u nog steeds snelheid en registreert metadata: twee versleutelde eindpunten, plus de timing en het volume van wat er tussen hen wordt uitgewisseld. Controleer welk type verbinding u daadwerkelijk heeft:

tailscale status
tailscale netcheck

tailscale status markeert elke peer als direct, weergegeven als direct 203.0.113.10:41641, of relayed, weergegeven als relay gevolgd door de naam van de relay, met byte-tellers erachter. Een peer die op een relay blijft staan, betekent dat de twee uiteinden geen direct pad konden opbouwen, meestal omdat UDP ergens wordt geblokkeerd of omdat beide zijden zich achter strikte NAT (network address translation) bevinden. tailscale netcheck rapporteert of UDP vanaf die machine überhaupt werkt, hoe uw NAT poorten toewijst en de latentie naar de dichtstbijzijnde relays; dit geeft aan met welke van deze twee oorzaken u te maken heeft.

Een exit node verplaatst uw uitgaande verkeer, het verwijdert het niet

Een exit node routeert al het openbare internetverkeer van een apparaat via een ander apparaat op de tailnet, waarbij gebruik wordt gemaakt van de standaardroutes 0.0.0.0/0 en ::/0. Op Linux adverteert de machine die de dienst aanbiedt deze, waarna elke client zich hiervoor kan aanmelden:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Een exit node moet worden goedgekeurd door een Owner, Admin of Network admin in de admin console, en uw beleid moet autogroup:internet verlenen voordat een client deze mag gebruiken. Beide stappen zijn bewust: een niet-goedgekeurde machine kan niet ongemerkt de uitgang worden voor uw gehele tailnet.

Dan de kwestie van vertrouwen. Verkeer is versleuteld vanaf uw laptop tot aan de exit node. Vervolgens verlaat het die machine als gewoon internetverkeer, waarbij het IP-adres van die machine wordt gebruikt. De beheerder van de exit node ziet dus uw bestemmingen, evenals de hostingprovider van die machine en het upstream-netwerk. U heeft het observatiepunt verplaatst in plaats van het verwijderd. Dat is een goede afweging wanneer u de andere kant beheert, wat het argument is voor het draaien van uw eigen exit node op een VPS, en een slechte afweging wanneer u dat niet doet.

Het standaardbeleid is een plat netwerk

Een nieuwe tailnet is standaard permissief. De documentatie over toegangscontrole van Tailscale stelt dat het standaardbeleidsbestand "communicatie tussen alle apparaten binnen de tailnet mogelijk maakt". Elk apparaat kan elk ander apparaat op elke poort bereiken. Dit is een plat netwerk. U heeft het verplaatst naar binnen de tunnel; dit helpt tegen buitenstaanders, maar doet niets tegen een laptop die besmet raakt.

Verscherp dit in het tailnet-beleidsbestand, dat access control lists (ACL's) of de nieuwere grants accepteert, beide geschreven in een JSON-dialect dat commentaar toestaat:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Dit beleid staat één groep toe om SSH op productieservers te bereiken, laat leden een exit node gebruiken en weigert al het overige door weglating. Tailscale geeft aan welke regeldoelen beschikbaar zijn in welk abonnement, dus controleer dit voordat u ontwerpt op basis van tags of autogroups, en bekijk wat het gratis abonnement daadwerkelijk bevat. Voor een apparaat dat nooit inkomende verbindingen zou moeten accepteren, zoals een persoonlijke telefoon, blokkeert tailscale set --shields-up deze op de client.

Wat het zelf hosten van het control plane met Headscale verandert

Headscale is "een open-source, zelf-gehoste implementatie van de Tailscale-control server." De README geeft de reikwijdte eerlijk aan: "Het implementeert een beperkte scope, een enkel Tailscale-netwerk (tailnet), geschikt voor persoonlijk gebruik of een kleine open-source organisatie." De lijst met functies omvat ACL's en rechten, subnet-routers, exit nodes, een ingebouwde DERP-server, Tailscale SSH en Taildrop. Als die beperkte scope het struikelblok is, is NetBird het andere mesh-netwerk dat een zelf-hostbaar control plane aanbiedt, en het draaien van de NetBird-server op uw eigen VPS verplaatst dezelfde beslissing over inschrijving naar hardware die u zelf bezit.

Wat verandert, is de identiteit van de partij die een malafide node zou kunnen inschrijven. Bij Headscale bevinden de key directory en het beleid zich op uw server. Geen enkele derde partij beschikt ooit over de lijst met publieke sleutels van uw apparaten, en geen enkele derde partij kan worden gedwongen deze af te staan of er een te ondertekenen.

Wat niet verandert, is het data plane. Het is dezelfde WireGuard met dezelfde end-to-end encryptie, en dezelfde relay-fallback wanneer een direct pad onmogelijk is. U neemt ook de taken over die Tailscale voorheen uitvoerde: uptime, patching, back-ups en de fysieke beveiliging van de server. Een gecompromitteerde Headscale-host geeft een aanvaller precies wat een gecompromitteerde coördinatieserver hen zou geven: de bevoegdheid om een node in te schrijven en beleid te verspreiden. Tailnet lock staat niet op de functielijst van Headscale, dus de compenserende maatregel voor dat specifieke risico is daar niet beschikbaar. Als de vraag over eigenaarschap voor u de doorslag geeft, dan leidt het zelf hosten van het control plane met Headscale u door de installatie.

Waartegen Tailscale bescherming biedt

• Publiek luisterende poorten. Een service die is gebonden aan een tailnet-adres is niet bereikbaar vanaf het internet, waardoor de scanners die elke VPS op poort 22 raken deze nooit zien. De uitzondering is een service die u zelf inschakelt, omdat Funnel een tailnet-service bewust publiceert naar het open internet. Daarom is het nuttig om te weten waar serve eindigt en funnel begint voordat u een van beide commando's uitvoert. Houd de host-firewall in ieder geval actief, omdat een gepubliceerde Docker-poort zijn eigen regels schrijft en ufw omzeilt op de publieke interface.
• Wachtwoordgokken bij blootgestelde logins. Er valt niets te proberen (password spraying) wanneer de poort alleen antwoordt binnen de tunnel. Dat is een sterkere positie dan het toepassen van rate limiting op een open poort, hoewel fail2ban op Ubuntu 24.04 nog steeds de moeite waard is op alles wat publiek toegankelijk moet blijven.
• Onbetrouwbare netwerken in het pad. Verkeer tussen uw machines is end-to-end versleuteld over een café-netwerk of een gedeeld LAN van een provider, en het blijft versleuteld wanneer het wordt doorgegeven (relayed).
• Handmatige distributie van sleutels. Elke peer die handmatig wordt toegevoegd aan een WireGuard-configuratie is een kans om een adres opnieuw te gebruiken of de verkeerde sleutel te plakken. Het mesh-netwerk voert die administratie voor u uit, wat het grootste praktische verschil is in WireGuard versus Tailscale.

Waar Tailscale niet tegen beschermt

• Een gecompromitteerd eindpunt. Het tailnet vertrouwt apparaten. Malware op een goedgekeurde laptop krijgt toegang tot de tunnel, de tailnet-adressen en alles wat uw beleid aan die gebruiker toestaat. Dit is het grootste gat en geen enkele VPN dicht dit.
• Een kwaadwillende of onvoorzichtige beheerder. Iedereen die het beleidsbestand kan bewerken, kan zichzelf toegang verlenen tot alles, en iedereen die de identiteit van een eigenaar (Owner) kan overnemen, kan hetzelfde doen. Controleer beleidswijzigingen op dezelfde manier als u code controleert.
• Verkeersanalyse. Uw ISP (internet service provider) ziet versleutelde UDP-pakketten naar een eindpunt stromen, evenals de timing en het volume. De flow-logs van Tailscale zien welke peers met elkaar communiceerden en wanneer. Geen van beide ziet de inhoud, maar het feit dat er een verbinding is, blijft niet verborgen. Lees daarom hoe Tor en een VPN verschillen voordat u een tool voor die taak kiest.
• Een apparaat dat u al kwijt bent. Het verlopen van sleutels is een trage vangnet-optie met een standaardinstelling van 180 dagen. Het verwijderen van het apparaat in de beheerconsole is de snelle methode; weet dus waar die knop zich bevindt voordat u deze nodig heeft.

Controleer uw eigen tailnet

1. Voer tailscale status uit op een apparaat en bekijk de lijst met peers. Een machine die u niet kunt identificeren, is precies de situatie die apparaatgoedkeuring moet voorkomen.
2. Voer tailscale lock status uit om te zien of tailnet lock is ingeschakeld en bepaal vervolgens of de extra handeling van het ondertekenen van elk nieuw apparaat opweegt tegen de voordelen voor uw tailnet.
3. Open de admin console en noteer elke machine waarbij het verlopen van de sleutel is uitgeschakeld, evenals elke herbruikbare auth key die nog actief is. Beide vormen inloggegevens zonder tijdsbeperking.
4. Lees uw policy file. Als deze nog op de standaardinstellingen staat, kan elk apparaat elk ander apparaat op elke poort bereiken; één geïnfecteerde laptop geeft dan toegang tot alle apparaten.

Tailscale dankt zijn reputatie aan het datavlak, waarbij het ontwerp de beheerder geen mogelijkheid biedt om uw verkeer in te zien. Neem die bewering aan zoals de leverancier deze documenteert en controleer vervolgens de onderdelen waar u verantwoordelijk voor bent: de identiteitsaccounts, de instelling voor goedkeuring, de lijst met verlopen sleutels en de policy file. De beveiligingspagina van Tailscale rapporteert een SOC 2 Type II-certificering en voortdurende beveiligingssamenwerking met Latacora; dit is bewijs voor hun proces en geen uitspraak over uw configuratie.

FAQ

Kan Tailscale mijn verkeer inzien?

Nee. Verkeer wordt versleuteld met WireGuard-sleutels die op uw eigen apparaten worden gegenereerd. De beveiligingspagina van Tailscale stelt: "Privésleutels verlaten het apparaat nooit. Al het verkeer is altijd end-to-end versleuteld." Dit geldt ook voor verbindingen die terugvallen op een DERP-relay, omdat de relay "blindelings reeds versleuteld verkeer van het ene naar het andere apparaat doorstuurt" en niet over de sleutels beschikt om dit te ontsleutelen. De infrastructuur van Tailscale ziet enkel metadata: welke apparaten er bestaan en welke apparaten wanneer met elkaar verbonden zijn.

Wat kan een gecompromitteerde Tailscale-coördinatieserver daadwerkelijk doen?

Deze kan een node toevoegen. De aankondiging van tailnet lock door Tailscale beschrijft het risico van een in het geheim toegevoegde node die "verkeer kan verzenden naar of ontvangen van uw bestaande nodes". Versleuteling helpt hier niet, "omdat de peer zelf kwaadaardig zou zijn". Een gecompromitteerd control plane kan ook een beleid verspreiden dat wijzigt welke bestemmingen uw apparaten kunnen bereiken. Het white paper over tailnet lock merkt op dat dit de connectiviteit kan verbreken door het niet distribueren van nieuwe node-sleutels. Wat de server niet kan, is verkeer tussen uw bestaande apparaten ontsleutelen, omdat deze nooit over de privésleutels van die apparaten heeft beschikt.

Verbergt een exit node mijn surfgedrag voor mijn ISP?

Het verbergt de bestemmingen voor het netwerk waarop u zich bevindt, inclusief uw thuis- of café-ISP, omdat al het verkeer uw apparaat verlaat als versleuteld verkeer gericht aan de exit node. Het maakt u niet anoniem. De exit node ziet deze bestemmingen in plaats daarvan, evenals de hostingprovider en het upstream-netwerk van die node, terwijl de bezochte websites het IP-adres van de exit node zien. U kiest hiermee een andere waarnemer; kies dus een partij die u daadwerkelijk vertrouwt.

Is Headscale veiliger dan de coördinatieserver van Tailscale?

Het is een andere afweging in vertrouwen in plaats van strikt veiliger. Met Headscale beheert u zelf de sleutelmap en het beleid, waardoor geen enkele externe partij gedwongen kan worden een apparaat aan uw tailnet toe te voegen. U neemt echter ook het beheer van die server op u: patchen, uptime, back-ups en de beveiliging van de host zelf. Een gecompromitteerde Headscale-host biedt een aanvaller dezelfde mogelijkheden voor het toevoegen van nodes als een gecompromitteerde coördinatieserver. Aangezien tailnet lock geen onderdeel is van de functieset van Headscale, dient u die host dienovereenkomstig te beveiligen.

Heb ik nog steeds een firewall nodig op een VPS die zich in mijn tailnet bevindt?

Ja. De publieke netwerkinterface blijft bestaan en elke service die gebonden is aan 0.0.0.0 blijft bereikbaar vanaf het internet, ongeacht of Tailscale actief is. Bind services aan het tailnet-adres, hanteer een 'default deny'-beleid op de publieke interface en controleer uw gepubliceerde Docker-poorten. Docker voegt namelijk eigen regels toe aan iptables en kan daardoor een poort openstellen waarvan u dacht dat deze gesloten was.