Tailscale Serve eller Funnel: hvem kan egentlig åbne linket?

Begge kommandoer publicerer en lokal tjeneste gennem et Tailscale HTTPS-navn, og fra maskinen, der kører dem, ser de næsten identiske ud. Forskellen er, hvem der bagefter kan nå URL'en, og den forskel afgør, hvilke kontroller din applikation stadig har brug for. Serve holder publikum inde i tailnettet, mens Funnel flytter det ud på det åbne internet. Vælg publikum først, og vælg derefter den kommando, der passer til det.

Serve besvarer et spørgsmål inde i dit tailnet

Serve proxyer en lokal port eller leverer lokalt indhold til enheder på dit tailnet, og tailnettets adgangsregler gælder stadig for hver anmodning. Et dashboard på port 3000 bliver tilgængeligt på et HTTPS-navn, som kun dine enheder kan slå op og oprette forbindelse til. Det er standardindstillingen for interne værktøjer, fordi publikum allerede er godkendt af tailnettet, og du ikke tilføjer en offentlig flade. URL'en ligner et almindeligt websted, og det er netop derfor, folk tager den for et.

Serve kan også vedhæfte identitetsheadere, der beskriver tailnet-brugeren, til de anmodninger, den videresender. Hvis din applikation stoler på disse headere som godkendelse, skal du binde backenden til localhost, så intet andet kan nå den direkte; en backend, der lytter på en routingbar adresse, kan modtage anmodninger, der aldrig har været gennem proxyen.

Funnel ændrer publikum til det åbne internet

Funnel publicerer en udvalgt tjeneste til enhver, der har URL'en, og besøgende har ikke brug for klienten, en konto eller medlemskab af dit tailnet. Ressourcen har derfor brug for den godkendelse, hastighedsbegrænsning og de patches, du ville anvende på enhver offentlig tjeneste. Offentlige anmodninger bærer ikke Serves tailnet-identitetsheadere, så en applikation, der stolede på dem, har slet ingen brugeridentitet under Funnel. At vælge en anden publiceringskommando besvarer ikke godkendelsesspørgsmålet for dig.

Funnel har også begrænsninger, som en vejledning fra en ældre version måske ikke nævner. Den afslutter TLS med et certifikat, som Tailscale skaffer til navnet, og den understøtter kun bestemte lytteporte, som Funnel-dokumentationen beskriver. Hvis din tjeneste forventer en anden protokol end HTTPS på en af disse porte, er Funnel det forkerte værktøj og ikke et konfigurationspuslespil.

Læs tilstanden fra klienten, ikke fra porten

Kontroller den aktuelle tilstand, før du deler noget, fordi de to tilstande kan konfigureres til den samme lokale port på forskellige tidspunkter. Statuskommandoerne rapporterer, hvad der faktisk er publiceret, og til hvem. Udled ikke publikum af, at en URL svarer.

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

Kommandosyntaksen er ændret gennem klientversioner, så et kopieret kald kan vælge en anden tilstand end den, du havde tænkt dig. Foretræk den dokumenterede form til den version, du kører, og læs den bekræftelse, klienten udskriver, i stedet for at antage den. Hvis både en Serve- og en Funnel-konfiguration findes, er den offentlige den, der betyder noget for eksponering. Nulstil den konfiguration, du ikke mente, i stedet for at lægge endnu en ovenpå.

Stop og læs statussen igen, hvis outputtet ikke navngiver publikum. En publiceret URL uden et angivet publikum er et gæt, og gæt er måden, hvorpå interne dashboards ender på det åbne internet.

Test med det publikum, du faktisk mente

Test udefra tailnettet, ikke fra maskinen, der publicerede tjenesten. En anmodning fra en enhed i tailnettet beviser, at proxyen virker; den beviser ikke, at en fremmed er udelukket. Brug et netværk uden Tailscale-klient og uden rute ind 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 dashboard bør den eksterne anmodning fejle med at oprette forbindelse eller fejle med autorisation, og den interne anmodning bør lykkes med den identitet, du forventer. For en offentlig tjeneste bør den eksterne anmodning lykkes, og applikationen bør spørge efter sine egne legitimationsoplysninger. Noter, hvilket af de to udfald du observerede, fordi URL'en alene ikke fortæller dig det. Hvis resultatet er det modsatte af hensigten, skal du først fjerne den offentlige konfiguration og undersøge bagefter.

At publicere en tjeneste er heller ikke den samme beslutning som at vælge en exit node, som styrer, hvor din udgående trafik forlader netværket. Serve og Funnel besvarer, hvem der kan nå noget, du kører; en exit node besvarer, hvor dine egne forbindelser ser ud til at komme fra. Hold de to spørgsmål adskilt, og sammenligningen forbliver enkel.