Zapytaj interfejs zarządzania o stan raz, a zaczyna on wyglądać jak port stanu. Ale nim nie jest. Gdy klient zostanie dopuszczony, może wydawać polecenia sterujące protokołu, a konto uruchamiające tego klienta dziedziczy wszystko, co te polecenia mogą zrobić z demonem. Traktowanie go jako strumienia tylko do odczytu to błąd, który zamienia integrację monitoringu w konsolę bez uwierzytelniania.

Przekonanie i ile kosztuje

Przekonanie jest takie, że nasłuch zarządzania odpowiada punktowi końcowemu metryk: podłącz kolektor, odczytaj liczniki, idź dalej. W rzeczywistości kolektor otwiera sesję z uprawnieniami sterującymi, a każde inne założenie o wdrożeniu zależy teraz od tego, czy ten kolektor zachowuje się dobrze.

Nic w interfejsie nie reklamuje trybu tylko do odczytu. Nie ma roli obserwatora do wyboru, a nazwa użytkownika w konfiguracji jej nie tworzy.

Co dopuszczony klient naprawdę ma

Demon społeczności przyjmuje tylko jednego aktywnego klienta zarządzania naraz. Ten jeden slot oznacza, że GUI, skrypt i agent monitoringu nie mogą podłączyć się wszystkie; drugi czeka lub zawodzi, gdy pierwszy trzyma sesję. Jeśli twój projekt zakłada równoczesnych czytelników, jest już błędny.

Gdzie wystarcza okresowa migawka, dane wyjściowe pliku stanu dają te same liczby bez aktywnej sesji. Zapisywanie tego pliku w odstępach i odczytywanie go zwykłymi uprawnieniami plikowymi trzyma kolektor całkowicie poza płaszczyzną sterowania, i to jest układ, którego większość monitoringu naprawdę potrzebuje.

Własne gniazdo, a nie otwarte

Gniazdo domeny Unix trzyma ścieżkę sterowania poza siecią, co usuwa z problemu zmieniający się adres tunelu. Nie usuwa to kwestii uprawnień. Katalog nadrzędny musi być zapisywalny dla konta usługi i osiągalny dla konta kontrolera, a to dwa oddzielne uprawnienia:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

Plik hasła zawiera sekret zarządzania w pierwszej linii. Chroń ten plik jak każde inne dane uwierzytelniające i trzymaj jego zawartość z dala od logów i zgłoszeń do pomocy technicznej. Ograniczenia użytkownika i grupy to sprawdzenia drugiej strony na gnieździe Unix, a nie uprawnienia systemu plików, więc docelowy proces potrzebuje zarówno dostępu do pliku, jak i pasującej tożsamości.

Udostępnienie gniazda całemu światu, aby usunąć błąd uprawnień, to jedyna poprawka, której należy unikać. Zamienia lokalny kanał sterowania w coś, czym może sterować dowolny proces na hoście.

Publikowanie przez TCP to nie ten sam projekt

Przeniesienie nasłuchu na port TCP nie czyni go bezpieczniejszym ani wygodniejszym. Hasło zarządzania jest wysyłane jawnym tekstem, więc nasłuch TCP ujawnia zarówno dane uwierzytelniające, jak i sesję każdemu, kto może obserwować ścieżkę. Dostęp z innego hosta wymaga autoryzowanego kanału administracyjnego albo małego lokalnego agenta, który udostępnia tylko potrzebne obserwacje.

Hasło na transporcie jawnym jest uwierzytelnianiem bez poufności, a ta kombinacja jest gorsza, niż wygląda, bo sprawia wrażenie chronionej.

Zależności startowe, o które nie prosiłeś

Kilka opcji zarządzania zmienia cykl życia demona. Wstrzymywanie uruchomienia do połączenia kontrolera albo kończenie pracy, gdy kontroler znika, zamienia opcjonalnego obserwatora w twardą zależność. Awaria agenta monitoringu pociągnęłaby wtedy za sobą tunel.

Przejrzyj te opcje, zanim włączysz cokolwiek poza samym gniazdem. Opcjonalna obserwacja powinna pozostać opcjonalna, a polityka restartu nie powinna być sprzężona z kolektorem dodanym dla wykresów.

Plik gniazda pozostawiony po nieudanym procesie nie jest dowodem, że nasłuch istnieje. Ustal, która instancja posiada ścieżkę, zanim ją usuniesz, i użyj własnego przepływu odzyskiwania usługi zamiast usuwać pliki pod działającym demonem.

Jak wygląda akceptacja

Cztery kontrole pokrywają projekt: zamierzona tożsamość kontrolera łączy się, proces bez tej tożsamości jest odrzucany, demon przeżywa kontrolera, który rozłącza się bez ostrzeżenia, a tunel nadal przenosi ruch po kontrolowanym restarcie. Udane połączenie zarządzania dowodzi tylko płaszczyzny sterowania. Nie mówi nic o tym, czy działa ruch aplikacji prywatnych, więc przetestuj to osobno. Zapisz cztery wyniki tam, gdzie znajdzie je następny operator.

Dokumentacja interfejsu zarządzania opisuje model jednego klienta i uprzywilejowany charakter protokołu, i to jest część, którą warto przeczytać, zanim skierujesz na niego pulpit.

Powiązane artykuły