Tailscale serve a funnel: różnice i zastosowanie

tailscale serve a funnel: kto ma dostęp do adresu URL

Różnica między tailscale serve a tailscale funnel sprowadza się wyłącznie do grupy odbiorców. serve uruchamia interfejs HTTPS (hypertext transfer protocol secure) na lokalnym porcie i udostępnia go wyłącznie wewnątrz sieci tailnet. funnel udostępnia ten sam lokalny port całemu publicznemu internetowi za pośrednictwem serwerów przekaźnikowych obsługiwanych przez Tailscale. Oba polecenia przyjmują te same flagi i cele. Jedno słowo decyduje o tym, czy panel sterowania pozostanie prywatny, czy będzie dostępny dla każdego.

Oba polecenia zapewniają certyfikat zaufany przez przeglądarki, przypisany do nazwy kończącej się na ts.net, i żadne z nich nie wymaga otwierania portów przychodzących na firewallu VPS. Demon tailscaled utrzymuje aktywne połączenie z siecią tailnet, przez które przesyłany jest ruch. Podłączenie serwera do sieci tailnet to jedno zadanie, które opisano w sekcjach uruchamianie VPS jako węzła wyjściowego Tailscale oraz konfiguracja routera podsieci dla sieci prywatnej. Niniejsza sekcja dotyczy publikowania usługi, która już znajduje się wewnątrz sieci tailnet.

Wymagania wstępne dla poprawnego działania poleceń

• Tailscale w wersji 1.38.3 lub nowszej na serwerze VPS, zalogowany do sieci tailnet. Sprawdź wersję za pomocą tailscale version oraz tailscale status.
• Włączona usługa MagicDNS. MagicDNS to wbudowany system DNS (domain name system) w Tailscale, który nadaje maszynie nazwę taką jak blog-vps.your-tailnet.ts.net, zamiast korzystania wyłącznie z adresu 100.x.
• Włączone certyfikaty HTTPS dla sieci tailnet, dostępne na stronie DNS w konsoli administracyjnej. Bez tego nie będzie dostępny certyfikat, który można przypisać do portu.
• Wyłącznie dla funnel: atrybut węzła funnel w pliku polityki sieci tailnet. To etap, na którym kończy się większość pierwszych prób konfiguracji; szczegóły opisano poniżej.

Każde polecenie w tym miejscu wymaga użycia sudo, ponieważ interfejs CLI komunikuje się z tailscaled poprzez gniazdo, do którego zapis może wykonywać tylko użytkownik root. Aby nadać wybranemu użytkownikowi uprawnienie do pominięcia tego wymogu, wykonaj:

sudo tailscale set --operator=$USER

Publikacja w sieci tailnet za pomocą tailscale serve

Wskaż serve na lokalny port, a resztą zajmie się narzędzie.

sudo tailscale serve 3000

Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

Samo 3000 jest skrótem dla http://127.0.0.1:3000. Tailscale nasłuchuje na porcie 443 adresu tailnet danego urządzenia, kończy połączenie TLS (transport layer security) przy użyciu certyfikatu ts.net i przekazuje czysty protokół HTTP na wskazany port lokalny. Aplikacja nie musi posiadać informacji o istnieniu certyfikatu; jest to główny powód, dla którego warto stosować to rozwiązanie przed panelem administracyjnym, który w innym przypadku pozostałby dostępny przez zwykłe HTTP.

Należy zwrócić uwagę na ostatnią linię: Press Ctrl+C to exit. Polecenie działa w pierwszym planie, a mapowanie istnieje tylko w ramach tego procesu. Zamknięcie terminala powoduje przerwanie działania adresu URL, ponieważ konfiguracja nie została zapisana na dysku. Dodanie flagi --bg powoduje zapisanie mapowania w konfiguracji serve węzła, co zapewnia trwałość ustawień po zamknięciu terminala oraz po restarcie systemu.

sudo tailscale serve --bg 3000

Polecenie serve obsługuje więcej niż tylko numer portu. --set-path montuje usługę w podkatalogu, dzięki czemu wiele aplikacji może współdzielić jedną nazwę hosta:

sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090

Celem może być również katalog plików statycznych lub backend, który już obsługuje TLS za pomocą certyfikatu, którego weryfikacja nie jest wymagana:

sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443

Rozwiązanie nie ogranicza się tylko do HTTP. --tcp=<port> przekazuje surowy strumień TCP (transmission control protocol), a --tls-terminated-tcp=<port> kończy połączenie TLS na węźle i przekazuje czysty tekst dalej, co pozwala na umieszczenie zaufanego certyfikatu przed usługą, która w ogóle nie obsługuje protokołu HTTP:

sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899

Dlaczego funnel zgłasza, że atrybut węzła nie jest ustawiony?

Funkcja funnel jest domyślnie wyłączona dla całej sieci tailnet. Pierwsze uruchomienie kończy się wyświetleniem tego komunikatu i przerwaniem działania:

Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.

Polecenie było poprawne. Polityka sieci tailnet nie nadała temu węzłowi uprawnień do publikowania, więc klient odmawia wykonania operacji, zanim jeszcze skontaktuje się z przekaźnikiem. Należy edytować plik polityki tailnet w konsoli administracyjnej, w sekcji Access Controls, i dodać atrybut:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

autogroup:member przyznaje to uprawnienie każdemu członkowi sieci tailnet. Jeśli publikować ma tylko jedna maszyna, należy otagować tę maszynę i wskazać tag, na przykład tag:public. Po zapisaniu polityki należy ponownie uruchomić polecenie funnel.

Jeśli konto posiada uprawnienia administratora tailnet, nowsze wersje klientów oferują skrót: interfejs CLI wyświetla adres URL zgody na login.tailscale.com, a przejście pod niego aktywuje certyfikaty HTTPS i automatycznie dodaje wymagany atrybut. Jeśli użytkownik nie jest administratorem, ten adres URL nie będzie pomocny. Edycji musi dokonać osoba posiadająca dostęp do polityk.

Publikacja w Internecie za pomocą Tailscale Funnel

Gdy atrybut zostanie ustawiony, polecenie jest tym samym, które jest już znane, z użyciem innego czasownika.

sudo tailscale funnel --bg 3000

Available on the internet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

Należy każdorazowo czytać pierwszą linię. Available within your tailnet oraz Available on the internet to jedyne widoczne różnice między usługą prywatną a publiczną, a polecenia generujące je różnią się tylko jednym słowem.

Według stanu na sierpień 2026, funnel nasłuchuje wyłącznie na porcie 443, 8443 lub 10000. Wartością domyślną jest 443, a alternatywy stanowią --https=8443 lub --https=10000. Każdy inny port jest odrzucany, ponieważ przekaźniki funnel akceptują połączenia tylko na tych portach. Z tego powodu adres URL funnel zawsze składa się z samej nazwy hosta lub nazwy hosta z doklejonym :8443.

Jak sprawdzić, co jest aktualnie opublikowane?

Zgadywanie to najczęstsza przyczyna pozostawienia panelu sterowania publicznie dostępnym przez miesiąc. Należy zapytać o to sam węzeł.

tailscale serve status
tailscale funnel status
tailscale serve status --json

Oba polecenia statusu odczytują tę samą konfigurację, więc każde z nich przedstawia pełny obraz sytuacji. W skryptach lub zaplanowanych zadaniach należy używać formy --json, ponieważ zwykłe wyjście jest przeznaczone dla ludzi. Jeśli nic nie zostało skonfigurowane, wyświetlona zostanie tylko jedna linia:

No serve config

Jeśli taki komunikat pojawia się po konfiguracji, która wcześniej działała, oznacza to, że mapowanie zostało utworzone w pierwszym planie, a proces został zakończony. Należy utworzyć je ponownie za pomocą --bg.

Aby usunąć pojedyncze mapowanie, należy powtórzyć polecenie, które je utworzyło, dodając na końcu off. Aby usunąć wszystkie mapowania typu serve oraz funnel na węźle, należy użyć reset.

sudo tailscale funnel --https=443 3000 off
sudo tailscale serve reset

Po wykonaniu którejkolwiek z tych operacji należy ponownie uruchomić tailscale serve status i sprawdzić stan faktyczny, zamiast zakładać, że polecenie wykonało zamierzone działanie.

Zyski i straty

Zyski są wymierne i to one decydują o wyborze tego rozwiązania zamiast reverse proxy.

• Certyfikat zaufany przez przeglądarki, odnawiany automatycznie. Brak konieczności instalacji klienta ACME (automatic certificate management environment) oraz ryzyka zapomnienia o odnowieniu.
• Brak otwartych portów przychodzących na firewallu VPS. tailscaled nawiązuje połączenia wychodzące, dzięki czemu domyślna polityka deny na firewallu ufw na VPS może pozostać w pełni restrykcyjna.
• Brak konieczności zakupu, kierowania lub oczekiwania na propagację rekordów DNS.
• Brak konieczności przekierowywania portów, co jest kluczowe w przypadku maszyn za NAT (network address translation), w przeciwieństwie do VPS z publicznym adresem IP.

Koszty są równie realne i wszystkie wynikają z natury usługi funnel.

• Nazwa nie należy do użytkownika. Publiczni odwiedzający widzą host.your-tailnet.ts.net. Funnel nie wspiera własnych domen, więc nie można umieścić przed nim app.example.com.
• Ścieżka nie należy do użytkownika. Ruch najpierw trafia do przekaźnika Tailscale, który następnie przekazuje strumień do węzła przez tailnet. Tailscale informuje, że ruch funnel podlega limitom przepustowości, które nie są publikowane i nie można ich konfigurować, dlatego należy samodzielnie zmierzyć przepustowość przed poleganiem na konkretnych wartościach.
• Brak kontroli. Własny reverse proxy zapewnia dostęp do logów, limitów zapytań, ograniczeń rozmiaru żądań oraz miejsca na implementację uwierzytelniania. Funnel dostarcza jedynie adres URL. Wszystkie pozostałe elementy muszą zostać zaimplementowane wewnątrz aplikacji.
• Lista portów jest ograniczona, zgodnie z powyższym.

Obie funkcje opierają się na infrastrukturze zarządzanej przez Tailscale: wystawianiu certyfikatów dla nazwy ts.net oraz samych przekaźnikach funnel. W przypadku rozważania samodzielnie hostowanego serwera kontrolnego Headscale, nie należy zakładać, że obie funkcje będą dostępne. Należy sprawdzić informacje o wydaniu (release notes) dla planowanej wersji Headscale.

Które rozwiązanie wybrać?

Zasada jest krótka.

Użyj serve do wszystkiego, co wewnętrzne: interfejsów administracyjnych, paneli nawigacyjnych, interfejsów metryk, których nie chcesz indeksować, lub kopii testowej witryny. Przynależność do sieci tailnet stanowi kontrolę dostępu i jest to rozwiązanie skuteczne. Urządzenie niebędące w sieci tailnet nie jest nawet w stanie rozwiązać nazwy hosta.

Użyj funnel dla linku demonstracyjnego, odbiornika webhook, do którego strona trzecia musi wysłać żądanie POST, lub wywołania zwrotnego OAuth podczas programowania. Jest to najszybsza droga do uzyskania publicznego adresu URL HTTPS, a jedno polecenie off kończy jego działanie. Należy jednak pamiętać, że publiczny oznacza publiczny: nazwa hosta nie jest tajemnicą, a tunel (funnel) przed aplikacją bez logowania to otwarta usługa. Wszystko, co znajduje się za nim, musi uwierzytelniać własne żądania z taką samą starannością, jakiej wymaga wystawiony punkt końcowy Ollama API.

Do wszystkiego, co określiłbyś mianem środowiska produkcyjnego, użyj profesjonalnego reverse proxy. Własna domena, własny certyfikat, własne logi, własne limity zapytań i brak osób trzecich na ścieżce żądania. Porównanie nginx, Caddy i Traefik jako reverse proxy pomoże w wyborze odpowiedniego narzędzia.

Tryby awarii i towarzyszące im komunikaty

Funnel odmawia uruchomienia. Funnel not available; "funnel" node attribute not set. oznacza problem z polityką, a nie z samym poleceniem. Dodaj atrybut funnel do pliku polityki tailnet, zapisz go i ponów próbę.

Działało, a teraz tailscale serve status zwraca No serve config. Mapowanie zostało utworzone w pierwszym planie, a proces ten zakończył działanie. Uruchom ponownie to samo polecenie z flagą --bg.

Nazwa jest rozpoznawana, ale brak odpowiedzi. Serwer proxy przekazuje ruch do wskazanego celu, więc jeśli usługa nie nasłuchuje pod danym adresem, nie ma czego przekazywać. Potwierdź stan usługi za pomocą ss -ltnp | grep 3000 na tej samej maszynie, na której uruchomiono tailscaled. Częstą przyczyną jest kontener publikujący port na adresie bridge Docker zamiast na 127.0.0.1, co oznacza, że host nie widzi żadnego procesu nasłuchującego w oczekiwanym miejscu. Jak działa sieć w Docker Compose wyjaśnia, gdzie faktycznie trafia opublikowany port.

Błędy certyfikatu dla nazwy ts.net. Certyfikaty HTTPS prawdopodobnie nie są włączone dla tailnet. Włącz je w konsoli administracyjnej, a następnie wykonaj krok certyfikacji osobno, aby jego błędy nie mieszały się z wynikami działania polecenia serve:

sudo tailscale cert your-host.your-tailnet.ts.net

Funnel ładuje się w sieci komórkowej, ale zachowuje się inaczej niż na laptopie. Laptop znajduje się wewnątrz tailnet, więc MagicDNS rozpoznaje nazwę jako adres 100.x i usługa jest osiągana bezpośrednio, bez udziału przekaźnika. Jest to poprawne zachowanie, które oznacza, że laptop nie może służyć do testowania publicznej dostępności. Użyj curl z maszyny, która nie znajduje się wewnątrz tailnet.

FAQ

Jaka jest różnica między tailscale serve a tailscale funnel?

Różnica dotyczy tego, kto ma dostęp do wyniku. tailscale serve udostępnia port lokalny pod adresem HTTPS, który jest dostępny tylko dla urządzeń w Twojej sieci tailnet. tailscale funnel udostępnia ten sam port pod adresem dostępnym dla każdego użytkownika Internetu, kierując ruch przez serwery przekaźnikowe (relay) obsługiwane przez Tailscale. Flagi oraz cele są wspólne dla obu poleceń. Pierwsza linia wyjściowa informuje, który tryb został uruchomiony: Available within your tailnet lub Available on the internet.

Dlaczego tailscale funnel zwraca błąd o nieustawionym atrybucie węzła?

Ponieważ funkcja funnel jest wyłączona dla sieci tailnet, dopóki administrator jej nie włączy. Komunikat Funnel not available; "funnel" node attribute not set. pochodzi z Twojego klienta, zanim nastąpi połączenie z jakimkolwiek przekaźnikiem. Dodaj wpis nodeAttrs, przyznając atrybut funnel dla autogroup:member (lub dla znacznika, jeśli tylko jedna maszyna ma publikować usługi) w pliku polityki sieci tailnet w sekcji Access Controls. Administrator sieci tailnet może również skorzystać z adresu URL zgody, który wyświetla CLI.

Z jakich portów może korzystać Tailscale Funnel?

Tylko z 443, 8443 oraz 10000. Domyślnym portem jest 443, a inny można wybrać za pomocą --https=8443 lub --https=10000. Jest to ograniczenie przekaźników funnel, a nie serwera, więc żadna zmiana w zaporze sieciowej ani konfiguracji VPS go nie zniesie. tailscale serve nie posiada takiego ograniczenia, ponieważ ruch nigdy nie opuszcza sieci tailnet.

Czy adres URL utworzony przez serve lub funnel przetrwa restart?

Tylko jeśli użyto flagi --bg. Bez niej polecenie działa na pierwszym planie, wyświetla Press Ctrl+C to exit., a mapowanie znika wraz z procesem. Z flagą --bg mapowanie jest zapisywane w konfiguracji serve węzła i przywracane wraz z tailscaled po restarcie. Stan można sprawdzić za pomocą tailscale serve status, które wyświetla No serve config, gdy nic nie jest skonfigurowane.

Czy pozostawienie uruchomionego funnel jest bezpieczne?

Jest bezpieczne pod względem transportu: połączenie jest szyfrowane HTTPS, a na zaporze sieciowej nie jest otwarty żaden port. Nie jest jednak bezpieczne w potocznym rozumieniu, ponieważ adres URL jest publiczny, a co za tym idzie – aplikacja za nim również. Utrzymuj funnel tylko przed usługami, które same uwierzytelniają żądania, i wyłączaj go po zakończeniu testów lub prezentacji, używając polecenia, które go utworzyło, z dopiskiem off na końcu.

Źródła powyższych informacji o działaniu poleceń: dokumentacja Tailscale Serve i Funnel oraz dokumentacja CLI pod adresem tailscale.com/docs.