Tailscale Serve of Funnel: wie kan de link echt openen?

Beide commando's publiceren een lokale dienst via een Tailscale HTTPS-naam, en vanaf de machine die ze uitvoert lijken ze bijna identiek. Het verschil is wie de URL daarna kan bereiken, en dat verschil bepaalt welke controles je applicatie nog nodig heeft. Serve houdt het publiek binnen het tailnet, Funnel verplaatst het naar het open internet. Kies eerst het publiek en daarna het commando dat daarbij past.

Serve beantwoordt een vraag binnen je tailnet

Serve proxyt een lokale poort of levert lokale inhoud aan apparaten op je tailnet, en de toegangsregels van het tailnet gelden nog steeds voor elk verzoek. Een dashboard op poort 3000 wordt bereikbaar op een HTTPS-naam die alleen jouw apparaten kunnen oplossen en waarmee ze kunnen verbinden. Dat is de juiste standaard voor interne tools, omdat het publiek al door het tailnet is geauthenticeerd en je geen openbaar oppervlak toevoegt. De URL ziet eruit als een normale website, en juist daarom zien mensen hem daarvoor aan.

Serve kan ook identiteitsheaders die de tailnet-gebruiker beschrijven aan doorgestuurde verzoeken koppelen. Als je applicatie die headers als authenticatie vertrouwt, bind de backend dan aan localhost zodat niets anders hem rechtstreeks kan bereiken; een backend die op een routeerbaar adres luistert, kan verzoeken ontvangen die nooit door de proxy zijn gegaan.

Funnel verandert het publiek naar het open internet

Funnel publiceert een gekozen dienst voor iedereen met de URL, en bezoekers hebben de client, een account of lidmaatschap van je tailnet niet nodig. De resource heeft daarom de authenticatie, snelheidsbeperking en patches nodig die je op elke openbare dienst zou toepassen. Openbare verzoeken dragen niet de tailnet-identiteitsheaders van Serve, dus een applicatie die daarop vertrouwde heeft onder Funnel helemaal geen gebruikersidentiteit. Een ander publicatiecommando kiezen beantwoordt de authenticatievraag niet voor je.

Funnel heeft ook beperkingen die een handleiding uit een oudere versie misschien niet noemt. Het beëindigt TLS met een certificaat dat Tailscale voor de naam haalt, en het ondersteunt alleen bepaalde luisterpoorten, zoals de Funnel-documentatie beschrijft. Als je dienst op een van die poorten een ander protocol dan HTTPS verwacht, is Funnel het verkeerde hulpmiddel en geen configuratiepuzzel.

Lees de modus bij de client, niet bij de poort

Controleer de huidige status voordat je iets deelt, want de twee modi kunnen op verschillende momenten voor dezelfde lokale poort zijn geconfigureerd. De statuscommando's melden wat er werkelijk is gepubliceerd en voor wie. Leid het publiek niet af uit het feit dat een URL reageert.

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

De commandsyntaxis is tussen clientversies veranderd, dus een gekopieerde aanroep kan een andere modus kiezen dan je bedoelde. Geef de gedocumenteerde vorm voor jouw versie de voorkeur en lees de bevestiging die de client afdrukt in plaats van die aan te nemen. Als er zowel een Serve- als een Funnel-configuratie bestaat, is de openbare degene die voor blootstelling telt. Zet de configuratie die je niet bedoelde terug in plaats van er nog een bovenop te leggen.

Stop en lees de status opnieuw als de uitvoer het publiek niet noemt. Een gepubliceerde URL zonder vermeld publiek is een gok, en gokken is hoe interne dashboards op het open internet belanden.

Test met het publiek dat je echt bedoelde

Test van buiten het tailnet, niet vanaf de machine die de dienst heeft gepubliceerd. Een verzoek van een apparaat in het tailnet bewijst dat de proxy werkt; het bewijst niet dat een buitenstaander is uitgesloten. Gebruik een netwerk zonder Tailscale-client en zonder route naar het tailnet.

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

Voor een intern dashboard zou het externe verzoek moeten mislukken om te verbinden of mislukken op autorisatie, en het interne verzoek zou moeten slagen met de identiteit die je verwacht. Voor een openbare dienst zou het externe verzoek moeten slagen en zou de applicatie zijn eigen inloggegevens moeten vragen. Noteer welk van die twee uitkomsten je hebt waargenomen, want de URL alleen vertelt het je niet. Als het resultaat het tegenovergestelde van de bedoeling is, verwijder dan eerst de openbare configuratie en onderzoek daarna.

Een dienst publiceren is ook niet dezelfde beslissing als het kiezen van een exit-node, die bepaalt waar je uitgaande verkeer het netwerk verlaat. Serve en Funnel beantwoorden wie iets kan bereiken dat je draait; een exit-node beantwoordt waar je eigen verbindingen vandaan lijken te komen. Houd de twee vragen gescheiden en de vergelijking blijft eenvoudig.