Płaszczyzna sterowania dla prywatnej sieci mesh.

Zrozum, co jest koordynowane

Płaszczyzna sterowania zarządza rejestracją węzłów i rozpowszechnia informacje o sieci. Ruch danych może korzystać z bezpośrednich połączeń równorzędnych lub przekaźnika w zależności od łączności. Uruchomienie koordynatora nie oznacza, że każdy pakiet przez niego przechodzi.

Rejestracja powinna być świadoma

Chroń administracyjny API i stosuj krótkotrwałe lub odpowiednio ograniczone metody rejestracji. Usuwaj urządzenia, które zostały zgubione lub wycofane z użycia. Możliwość dołączenia do sieci mesh nie powinna oznaczać dostępu do każdej usługi.

Przejrzyj listy ACL i trasy

Stosuj reguły najmniejszych uprawnień między użytkownikami a węzłami. Ogłaszane trasy podsieci i węzły wyjściowe rozszerzają osiągalną sieć i wymagają wyraźnej zgody. Testuj ruch odrzucany równie starannie jak ruch dozwolony.

Zachowaj materiały do odzyskiwania

Twórz kopie zapasowe konfiguracji, stanu i kluczy zgodnie z procedurą obsługiwanej wersji. Zapewnij sposób administrowania VPS, jeśli mesh zawiedzie. Zweryfikuj zgodność klientów i informacje o aktualizacji przed zmianą płaszczyzny sterowania.

Rejestracja, routing i polityka to osobne kontrole

Headscale koordynuje kompatybilne klienty Tailscale; połączenia bezpośrednie i ścieżki przekaźnika DERP mają odmienne zachowanie sieciowe. Router podsieci ogłasza zakres, serwer sterowania go zatwierdza, a klient musi zaakceptować trasę. Włącz przekazywanie na węźle routingu i utrzymuj ogłaszane zakresy wąskie. Zatwierdzona trasa nadal wymaga polityki dostępu ograniczającej, kto może używać którego celu i portu.

• Sprawdź listę tras serwera sterującego
• Testuj z dozwolonego urządzenia
• Powtórz ten sam test z urządzenia, które powinno zostać odrzucone

headscale nodes list-routes

Oficjalna dokumentacja: Trasy Headscale

Nie umieszczaj jedynej ścieżki odzyskiwania wewnątrz mesh

Zachowaj drugi sposób dostępu do konsoli serwera lub ściśle ograniczoną trasę administratora. Przetestuj, co się dzieje, gdy koordynator, przekaźnik lub klient są niedostępne. Zachowaj stan płaszczyzny sterowania i klucze zgodnie z zainstalowaną wersją. Prywatna sieć mesh może uprościć dostęp, ale nie powinna stać się nieudokumentowaną zależnością, która uniemożliwia własną naprawę.

Ustal tożsamość płaszczyzny sterowania i ścieżkę odzyskiwania

Wybierz stabilną nazwę HTTPS, obsługiwane wydanie Headscale i kompatybilnych klientów Tailscale. Przeczytaj przykład konfiguracji dostarczony z tym konkretnym wydaniem; konfiguracja skopiowana z innego wydania może nie przejść walidacji lub po cichu opisywać inną politykę. Utrwal bazę danych płaszczyzny sterowania i wymagane klucze. Utrzymuj administracyjny API jako prywatny i zachowaj osobną konsolę lub ograniczoną trasę SSH, aby utrata meshu nie uniemożliwiła naprawy jego koordynatora.

• Użyj certyfikatu ważnego dla publicznej nazwy płaszczyzny sterowania.
• Klucze rejestracji powinny mieć krótki czas życia i odpowiednio ograniczony zakres.
• Traktuj projekt przekaźnika i przestrzeń nazw DNS jako świadome wybory.

Oficjalna dokumentacja: Wdrożenie kontenera Headscale

Zarejestruj jedno urządzenie przed rozgłaszaniem sieci

Uruchom serwer zgodnie z instrukcjami upstream i zarejestruj jednego użytkownika testowego/urządzenie testowe za pomocą udokumentowanej metody rejestracji. Potwierdź, że urządzenie dociera do oczekiwanej płaszczyzny sterowania URL i pojawia się pod zamierzoną tożsamością. Sprawdź status klienta i przetestuj jedną usługę prywatną przed dodaniem tras exit-node lub podsieci. Ścieżka DERP może zachować łączność tam, gdzie ścieżka bezpośrednia jest niedostępna; nie oznacza to, że koordynator przekazuje każdy pakiet.

• Zacznij od urządzenia i usługi, które możesz bezpiecznie usunąć.
• Sprawdź, czy ruch partnerski jest bezpośredni, czy przekazywany.
• Chroń przekaźnik i punkty końcowe sterowania zgodnie z wybranym wdrożeniem.

Oficjalna dokumentacja: Dokumentacja wdrożenia Headscale

Zatwierdzaj routing i autoryzację niezależnie

Aby uzyskać dostęp do podsieci, włącz przekazywanie na węźle routingu, ogłoś wąski zakres, zatwierdź go na serwerze sterowania i upewnij się, że docelowy klient go akceptuje. Unikaj nakładających się sieci, które czynią trasę powrotną niejednoznaczną. Zatwierdzona trasa nie jest polityką dostępu: zdefiniuj, kto może łączyć się z którym celem i portem, w tym urządzenia gości. Przetestuj dozwolone połączenie i identyczne połączenie odmówione, zanim rozszerzysz mesh.

# Run on the control server; syntax follows the installed release:
headscale nodes list-routes
# Client-side inspection:
tailscale status

Oficjalna dokumentacja: Podsieci i trasy wyjściowe Headscale

Znajdź uszkodzoną warstwę, zanim zmienisz politykę

Jeśli rejestracja się nie powiedzie, sprawdź DNS, HTTPS i serwer URL. Jeśli urządzenie dołącza, ale podsieć jest nieosiągalna, sprawdź ogłaszanie, zatwierdzenie, akceptację tras przez klienta, przekazywanie i ścieżkę powrotną. Jeśli zawodzi tylko jedna usługa, sprawdź jej adres nasłuchu, zaporę hosta i politykę mesh. Zachowaj spójną kopię zapasową bazy danych/konfiguracji i przetestuj aktualizację wersji z jednorazowym klientem, zanim zmienisz jedyną płaszczyznę sterowania.