Tailscale Serve eller Funnel: hvem kan egentlig åpne lenken?
Serve deler en tjeneste med tailnettet ditt, mens Funnel eksponerer den på det åpne internettet. Sammenlign publikummet, identitetshodene og portene Funnel tillater.
Begge kommandoene publiserer en lokal tjeneste gjennom et Tailscale HTTPS-navn, og fra maskinen som kjører dem ser de nesten identiske ut. Forskjellen er hvem som kan nå URL-en etterpå, og den forskjellen avgjør hvilke kontroller applikasjonen din fortsatt trenger. Serve holder publikummet inne i tailnettet, mens Funnel flytter det ut på det åpne internettet. Velg publikummet først, og velg deretter kommandoen som passer til det.
Serve svarer på et spørsmål inne i tailnettet ditt
Serve proxyer en lokal port eller leverer lokalt innhold til enheter på tailnettet ditt, og tailnettets tilgangsregler gjelder fortsatt for hver forespørsel. Et dashbord på port 3000 blir tilgjengelig på et HTTPS-navn som bare enhetene dine kan slå opp og koble til. Dette er riktig standard for interne verktøy, fordi publikummet allerede er autentisert av tailnettet og du ikke legger til en offentlig flate. URL-en ser ut som et vanlig nettsted, og det er nettopp derfor folk tar den for å være ett.
Serve kan også legge ved identitetshoder som beskriver tailnet-brukeren på forespørslene den videresender. Hvis applikasjonen din stoler på disse hodene som autentisering, bind backend-en til localhost slik at ingenting annet kan nå den direkte; en backend som lytter på en ruterbar adresse kan motta forespørsler som aldri har gått gjennom proxyen.
Funnel endrer publikummet til det åpne internettet
Funnel publiserer en valgt tjeneste til alle som har URL-en, og besøkende trenger ikke klienten, en konto eller medlemskap i tailnettet ditt. Ressursen trenger derfor autentiseringen, hastighetsbegrensningen og oppdateringene du ville brukt på enhver offentlig tjeneste. Offentlige forespørsler bærer ikke Servens tailnet-identitetshoder, så en applikasjon som stolte på dem, har ingen brukeridentitet i det hele tatt under Funnel. Å velge en annen publiseringskommando svarer ikke på autentiseringsspørsmålet for deg.
Funnel har også begrensninger som en veiledning fra en eldre versjon kanskje ikke nevner. Den avslutter TLS med et sertifikat Tailscale skaffer for navnet, og den støtter bare bestemte lyttporter, slik Funnel-dokumentasjonen beskriver. Hvis tjenesten din forventer en annen protokoll enn HTTPS på en av disse portene, er Funnel feil verktøy og ikke et konfigurasjonspuslespill.
Les modusen fra klienten, ikke fra porten
Kontroller gjeldende tilstand før du deler noe, fordi de to modusene kan konfigureres for samme lokale port på forskjellige tidspunkter. Statuskommandoene rapporterer hva som faktisk er publisert og for hvem. Ikke utled publikummet fra at en URL svarer.
tailscale serve status
tailscale funnel status
tailscale status --json | head -40
Kommandosyntaksen har endret seg mellom klientversjoner, så et kopiert kall kan velge en annen modus enn den du mente. Foretrekk den dokumenterte formen for versjonen du kjører, og les bekreftelsen klienten skriver ut i stedet for å anta den. Hvis både en Serve- og en Funnel-konfigurasjon finnes, er den offentlige den som betyr noe for eksponering. Nullstill konfigurasjonen du ikke mente, i stedet for å legge enda en oppå.
Stopp og les statusen på nytt hvis utdataene ikke navngir publikummet. En publisert URL uten angitt publikum er en gjetning, og gjetninger er måten interne dashbord havner på det åpne internettet.
Test med publikummet du faktisk mente
Test utenfra tailnettet, ikke fra maskinen som publiserte tjenesten. En forespørsel fra en enhet i tailnettet beviser at proxyen virker; den beviser ikke at en fremmed er utelukket. Bruk et nettverk uten Tailscale-klient og uten rute inn i tailnettet.
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
For et internt dashbord bør den eksterne forespørselen mislykkes i å koble til eller mislykkes i autorisasjon, og den interne forespørselen bør lykkes med identiteten du forventer. For en offentlig tjeneste bør den eksterne forespørselen lykkes, og applikasjonen bør be om sine egne legitimasjoner. Noter hvilket av disse to utfallene du observerte, fordi URL-en alene ikke forteller deg det. Hvis resultatet er det motsatte av hensikten, fjern den offentlige konfigurasjonen først og undersøk etterpå.
Å publisere en tjeneste er heller ikke samme beslutning som å velge en exit node, som styrer hvor den utgående trafikken din forlater. Serve og Funnel svarer på hvem som kan nå noe du kjører; en exit node svarer på hvor dine egne tilkoblinger ser ut til å komme fra. Hold de to spørsmålene fra hverandre, og sammenligningen forblir enkel.