Logowanie do Tailscale: jakie konto wybrać?

Logowanie do Tailscale: to konto wybiera twoją sieć

Logowanie do Tailscale nie polega na zakładaniu konta z hasłem. Pierwszy ekran po instalacji prosi o zalogowanie się kontem, które już masz u zewnętrznego dostawcy tożsamości (IdP, identity provider): Google, Microsoft, GitHub, Apple, Okta, OneLogin albo dowolnego dostawcy OIDC (OpenID Connect, otwarty standard logowania jednokrotnego). Dokumentacja Tailscale mówi to wprost: „Tailscale itself doesn't provide user identity”. Wybrane konto nie jest więc tylko sposobem wejścia. Ono decyduje, do której sieci trafi twój laptop i twój VPS.

Czym jest tailnet i kiedy on powstaje

Tailnet to twoja sieć w Tailscale: użytkownicy, urządzenia, nazwy DNS i reguły dostępu w jednym miejscu. Strona „Tailnet overview” w dokumentacji Tailscale mówi, że Tailscale tworzy tailnet przy pierwszym logowaniu na dowolnym urządzeniu, czy to na telefonie, komputerze, czy maszynie wirtualnej. Nigdzie nie klikasz „utwórz sieć”. Sieć powstaje sama i zostaje powiązana z tożsamością użytą przy tym logowaniu.

Dlatego zalogowanie się „nie tym kontem” nie kończy się komunikatem o błędzie. Kończy się drugim tailnetem, który wygląda zupełnie poprawnie, tylko nie ma w nim żadnej z twoich pozostałych maszyn. Nic nie jest zepsute, a jednak nic nie działa tak, jak chcesz. Jeśli dopiero zaczynasz, warto najpierw przeczytać, czym jest Tailscale i jak łączy maszyny bez przekierowania portów.

Konto prywatne Google kontra firmowe Google Workspace

W małych polskich firmach w obiegu są zwykle dwa rodzaje kont Google: prywatne @gmail.com i firmowe w Google Workspace na własnej domenie, na przykład @twojafirma.pl. Microsoft 365 działa tak samo: konto prywatne kontra konto w domenie organizacji. Na ekranie logowania w obu przypadkach widzisz ten sam przycisk „Sign in with Google”, więc łatwo uznać, że to bez znaczenia. Znaczenie ma adres, który wraca od dostawcy, bo z niego bierze się domena tailnetu. Prywatne konto Gmail i firmowe konto w domenie to dwie różne tożsamości, więc dają dwa różne tailnety.

Skutki widać już przy rejestracji. Dokumentacja „Tailscale quickstart” mówi (stan na wrzesień 2026), że rejestracja adresem z domeny publicznej, takiej jak @gmail.com, oznacza automatyczne przypisanie do planu Personal z sześcioma darmowymi użytkownikami, a rejestracja adresem we własnej domenie uruchamia 14-dniowy okres próbny planu Enterprise. Progi i ceny zmieniają się częściej niż sama mechanika logowania, więc traktuj je jako stan na dziś: co dokładnie obejmuje darmowy plan oraz ile realnie płaci kilkuosobowy zespół rozbieramy osobno.

Kto dołączy do twojego tailnetu, a kogo musisz zaprosić

Tu leży praktyczna różnica między domeną firmową a adresem prywatnym. Dokumentacja „Invite team members to your tailnet” wymaga, by tailnet używał własnej domeny (custom domain), i dodaje ograniczenie: „You can only invite users in the same domain”. Dla tailnetu na domenie współdzielonej, czyli takiej jak gmail.com, ta sama strona wskazuje inną drogę: zaproszenie przez link. Osobna strona „Invite any user to your tailnet” opisuje je jako jednorazowe zaproszenie w postaci wygenerowanego adresu URL.

Wniosek dla firmy jest prosty. Jeżeli wszyscy logują się kontami w domenie firmy, macie jedną sieć i jedną listę użytkowników, a nowa osoba dołącza swoim służbowym adresem. Jeżeli każdy loguje się prywatnym Gmailem, macie tyle sieci, ile osób, i łączenie ich odbywa się przez zaproszenia wysyłane ręcznie. Dokumentacja opisuje też zatwierdzanie nowych użytkowników („User approval”), czyli kontrolę administratora nad tym, kto faktycznie wchodzi do sieci.

Urządzenie należy do tailnetu, nie do ciebie

Węzeł (node) jest członkiem konkretnego tailnetu. Po zalogowaniu klient ma klucz węzła wystawiony dla tej jednej sieci, adres z jej zakresu i nazwę w jej MagicDNS. Przełączenie konta na maszynie nie przenosi jej więc do innej sieci razem z konfiguracją. Ono rejestruje tam nowe urządzenie. Stary wpis zostaje w starym tailnecie do momentu, w którym ktoś usunie go w panelu administracyjnym.

Najlepiej widać to na serwerze. VPS zalogowany prywatnym kontem jest niewidoczny dla reszty zespołu, choć demon działa, tailscale status pokazuje połączenie, a w panelu maszyna wygląda zdrowo. To częsta przyczyna zgłoszeń w stylu „Tailscale działa, ale nie widzę serwera”, i warto sprawdzić ją przed błędami samej instalacji klienta na Ubuntu, bo nie wymaga ona żadnej naprawy, tylko poprawnego konta.

Jak sprawdzić, w jakim tailnecie i na jakim koncie jesteś

Dwa miejsca warto sprawdzić, zanim zaczniesz szukać winy w regułach dostępu. Na maszynie: tailscale status pokazuje stan połączeń z innymi urządzeniami sieci, a polecenie tailscale switch z flagą --list służy do wypisania kont dostępnych lokalnie (dokumentacja CLI opisuje tę flagę jako „Lists available accounts”). W panelu administracyjnym: nazwa DNS tailnetu znajduje się na stronie DNS, co potwierdza strona „Tailnet overview”.

tailscale status
tailscale switch --list

Jeśli nazwa sieci albo adres użytkownika w panelu nie zgadza się z tym, czego oczekujesz, dalsze czytanie reguł ACL nie ma sensu, bo patrzysz na inną sieć niż ta, w której jest twoja maszyna.

Jak przełączać konta na jednej maszynie

Tailscale nazywa tę funkcję fast user switching. Kolejne konto dodajesz przez tailscale login, przełączasz się przez tailscale switch <konto>, a krótką nazwę bieżącego konta ustawia tailscale set --nickname=work, dzięki czemu później wystarczy tailscale switch work. Te polecenia uruchamiasz na własnym komputerze lub serwerze, bo logowanie wymaga wyjścia do internetu i otwarcia strony dostawcy tożsamości w przeglądarce.

tailscale login
tailscale set --nickname=work
tailscale switch --list
tailscale switch work

Dokumentacja „Fast user switching” stawia dwa ograniczenia, o których trzeba wiedzieć z góry. Po pierwsze: „A device is not able to transmit packets on multiple tailnets simultaneously”, a jedna sieć nie wie nic o istnieniu drugiej, więc to naprawdę jest przełączanie, a nie praca w dwóch sieciach naraz. Po drugie: ponowne uwierzytelnienie jest potrzebne wtedy, gdy dane konto nigdy nie było używane na tym urządzeniu albo gdy klucz węzła dla tej sieci wygasł. Polecenie tailscale logout rozłącza i wygasza bieżące logowanie.

Co trzeba zrobić ponownie na każdym węźle po zmianie sieci

Konfiguracja nie jest własnością maszyny. Jest własnością tailnetu, więc po przejściu na inne konto powtarzasz ją od zera w nowym panelu:

• ponowne zalogowanie węzła i zatwierdzenie samego urządzenia w nowej sieci,
• ponowne rozgłoszenie tras i ich zatwierdzenie, jeśli maszyna pracowała jako subnet router udostępniający prywatne podsieci,
• ponowne włączenie i zatwierdzenie węzła wyjściowego, jeśli VPS służył jako exit node dla całego ruchu klientów,
• reguły ACL, tagi urządzeń i klucze autoryzacyjne, bo plik polityki dostępu należy do sieci, a nie do maszyny,
• nazwy MagicDNS, które zmieniają się razem z nazwą DNS tailnetu, więc każdy skrypt i każdy wpis konfiguracji wskazujący starą nazwę przestaje działać.

Na serwerach bez przeglądarki wygodniej jest zarejestrować maszynę kluczem autoryzacyjnym wygenerowanym w nowym panelu niż przechodzić logowanie interaktywne z linkiem kopiowanym z konsoli.

Czy można scalić dwa tailnety albo zmienić dostawcę tożsamości

W tym miejscu trzymam się wyłącznie tego, co dokumentacja Tailscale mówi dziś, bo to obszar, który się zmienia, a zła rada kosztuje tu cały wieczór pracy.

Scalanie sieci: dokumentacja nie opisuje operacji połączenia dwóch istniejących tailnetów w jeden. Strona „Manage multiple tailnets” opisuje coś innego, czyli wiele sieci w ramach jednej organizacji, i stawia warunek: „All additional tailnets must use the same domain and identity provider as your existing tailnet”. Funkcja jest w wersji alpha, a zakładanie kolejnych sieci nie jest samoobsługowe, bo wymaga kontaktu z opiekunem handlowym. Jako sposób na dostęp pomiędzy sieciami dokumentacja wskazuje udostępnianie pojedynczych maszyn (sharing) oraz declarative node sharing. Jeśli potrzebujesz naprawdę jednej sieci, zapytaj wsparcie Tailscale, zamiast zakładać, że taką operację da się wykonać z panelu.

Zmiana dostawcy tożsamości: strona „Switch identity provider” opisuje taką zmianę dla istniejącego tailnetu i wymaga roli Owner. Wymienia Google Workspace, Microsoft z Entra ID, Okta, OneLogin oraz OIDC, a pozostałe przypadki odsyła do wsparcia. Są tam też dwa ograniczenia ważne dla małej firmy: „You cannot change the tailnet's primary domain name while changing the IdP unless you contact Tailscale Support” oraz „If you are using a shared domain tailnet, such as those created with a Gmail addresses, you cannot switch your IdP unless you contact Tailscale Support”. Strona z listą dostawców dodaje, że migracja z GitHuba i z Apple, a także do nich, nie jest możliwa. Funkcja była opisana jako beta w chwili ostatniej weryfikacji tej strony przez Tailscale (czerwiec 2026), więc sprawdź ją u źródła przed zaplanowaniem migracji.

Praktyczny wniosek jest niewygodny: tailnet założony na prywatnym Gmailu jest najtrudniejszy do przeniesienia, bo obie te blokady dotyczą właśnie jego.

Dwie decyzje przed zaproszeniem zespołu

Pierwsza decyzja: jeden dostawca tożsamości dla całego zespołu, wybrany przed pierwszym logowaniem na produkcyjnym serwerze. Jeśli firma ma Google Workspace albo Microsoft 365 na własnej domenie, to właśnie on, a nie konta prywatne. Wtedy nowa osoba dołącza swoim służbowym adresem, a odejście z firmy odcina dostęp do sieci w tym samym miejscu, w którym i tak wyłączasz konta, czyli u dostawcy tożsamości. Konta prywatne oznaczają, że dostęp do sieci firmowej wisi na skrzynce, której nie kontrolujesz.

Druga decyzja: co robisz, gdy stracisz dostęp do tego dostawcy. Zablokowane konto Google albo wygaszona subskrypcja Microsoft 365 to jednocześnie utrata drogi logowania do panelu twojej sieci, a urządzenia działają dalej tylko do wygaśnięcia kluczy węzłów. Minimum to drugi użytkownik z rolą Owner w tym samym tailnecie. Jeśli sama zależność od zewnętrznego dostawcy jest dla ciebie nie do przyjęcia, wyjściem awaryjnym jest własny serwer kontrolny: Headscale, czyli otwarta implementacja serwera kontrolnego dla klientów Tailscale, do którego klient podłącza się flagą --login-server.

tailscale login --login-server=https://headscale.twojafirma.pl

Wtedy uwierzytelnianie, kopie zapasowe i czas działania tego serwera są twoje, i to jest realna cena tej niezależności. Zanim ją zapłacisz, warto wiedzieć, co serwer kontrolny Tailscale widzi, a czego nie widzi nigdy, bo od tego zależy, czy przenosisz do siebie bezpieczeństwo, czy tylko obowiązki.

FAQ

Dlaczego po zalogowaniu nie widzę swojego serwera w Tailscale?

Najczęściej dlatego, że serwer i laptop są w dwóch różnych tailnetach. Tailnet powstaje przy pierwszym logowaniu i zostaje powiązany z użytą tożsamością, więc logowanie prywatnym Gmailem na jednej maszynie i firmowym adresem na drugiej daje dwie osobne, w pełni sprawne sieci. Sprawdź nazwę DNS tailnetu w panelu administracyjnym oraz konta dostępne lokalnie przez tailscale switch --list, zamiast zaczynać od reguł ACL.

Czy mogę zmienić konto, którym loguję się do Tailscale?

Na poziomie urządzenia tak: kolejne konto dodaje tailscale login, a przełącza tailscale switch. Dokumentacja „Fast user switching” zaznacza, że urządzenie nie przesyła pakietów w wielu tailnetach jednocześnie, więc to przełączanie, nie praca w dwóch sieciach równolegle. Zmiana dostawcy tożsamości dla całego istniejącego tailnetu jest inną operacją, opisaną na stronie „Switch identity provider”: wymaga roli Owner i ma wyjątki, w których trzeba napisać do wsparcia Tailscale.

Czy da się połączyć dwa tailnety w jeden?

Dokumentacja Tailscale nie opisuje takiej operacji. Opisuje wiele tailnetów w jednej organizacji, ze wspólną domeną i wspólnym dostawcą tożsamości, w wersji alpha i przy udziale opiekuna handlowego, oraz udostępnianie pojedynczych maszyn między sieciami. Jeśli potrzebujesz jednej sieci, najpewniejsza droga to wybrać tailnet docelowy, zaprosić do niego użytkowników i zalogować węzły ponownie. Pytanie o faktyczne scalenie skieruj do wsparcia Tailscale.

Co się stanie z moją siecią, jeśli stracę konto Google lub Microsoft?

Tracisz drogę logowania, a razem z nią dostęp administracyjny do tailnetu, choć same urządzenia zostają połączone do wygaśnięcia kluczy węzłów. Dlatego warto mieć w tailnecie drugiego użytkownika z rolą Owner, na innym koncie niż twoje główne. Jeśli chcesz nie zależeć od zewnętrznego dostawcy w ogóle, alternatywą jest własny serwer kontrolny, do którego klient łączy się flagą --login-server.

Czy prywatne konto Gmail wystarczy dla małej firmy?

Działa, ale utrudnia dwie rzeczy. Zaproszenia zespołu w domenie firmowej wymagają własnej domeny, a tailnet na domenie współdzielonej korzysta z zaproszeń przez link. Do tego dokumentacja „Switch identity provider” mówi, że tailnet na domenie współdzielonej, na przykład utworzony adresem Gmail, nie może samodzielnie zmienić dostawcy tożsamości bez kontaktu ze wsparciem. Jeśli firma ma już Google Workspace lub Microsoft 365 na swojej domenie, zacznij od tego konta.