Czy Tailscale jest bezpieczny? Analiza modelu zaufania

Czy Tailscale jest bezpieczny? Krótka odpowiedź

Czy Tailscale jest bezpieczny? W zakresie, który budzi największe obawy większości użytkowników – tak: serwer koordynujący, który zarządza siecią tailnet, nigdy nie przechowuje kluczy prywatnych szyfrujących ruch, więc nie może odczytać danych przesyłanych między urządzeniami. Strona dotycząca bezpieczeństwa Tailscale stwierdza to wprost: „Klucze prywatne nigdy nie opuszczają urządzenia. Cały ruch jest zawsze szyfrowany metodą end-to-end”. Istotne pytanie brzmi jednak inaczej. Serwer koordynujący, który został przejęty lub działa pod przymusem prawnym, nie musi odczytywać pakietów. Decyduje on o tym, którym kluczom publicznym ufają urządzenia, więc mógłby zarejestrować urządzenie, którego użytkownik nigdy nie autoryzował.

Oto model zaufania w jednym zdaniu: szyfrowanie chroni dane, a płaszczyzna sterowania decyduje o członkostwie. Każda z poniższych sekcji wskazuje jedną stronę, której należy zaufać, określa jej rzeczywiste możliwości oraz wskazuje mechanizmy kontroli, które je ograniczają. Jeśli produkt jest nowy, warto zacząć od czym jest Tailscale i jak działa jego sieć mesh.

Płaszczyzna sterowania i płaszczyzna danych są odseparowane

Tailscale to mesh VPN (wirtualna sieć prywatna) oparta na WireGuard, czyli tym samym protokole, który można skonfigurować ręcznie na własnym serwerze VPS z WireGuard. Każde urządzenie generuje własną parę kluczy WireGuard lokalnie. Wpis na blogu Tailscale dotyczący tego, jak to działa, określa serwer koordynujący jako „wspólną skrzynkę na klucze publiczne” i podkreśla, że „klucz prywatny nigdy, pod żadnym pozorem, nie opuszcza swojego węzła”.

Płaszczyzna danych to zaszyfrowany ruch między urządzeniami. Przepływa on bezpośrednio między nimi, o ile pozwala na to konfiguracja sieci. Płaszczyzna sterowania obejmuje wszystko inne: listę urządzeń należących do tailnetu, przypisanie kluczy publicznych do urządzeń, polityki dostępu, ustawienia DNS oraz listę przekaźników. Tailscale obsługuje płaszczyznę sterowania jako usługę hostowaną. Płaszczyznę danych użytkownik uruchamia na własnych maszynach.

Rozdzielenie tych dwóch elementów pozwala odpowiedzieć na każde pytanie dotyczące bezpieczeństwa. Szyfrowanie jest właściwością płaszczyzny danych. Przynależność do sieci jest decyzją płaszczyzny sterowania. Żaden poziom szyfrowania nie określa, kto jest uprawniony do bycia peerem w sieci.

Co może zrobić przejęty serwer koordynacyjny?

Nie może odszyfrować ruchu. Klucze służące do szyfrowania są generowane na urządzeniach użytkownika i nigdy nie są przesyłane na zewnątrz, więc nie ma danych, które można przejąć lub ujawnić, aby otworzyć tunel. Dotyczy to również ruchu przekaźnikowego, co zostało omówione w dalszej części.

Może zarejestrować węzeł. Gdy Tailscale ogłosiło funkcję tailnet lock, firma opisała to ryzyko własnymi słowami: złośliwy serwer mógłby „użyć potajemnie dodanego węzła do wysyłania lub odbierania ruchu do istniejących węzłów” i w takim przypadku „nie miałoby znaczenia, że ruch jest szyfrowany, ponieważ sam partner byłby złośliwy”. Urządzenie ufa partnerowi, ponieważ płaszczyzna sterowania poinformowała je, że dany klucz należy do sieci tailnet.

Może zmienić zakres dostępności urządzeń. Polityka dostępu znajduje się w płaszczyźnie sterowania i jest dystrybuowana do węzłów. Biała księga tailnet lock firmy Tailscale stwierdza, że tailnet lock „nie zapobiega sytuacji, w której przejęta płaszczyzna sterowania zakłóca łączność w sieci, na przykład poprzez niedostarczenie nowych kluczy węzłów lub rozpowszechnienie polityki kontroli dostępu, która odmawia dostępu wszystkim węzłom”.

W każdym przypadku widzi metadane połączeń. Logi przepływu sieciowego Tailscale rejestrują zdarzenia otwarcia i zamknięcia dla każdego połączenia między maszynami. Dokumentacja stanowi, że logi te „ściśle nie zawierają żadnych informacji o operacjach klienta ani zawartości ruchu sieciowego”. Płaszczyzna sterowania może zatem wiedzieć, które z urządzeń komunikowały się ze sobą i kiedy. Nie wie jednak, co zostało przesłane.

Tylko jeden punkt na tej liście dotyczy szyfrowania. Pozostałe odnoszą się do kwestii członkostwa oraz polityki sieciowej, dlatego mechanizmy kontrolne, na które należy zwrócić uwagę, to te regulujące proces rejestracji.

Dostawca tożsamości stanowi fundament zaufania w sieci tailnet

Tailscale nie zarządza własną bazą haseł. Dokumentacja wyraźnie wskazuje, że hasła Tailscale nie istnieją, a proces logowania jest delegowany do zewnętrznego dostawcy tożsamości (IdP): Apple, Google, GitHub, Microsoft, Okta, OneLogin lub dowolnego dostawcy zgodnego z OpenID Connect.

Należy traktować to jako deklarację bezpieczeństwa. Każdy, kto uzyska dostęp do konta Google lub Microsoft, może zalogować się do sieci tailnet. Uwierzytelnianie wieloskładnikowe (MFA) jest w pełni zależne od mechanizmów wymuszanych przez IdP. Proces wyrejestrowania użytkownika (offboarding) odbywa się zgodnie z procedurami obowiązującymi w IdP w momencie odejścia pracownika. Przejęcie konta IdP w wyniku phishingu oznacza przejęcie konta w sieci tailnet. Atakujący nie musi atakować protokołu WireGuard: wystarczy, że doda urządzenie i przejmie uprawnienia przypisane danemu użytkownikowi w polityce sieci.

Dwa mechanizmy kontrolne chronią przed dostępem nieautoryzowanego urządzenia w przypadku kradzieży tożsamości: zatwierdzanie urządzeń (device approval) oraz wygasanie kluczy (key expiry). Trzecim zabezpieczeniem jest Tailnet lock, który koncentruje się na płaszczyźnie sterowania (control plane), a nie na samym koncie użytkownika.

Zatwierdzanie urządzeń: nic nie dołącza do sieci bez zgody administratora

Dokumentacja Tailscale opisuje zatwierdzanie urządzeń jako funkcję, która „pozwala administratorom sieci Tailscale przeglądać i zatwierdzać nowe urządzenia, zanim będą mogły one dołączyć do sieci Tailscale”. Zatwierdzenia może dokonać właściciel (Owner), administrator (Admin) lub administrator IT. Nowe urządzenie wyświetla etykietę „Needs approval” na stronie Machines, dopóki ktoś nie podejmie odpowiednich działań.

Włączenie tej funkcji zmienia przebieg scenariusza z przejęciem konta. Atakujący loguje się, urządzenie rejestruje się, a następnie oczekuje bez dostępu do jakichkolwiek zasobów. W konsoli administracyjnej pojawia się etykieta informująca, że nierozpoznana maszyna próbuje dołączyć do sieci. Automatyzacja nadal działa, ponieważ klucz uwierzytelniający (auth key) można oznaczyć jako wstępnie zatwierdzony podczas generowania, a urządzenia mogą być zatwierdzane przez API.

Klucze uwierzytelniające to kolejna droga dostępu, dlatego należy traktować je jak poświadczenia. Dokumentacja Tailscale wprost ostrzega przed ryzykownymi wariantami: „Należy zachować szczególną ostrożność w przypadku kluczy wielokrotnego użytku! Mogą być one bardzo niebezpieczne w przypadku kradzieży. Najlepiej przechowywać je w przeznaczonych do tego produktach typu key vault”. Według stanu na sierpień 2026 r. udokumentowany zakres ważności klucza wynosi od 1 do 90 dni, a brak określenia daty wygaśnięcia skutkuje ustawieniem domyślnego maksimum 90 dni. Należy preferować klucze jednorazowe, oznaczać jako efemeryczne maszyny, które często zmieniają stan, oraz przechowywać wszelkie klucze wielokrotnego użytku zaszyfrowane za pomocą Ansible Vault lub w menedżerze sekretów, zamiast umieszczać je w skryptach powłoki.

Wygasanie kluczy: licznik ograniczający skutki każdego innego błędu

Klucze węzłów wygasają, co sprawia, że kradzież lub zapomnienie urządzenia staje się jedynie tymczasowym problemem. Dokumentacja Tailscale wskazuje, że „domyślnie nowe domeny mają ustawiony okres ważności wynoszący 180 dni” oraz że „jeśli ponowne uwierzytelnienie nie nastąpi, klucze wygasają, a połączenia do/z danego punktu końcowego przestają działać”. Urządzenie można uwierzytelnić ponownie samodzielnie:

tailscale up --force-reauth

Dokumentacja ostrzega, że może to „zerwać połączenie z tailnet, dlatego nie należy wykonywać tej czynności zdalnie przez SSH lub RDP bez alternatywnej metody logowania na wypadek utraty łączności”. Polecenie należy uruchomić, mając dostęp do konsoli lub korzystając z drugiej ścieżki dostępu do maszyny, ponieważ operacja ta przerywa używane połączenie sieciowe.

W przypadku serwerów kontrola ta jest często modyfikowana. Maszyna wymagająca ponownego uwierzytelnienia co 180 dni zostanie odłączona od tailnet o godzinie 3 nad ranem, gdy nikt nie monitoruje jej stanu, dlatego administratorzy wyłączają wygasanie kluczy na takich jednostkach. Usuwa to licznik, który docelowo unieważniłby skradziony klucz. Lepszym rozwiązaniem dla serwera jest urządzenie z przypisanym tagiem, ponieważ tag przypisuje maszynę do roli, a nie do konkretnej osoby, dzięki czemu maszyna pozostaje dostępna nawet po odejściu pracownika z firmy. Niezależnie od podjętej decyzji, należy prowadzić listę maszyn z wyłączonym wygasaniem kluczy: takie klucze pozostają ważne do momentu usunięcia urządzenia.

Tailnet lock: wyłączenie serwera koordynacji z łańcucha zaufania

Tailnet lock bezpośrednio rozwiązuje problem rejestracji węzłów. Dokumentacja tailnet lock w Tailscale wyjaśnia ten mechanizm: „Gdy nowy węzeł dołącza do tailnet, jego publiczny klucz węzła wymaga podpisu kluczem Tailnet Lock. Serwer koordynacji dystrybuuje podpisany publiczny klucz węzła do pozostałych węzłów”. Istniejące urządzenia weryfikują ten podpis przed zaakceptowaniem partnera, więc klucz węzła wygenerowany samodzielnie przez płaszczyznę sterowania (control plane) zostaje odrzucony.

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init aktywuje tę funkcję, a w tym samym momencie wyznacza się węzły podpisujące. Tailscale wymaga co najmniej dwóch węzłów podpisujących podczas inicjalizacji i pozwala na maksymalnie 20 w jednym tailnet. Po włączeniu, każde nowe urządzenie wymaga podpisu od jednego z nich, co wiąże się z realnym kosztem operacyjnym: dodanie telefonu wymaga wykonania polecenia na laptopie.

Limity są udokumentowane i mają większe znaczenie niż sam opis funkcji:

• Utrata klucza wyłączającego (disablement secret) oznacza brak możliwości odzyskania dostępu. Dokumentacja stwierdza: „Jeśli utracisz klucze wyłączające i nie przekazałeś żadnego z nich do wsparcia technicznego Tailscale, tailnet nie może zostać odzyskany”.
• Klucz podpisujący znajduje się na posiadanym urządzeniu, więc dziedziczy jego poziom bezpieczeństwa. Dokumentacja jest jednoznaczna: „Jeśli urządzenie zostanie przejęte, klucz może zostać wykradziony”.
• Nie można korzystać z obu mechanizmów kontroli jednocześnie. Tailscale wskazuje, że tailnet lock oraz zatwierdzanie urządzeń (device approval) wykluczają się wzajemnie, więc włączenie jednego oznacza rezygnację z drugiego.
• Jest to model zaufania przy pierwszym użyciu (TOFU). Początkowa konfiguracja nadal przechodzi przez płaszczyznę sterowania, a punkt zakotwiczenia zaufania przenosi się do własnej sieci dopiero po tym pierwszym kroku.

Tailnet lock chroni członkostwo w sieci. Nie chroni dostępności, co potwierdza dokumentacja techniczna (white paper).

Czy przekaźnikowe połączenie ujawnia mój ruch?

Nie. Gdy dwa urządzenia nie mogą połączyć się bezpośrednio, ruch jest przekierowywany przez serwer DERP (Designated Encrypted Relay for Packets). Dokumentacja Tailscale określa tę właściwość jednoznacznie: „Ponieważ klucze prywatne Tailscale nigdy nie opuszczają urządzenia, na którym zostały wygenerowane, serwer DERP nie jest w stanie odszyfrować ruchu. Serwer DERP jedynie ślepo przekazuje już zaszyfrowane pakiety między urządzeniami”.

Przekaźnik wpływa na szybkość połączenia i pozwala na wgląd w metadane: adresy dwóch zaszyfrowanych punktów końcowych, czas trwania sesji oraz wolumen przesyłanych danych. Można sprawdzić, jaki typ połączenia jest aktualnie używany:

tailscale status
tailscale netcheck

tailscale status oznacza każdego partnera jako bezpośredniego, co jest wyświetlane jako direct 203.0.113.10:41641, lub przekaźnikowego, co jest wyświetlane jako relay wraz z nazwą przekaźnika i licznikami bajtów. Jeśli partner pozostaje w trybie przekaźnikowym, oznacza to, że urządzenia nie mogły nawiązać bezpośredniego połączenia. Zazwyczaj wynika to z blokady protokołu UDP lub faktu, że obie strony znajdują się za restrykcyjnym NAT (network address translation). tailscale netcheck informuje, czy protokół UDP działa poprawnie na danej maszynie, w jaki sposób NAT mapuje porty oraz jaka jest latencja do najbliższych przekaźników, co pozwala ustalić przyczynę problemu.

Węzeł wyjściowy przenosi punkt wyjścia, nie usuwa go

Węzeł wyjściowy kieruje cały publiczny ruch internetowy urządzenia przez inne urządzenie w sieci tailnet, korzystając z domyślnych tras 0.0.0.0/0 oraz ::/0. W systemie Linux maszyna oferująca tę usługę ogłasza ją, a każdy klient decyduje o jej użyciu:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Węzeł wyjściowy musi zostać zatwierdzony przez właściciela (Owner), administratora (Admin) lub administratora sieci (Network admin) w konsoli administracyjnej, a polityka musi przyznawać autogroup:internet, zanim klient będzie mógł z niego skorzystać. Oba kroki są celowe: niezatwierdzona maszyna nie może po cichu stać się bramą wyjściową dla całego tailnetu.

Teraz kwestia zaufania. Ruch jest szyfrowany od laptopa do węzła wyjściowego. Następnie opuszcza on tę maszynę jako zwykły ruch internetowy, posługując się adresem IP tej maszyny. Operator węzła wyjściowego widzi zatem miejsca docelowe użytkownika, podobnie jak dostawca hostingu tej maszyny oraz jej sieć nadrzędna. Punkt obserwacji został przeniesiony, a nie usunięty. Jest to korzystny kompromis, gdy użytkownik kontroluje zdalny koniec połączenia, co stanowi argument za uruchomieniem własnego węzła wyjściowego na VPS, natomiast w przeciwnym przypadku jest to rozwiązanie niekorzystne.

Domyślna polityka to sieć płaska

Nowa sieć tailnet jest domyślnie otwarta. Dokumentacja kontroli dostępu Tailscale wskazuje, że domyślny plik polityki „umożliwia komunikację między wszystkimi urządzeniami wewnątrz tailnet”. Każde urządzenie może połączyć się z każdym innym na dowolnym porcie. Jest to sieć płaska. Przeniesienie jej do wnętrza tunelu chroni przed podmiotami zewnętrznymi, ale nie zabezpiecza przed zainfekowanym laptopem.

Należy zaostrzyć zasady w pliku polityki tailnet, który akceptuje listy kontroli dostępu (ACL) lub nowsze mechanizmy grants, oba zapisane w dialekcie JSON dopuszczającym komentarze:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

Ta polityka pozwala jednej grupie na dostęp przez SSH do serwerów produkcyjnych, umożliwia członkom korzystanie z węzła wyjściowego (exit node) i domyślnie blokuje wszystko inne. Tailscale publikuje listę dostępnych reguł w zależności od planu, dlatego należy to zweryfikować przed projektowaniem struktury opartej na tagach lub autogroups, a także sprawdzić co faktycznie zawiera darmowy plan. W przypadku urządzenia, które nigdy nie powinno przyjmować połączeń przychodzących, takiego jak telefon osobisty, tailscale set --shields-up blokuje je na poziomie klienta.

Co zmienia samodzielne hostowanie płaszczyzny sterowania za pomocą Headscale

Headscale to „otwartoźródłowa, samodzielnie hostowana implementacja serwera sterowania Tailscale”. Plik README jasno określa zakres: „Implementuje wąski zakres, pojedynczą sieć Tailscale (tailnet), odpowiednią do użytku osobistego lub małej organizacji open-source”. Lista funkcji obejmuje ACL i uprawnienia, routery podsieci, węzły wyjściowe (exit nodes), wbudowany serwer DERP, Tailscale SSH oraz Taildrop. Jeśli ten wąski zakres jest przeszkodą, NetBird stanowi alternatywną sieć mesh oferującą samodzielnie hostowaną płaszczyznę sterowania, a uruchomienie serwera NetBird na własnym VPS przenosi tę samą decyzję o rejestracji na sprzęt, którego jesteś właścicielem.

Zmianie ulega podmiot, który mógłby zarejestrować nieautoryzowany węzeł. W przypadku Headscale katalog kluczy i polityka znajdują się na Twoim serwerze. Żadna strona trzecia nie przechowuje listy kluczy publicznych Twoich urządzeń i żadna strona trzecia nie może zostać zmuszona do ich wydania lub podpisania.

Nie zmienia się płaszczyzna danych. Jest to ten sam protokół WireGuard z tym samym szyfrowaniem end-to-end oraz tym samym mechanizmem przekaźnikowym (relay) w przypadku braku bezpośredniego połączenia. Przejmujesz również zadania, które wcześniej wykonywało Tailscale: zapewnienie dostępności, aktualizacje, kopie zapasowe oraz bezpieczeństwo fizyczne serwera. Przejęcie hosta z Headscale daje atakującemu dokładnie to samo, co przejęcie serwera koordynacji, czyli możliwość rejestracji węzła i dystrybucji polityki. Funkcja Tailnet lock nie znajduje się na liście funkcji Headscale, więc mechanizm kontroli kompensującej dla tego konkretnego ryzyka nie jest tam dostępny. Jeśli kwestia własności jest dla Ciebie decydująca, samodzielne hostowanie płaszczyzny sterowania za pomocą Headscale przeprowadzi Cię przez proces konfiguracji.

Przed czym chroni Tailscale

• Publiczne porty nasłuchujące. Usługa powiązana z adresem w sieci tailnet nie jest osiągalna z Internetu, więc skanery sprawdzające każdy VPS na porcie 22 nigdy jej nie wykryją. Wyjątek stanowi sytuacja, w której użytkownik sam włączy taką opcję, ponieważ Funnel celowo publikuje usługę z sieci tailnet w otwartym Internecie. Dlatego warto wiedzieć, gdzie kończy się serve, a zaczyna funnel, zanim uruchomi się którekolwiek z tych poleceń. Mimo to należy zachować firewalla na hoście, ponieważ opublikowany port Docker tworzy własne reguły i omija ufw na publicznym interfejsie.
• Zgadywanie haseł do wystawionych usług. Nie ma czego atakować metodą brute-force, gdy port odpowiada wyłącznie wewnątrz tunelu. Jest to skuteczniejsze rozwiązanie niż ograniczanie liczby żądań (rate limiting) na otwartym porcie, choć fail2ban na Ubuntu 24.04 nadal warto uruchomić na każdej usłudze, która musi pozostać publiczna.
• Niezaufane sieci na trasie połączenia. Ruch między maszynami jest szyfrowany end-to-end w sieciach kawiarnianych czy współdzielonych sieciach LAN dostawców i pozostaje zaszyfrowany nawet w przypadku przesyłania przez przekaźnik (relay).
• Ręczne zarządzanie dystrybucją kluczy. Każdy peer dodany ręcznie do konfiguracji WireGuard to ryzyko ponownego użycia adresu lub wklejenia błędnego klucza. Sieć typu mesh automatyzuje tę ewidencję, co stanowi najważniejszą praktyczną różnicę w zestawieniu WireGuard a Tailscale.

Przed czym Tailscale nie chroni

• Zainfekowany punkt końcowy. Tailnet ufa urządzeniom. Złośliwe oprogramowanie na autoryzowanym laptopie uzyskuje dostęp do tunelu, adresów wewnątrz tailnet oraz wszystkich zasobów, do których użytkownik posiada uprawnienia. Jest to największa luka, której nie eliminuje żadna sieć VPN.
• Złośliwy lub nieostrożny administrator. Każdy, kto może edytować plik polityki, może przyznać sobie dostęp do dowolnego zasobu. To samo dotyczy osób, które przejmą konto właściciela (Owner). Zmiany w polityce należy weryfikować w taki sam sposób, jak przegląda się kod źródłowy.
• Analiza ruchu. Twój dostawca usług internetowych (ISP) widzi zaszyfrowany ruch UDP kierowany do punktu końcowego, a także czas i wolumen transmisji. Dzienniki przepływu (flow logs) w Tailscale rejestrują, które węzły komunikowały się ze sobą i kiedy. Żadna z tych metod nie pozwala na odczytanie zawartości pakietów, jednak sam fakt nawiązania połączenia nie jest ukryty. Przed wyborem narzędzia do tego celu zapoznaj się z informacjami o tym, czym różni się Tor od VPN.
• Utracone urządzenie. Wygasanie kluczy stanowi zabezpieczenie ostateczne, domyślnie ustawione na 180 dni. Szybszą metodą jest usunięcie urządzenia w konsoli administracyjnej, dlatego warto wiedzieć, gdzie znajduje się ten przycisk, zanim zajdzie taka potrzeba.

Sprawdź własną sieć tailnet

1. Uruchom tailscale status na urządzeniu i odczytaj listę węzłów (peer list). Urządzenie, którego nie potrafisz zidentyfikować, to dokładnie sytuacja, której zapobiega funkcja zatwierdzania urządzeń (device approval).
2. Uruchom tailscale lock status, aby sprawdzić, czy funkcja tailnet lock jest włączona, a następnie oceń, czy koszt podpisywania każdego nowego urządzenia jest uzasadniony w Twojej sieci tailnet.
3. Otwórz konsolę administracyjną i zanotuj każde urządzenie z wyłączonym wygasaniem klucza (key expiry), a także każdy klucz uwierzytelniający wielokrotnego użytku (reusable auth key), który nadal istnieje. Oba te elementy stanowią poświadczenia bez ograniczenia czasowego.
4. Przeczytaj swój plik polityki (policy file). Jeśli nadal używasz ustawień domyślnych, każde urządzenie może połączyć się z każdym innym na dowolnym porcie, co oznacza, że jeden zainfekowany laptop daje dostęp do wszystkich pozostałych.

Tailscale buduje swoją reputację na płaszczyźnie danych (data plane), gdzie konstrukcja systemu uniemożliwia operatorowi odczyt Twojego ruchu. Potraktuj to zapewnienie zgodnie z dokumentacją dostawcy, a następnie przeprowadź audyt elementów, za które odpowiadasz: kont tożsamości, ustawień zatwierdzania, listy wygasania oraz pliku polityki. Strona dotycząca bezpieczeństwa Tailscale informuje o certyfikacji SOC 2 Type II oraz stałej współpracy z Latacora, co stanowi dowód na procesy dostawcy, a nie deklarację dotyczącą Twojej konfiguracji.

FAQ

Czy Tailscale może odczytać mój ruch?

Nie. Ruch jest szyfrowany kluczami WireGuard generowanymi na urządzeniach użytkownika, a strona bezpieczeństwa Tailscale potwierdza, że „klucze prywatne nigdy nie opuszczają urządzenia. Cały ruch jest zawsze szyfrowany metodą end-to-end”. Dotyczy to również połączeń korzystających z przekaźników DERP, ponieważ przekaźnik „ślepo przekazuje już zaszyfrowany ruch między urządzeniami” i nie posiada kluczy umożliwiających jego odszyfrowanie. Infrastruktura Tailscale widzi jedynie metadane: jakie urządzenia istnieją oraz które z nich łączyły się ze sobą i kiedy.

Co faktycznie mógłby zrobić przejęty serwer koordynacyjny Tailscale?

Mógłby zarejestrować nowy węzeł. Dokumentacja tailnet lock opisuje ryzyko potajemnego dodania węzła, który mógłby „wysyłać lub odbierać ruch do istniejących węzłów”, gdzie szyfrowanie nie pomaga, „ponieważ sam partner komunikacji byłby złośliwy”. Przejęty panel sterowania mógłby również rozpowszechnić politykę zmieniającą dostępność zasobów dla urządzeń, a biała księga tailnet lock wskazuje, że mógłby on zakłócić łączność poprzez wstrzymanie dystrybucji nowych kluczy węzłów. Nie mógłby natomiast odszyfrować ruchu między istniejącymi urządzeniami, ponieważ nigdy nie posiadał ich kluczy prywatnych.

Czy exit node ukrywa moją aktywność przeglądania przed dostawcą internetu (ISP)?

Ukrywa on miejsca docelowe przed siecią, w której aktualnie przebywasz, w tym przed domowym dostawcą internetu lub siecią w kawiarni, ponieważ cały ruch opuszcza urządzenie jako zaszyfrowany strumień skierowany do exit node. Nie zapewnia to jednak anonimowości. Exit node widzi te miejsca docelowe, podobnie jak jego dostawca hostingu i sieć nadrzędna, podczas gdy odwiedzane strony widzą adres IP exit node. Wybierasz w ten sposób innego obserwatora, więc należy wskazać podmiot, któremu faktycznie ufasz.

Czy Headscale jest bezpieczniejszy niż serwer koordynacyjny Tailscale?

Jest to inna decyzja dotycząca zaufania, a nie rozwiązanie ściśle bezpieczniejsze. W przypadku Headscale to użytkownik zarządza katalogiem kluczy i politykami, więc żadna zewnętrzna strona nie może zostać zmuszona do zarejestrowania urządzenia w Twoim tailnet. Bierzesz również na siebie utrzymanie serwera: aktualizacje, dostępność, kopie zapasowe oraz bezpieczeństwo samego hosta. Przejęty host Headscale daje atakującemu takie same możliwości rejestracji, jakie miałby w przypadku przejęcia serwera koordynacyjnego, a ponieważ tailnet lock nie znajduje się na liście funkcji Headscale, należy odpowiednio zabezpieczyć ten host.

Czy nadal potrzebuję firewalla na VPS, który znajduje się w moim tailnet?

Tak. Publiczny interfejs sieciowy nadal istnieje, a każda usługa powiązana z 0.0.0.0 pozostaje dostępna z Internetu, niezależnie od tego, czy Tailscale jest uruchomiony. Powiązuj usługi z adresem tailnet, utrzymuj domyślną politykę odmowy (deny) na interfejsie publicznym i weryfikuj opublikowane porty kontenerów, ponieważ Docker automatycznie dodaje własne reguły i może wystawić port, który w założeniu miał być zamknięty.