Tailscale Serve a Funnel: kto naprawdę może otworzyć link?

Serve udostępnia usługę w Twoim tailnecie, a Funnel wystawia ją do otwartego internetu. Porównaj odbiorców, nagłówki tożsamości i porty, które dopuszcza Funnel.

Oba polecenia publikują lokalną usługę pod nazwą HTTPS Tailscale i z maszyny, która je uruchamia, wyglądają prawie identycznie. Różnica polega na tym, kto może później dotrzeć do adresu URL, i ta różnica decyduje o tym, jakich kontroli Twoja aplikacja nadal potrzebuje. Serve trzyma odbiorców wewnątrz tailnetu, a Funnel przenosi ich do otwartego internetu. Najpierw wybierz odbiorców, a potem polecenie, które do nich pasuje.

Serve odpowiada na pytanie wewnątrz Twojego tailnetu

Serve pośredniczy w ruchu do lokalnego portu lub serwuje lokalną treść urządzeniom w Twoim tailnecie, a reguły dostępu tailnetu nadal obowiązują przy każdym żądaniu. Panel na porcie 3000 staje się dostępny pod nazwą HTTPS, którą mogą rozwiązać i z którą mogą się połączyć tylko Twoje urządzenia. To właściwe ustawienie domyślne dla narzędzi wewnętrznych, ponieważ odbiorcy są już uwierzytelnieni przez tailnet, a Ty nie dodajesz publicznej powierzchni. Adres URL wygląda jak zwykła strona internetowa i właśnie dlatego ludzie biorą go za taką.

Serve może też dołączać do przekazywanych żądań nagłówki tożsamości opisujące użytkownika tailnetu. Jeśli Twoja aplikacja ufa tym nagłówkom jako uwierzytelnieniu, przypnij backend do localhost, aby nic innego nie mogło dotrzeć do niego bezpośrednio; backend nasłuchujący na adresie routowalnym może odbierać żądania, które nigdy nie przeszły przez proxy.

Funnel zmienia odbiorców na otwarty internet

Funnel publikuje wybraną usługę dla każdego, kto ma adres URL, a odwiedzający nie potrzebują klienta, konta ani członkostwa w Twoim tailnecie. Zasób wymaga więc uwierzytelniania, ograniczania szybkości i poprawek, które zastosowałbyś do każdej publicznej usługi. Publiczne żądania nie niosą nagłówków tożsamości tailnetu od Serve, więc aplikacja, która na nich polegała, pod Funnel nie ma żadnej tożsamości użytkownika. Wybór innego polecenia publikacji nie odpowiada za Ciebie na pytanie o uwierzytelnianie.

Funnel ma też ograniczenia, których poradnik ze starszej wersji może nie wspominać. Kończy TLS certyfikatem, który Tailscale uzyskuje dla nazwy, i obsługuje tylko określone porty nasłuchu, jak opisuje dokumentacja Funnel. Jeśli Twoja usługa oczekuje protokołu innego niż HTTPS na jednym z tych portów, Funnel jest niewłaściwym narzędziem, a nie zagadką konfiguracyjną.

Czytaj tryb z klienta, nie z portu

Sprawdź bieżący stan, zanim cokolwiek udostępnisz, ponieważ oba tryby można skonfigurować dla tego samego lokalnego portu w różnych momentach. Polecenia stanu raportują, co jest faktycznie opublikowane i dla kogo. Nie wnioskuj o odbiorcach z faktu, że adres URL odpowiada.

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

Składnia poleceń zmieniała się między wersjami klienta, więc skopiowane wywołanie może wybrać inny tryb niż zamierzony. Preferuj udokumentowaną formę dla używanej wersji i czytaj potwierdzenie wypisywane przez klienta, zamiast je zakładać. Jeśli istnieje konfiguracja zarówno Serve, jak i Funnel, publiczna jest tą, która liczy się dla ekspozycji. Zresetuj konfigurację, której nie miałeś na myśli, zamiast dokładać kolejną.

Zatrzymaj się i przeczytaj stan ponownie, jeśli dane wyjściowe nie nazywają odbiorców. Opublikowany adres URL bez wskazanych odbiorców to zgadywanie, a zgadywanie to sposób, w jaki wewnętrzne panele trafiają do otwartego internetu.

Testuj z odbiorcami, których naprawdę miałeś na myśli

Testuj spoza tailnetu, a nie z maszyny, która opublikowała usługę. Żądanie z urządzenia w tailnecie dowodzi, że proxy działa; nie dowodzi, że obcy jest wykluczony. Użyj sieci bez klienta Tailscale i bez trasy do tailnetu.

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

Dla wewnętrznego panelu zewnętrzne żądanie powinno nie połączyć się lub nie przejść autoryzacji, a wewnętrzne żądanie powinno się udać z oczekiwaną tożsamością. Dla usługi publicznej zewnętrzne żądanie powinno się udać, a aplikacja powinna poprosić o własne dane logowania. Zapisz, który z tych dwóch wyników zaobserwowałeś, ponieważ sam adres URL tego nie mówi. Jeśli wynik jest przeciwny do zamierzenia, najpierw usuń publiczną konfigurację, a potem prowadź dochodzenie.

Publikowanie usługi to też nie ta sama decyzja co wybór węzła wyjściowego, który kontroluje, skąd wychodzi Twój ruch wychodzący. Serve i Funnel odpowiadają, kto może dotrzeć do czegoś, co uruchamiasz; węzeł wyjściowy odpowiada, skąd wyglądają na pochodzące Twoje własne połączenia. Trzymaj te dwa pytania osobno, a porównanie pozostaje proste.

Powiązane artykuły