Tailscale Serve teenoor Funnel: wie kan die skakel werklik oopmaak?

Albei opdragte publiseer 'n plaaslike diens deur 'n Tailscale HTTPS-naam, en van die masjien wat hulle uitvoer lyk hulle byna identies. Die verskil is wie die URL daarna kan bereik, en daardie verskil bepaal watter beheermaatreëls jou toepassing steeds nodig het. Serve hou die gehoor binne die tailnet; Funnel skuif dit na die publieke internet. Kies eers die gehoor en kies dan die opdrag wat daarby pas.

Serve beantwoord 'n vraag binne jou tailnet

Serve dien as 'n proxy vir 'n plaaslike poort of lewer plaaslike inhoud aan toestelle op jou tailnet, en die tailnet se toegangsreëls geld steeds vir elke versoek. 'n Kontroleskerm op poort 3000 word bereikbaar by 'n HTTPS-naam wat net jou toestelle kan oplos en waarmee hulle kan verbind. Dit is die regte verstek vir interne gereedskap, want die gehoor is reeds deur die tailnet geoutentiseer en jy voeg nie 'n publieke oppervlak by nie. Die URL lyk soos 'n gewone webwerf, en dit is juis waarom mense dit vir een aansien.

Serve kan ook identiteitsopskrifte wat die tailnet-gebruiker beskryf aan versoeke heg wat dit aanstuur. As jou toepassing daardie opskrifte as outentisering vertrou, bind die backend aan localhost sodat niks anders dit direk kan bereik nie; 'n backend wat op 'n routeerbare adres luister, kan versoeke ontvang wat nooit deur die proxy gegaan het nie.

Funnel verander die gehoor na die oop internet

Funnel publiseer 'n gekose diens aan enigiemand met die URL, en besoekers het nie die kliënt, 'n rekening of lidmaatskap van jou tailnet nodig nie. Die hulpbron het dus die outentisering, koersbeperking en opdaterings nodig wat jy op enige publieke diens sou toepas. Publieke versoeke dra nie Serve se tailnet-identiteitsopskrifte nie, so 'n toepassing wat daarop staatgemaak het, het onder Funnel glad geen gebruikeridentiteit nie. Om 'n ander publikasie-opdrag te kies, beantwoord nie die outentiseringsvraag vir jou nie.

Funnel het ook beperkings wat 'n tutoriaal uit 'n ouer weergawe dalk nie noem nie. Dit termineer TLS met 'n sertifikaat wat Tailscale vir die naam verkry, en dit ondersteun net spesifieke luisterpoorte, soos die Funnel-dokumentasie beskryf. As jou diens 'n ander protokol as HTTPS op een van daardie poorte verwag, is Funnel die verkeerde hulpmiddel eerder as 'n konfigurasieraaisel.

Lees die modus by die kliënt, nie by die poort nie

Kontroleer die huidige toestand voordat jy iets deel, want die twee modusse kan op verskillende tye vir dieselfde plaaslike poort gekonfigureer word. Die statusopdragte rapporteer wat werklik gepubliseer is en aan wie. Moenie die gehoor aflei uit die feit dat 'n URL reageer nie.

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

Opdragsinneks het oor kliëntweergawes verander, so 'n gekopieerde aanroep kan 'n ander modus kies as dié wat jy bedoel het. Verkies die gedokumenteerde vorm vir die weergawe wat jy gebruik, en lees die bevestiging wat die kliënt druk in plaas daarvan om dit te aanvaar. As daar beide 'n Serve- en 'n Funnel-konfigurasie bestaan, is die publieke een die een wat vir blootstelling saak maak. Herstel die konfigurasie wat jy nie bedoel het nie eerder as om nog een bo-op te lê.

Stop en lees die status weer as die uitset nie die gehoor noem nie. 'n Gepubliseerde URL sonder 'n vermelde gehoor is 'n raaiskoot, en raaiskote is hoe interne kontroleskerms op die publieke internet beland.

Toets met die gehoor wat jy werklik bedoel het

Toets van buite die tailnet, nie van die masjien wat die diens gepubliseer het nie. 'n Versoek vanaf 'n tailnet-toestel bewys die proxy werk; dit bewys nie dat 'n vreemdeling uitgesluit is nie. Gebruik 'n netwerk wat geen Tailscale-kliënt en geen roete na die tailnet het nie.

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

Vir 'n interne kontroleskerm behoort die buiteversoek te misluk om te verbind of te misluk om te magtig, en die binneversoek behoort te slaag met die identiteit wat jy verwag. Vir 'n publieke diens behoort die buiteversoek te slaag en die toepassing behoort sy eie geloofsbriewe te vra. Teken aan watter van daardie twee uitkomste jy waargeneem het, want die URL alleen sê dit nie. As die resultaat die teenoorgestelde van die bedoeling is, verwyder eers die publieke konfigurasie en ondersoek daarna.

Om 'n diens te publiseer is ook nie dieselfde besluit as om 'n exit node te kies nie, wat beheer waar jou uitgaande verkeer die netwerk verlaat. Serve en Funnel beantwoord wie iets kan bereik wat jy bedryf; 'n exit node beantwoord waar jou eie verbindings vandaan lyk. Hou die twee vrae apart en die vergelyking bly eenvoudig.