Tylko jeden klient zarządzania: dlaczego monitor wyrzuca interfejs graficzny

Graficzny interfejs pulpitu trzyma połączenie zarządzania, więc skrypt monitorujący, który próbuje otworzyć własne, nic nie odczytuje albo, co gorsza, interfejs przestaje odpowiadać na monity. Zwykły wniosek jest taki, że demon jest niestabilny. W demonie społecznościowym ograniczenie jest zamierzone: interfejs sterowania obsługuje jednego podłączonego klienta zarządzania naraz, a ta liczba nie ma nic wspólnego z tym, ilu użytkowników sieć VPN może obsłużyć.

Jedno gniazdo, jeden posiadacz

Kanał zarządzania akceptuje jednego podłączonego klienta. Gdy drugi przybywa, podczas gdy pierwszy jest aktywny, czeka albo zostaje odrzucony, i nie ma żadnego równoległego trybu subskrybenta ukrytego za opcją. Odłączenie bieżącego posiadacza pozwala demonowi przyjąć następnego, co jest przekazaniem, a nie drugim kanałem.

To czyni każde dodatkowe narzędzie konkurentem. Jeśli interfejs posiada połączenie, skrypt odpytujący albo nie zdoła się podłączyć, albo udaje mu się to dopiero po tym, jak interfejs się podda, a sekwencja powtarza się przy następnym ponownym połączeniu. Jeśli skrypt podłączy się pierwszy, interfejs traci swoją ścieżkę sterowania i jego monity przestają działać. Żadne z narzędzi nie zgłasza konfliktu, bo każde widzi tylko własne nieudane polecenie.

Zdecyduj, który komponent posiada kontrolę

Wybierz jednego posiadacza kanału interaktywnego i pozwól, by był jedyną rzeczą, która się łączy. Interfejs zarządzający połączeniem, skrypt odpowiadający na monity uwierzytelniania i kontroler kończący sesje wszyscy liczą się jako posiadacze, a rolę może pełnić tylko jeden.

Gdy interfejs posiada połączenie, używaj integracji, którą oferuje, zamiast z nim walczyć. Wyścig z posiadaczem o gniazdo daje przerywane awarie, które użytkownikom wydają się losowe, a osoba debugująca widzi zwykle tylko drugą połowę wyścigu. Zanotuj, który proces łączy się pierwszy po restarcie, bo ta kolejność za każdym razem decyduje o zwycięzcy. Monitor uruchomiony przed interfejsem utrzyma kanał, dopóki interfejs się nie podda.

Używaj migawek stanu dla kolektorów

Większość monitoringu potrzebuje listy, a nie rozmowy. Okresowy plik stanu odpowiada na to bez dotykania kanału sterowania i działa dalej, gdy interfejs pozostaje podłączony.

status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix

Interwał to budżet świeżości, więc ustaw go na to, czego pulpit naprawdę potrzebuje, a nie na najmniejszą wartość, która wydaje się bezpieczna. Migawka zapisywana co kilka sekund jest tania; skrypt, który co kilka sekund łączy się ponownie z gniazdem sterowania, nie jest, bo każde ponowne połączenie konkuruje z posiadaczem.

Migawka to nie historia i nie strumień zdarzeń. Połączenia, które przychodzą i odchodzą w obrębie jednego interwału, nigdy się nie pojawiają, więc wymogu audytowego nie da się spełnić, odpytując plik, który nadpisuje sam siebie. Jeśli musisz wiedzieć, czy użytkownik w ogóle się połączył, migawka jest niewłaściwym narzędziem.

Rozprowadzanie to projekt, a nie tryb

Jeśli kilku odbiorców naprawdę potrzebuje danych zarządzania na żywo, postaw jeden zaufany komponent przed gniazdem i pozwól mu publikować wąsko wybrane obserwacje dla pozostałych. Ten komponent posiada ponowne łączenie, monity uwierzytelniania i decyzję o tym, co jest bezpieczne do ujawnienia.

Zbuduj go świadomie: zdefiniuj, które zapytania są dozwolone, rejestruj, kto pytał, i nie dopuść, by warstwa rozprowadzania przypadkiem stała się panelem zdalnego sterowania. Demon nie ma trybu wieloklientowego do włączenia i żadna linia konfiguracji go nie tworzy. Traktuj posiadacza jako część granicy bezpieczeństwa, bo trzyma interfejs, który potrafi odłączyć ludzi. Jego restart powinien być rutynową operacją z udokumentowaną ścieżką odzyskiwania.

Traktuj gniazdo jak przywilej, nie jak metryki

Interfejs zarządzania może odłączać użytkowników, zmieniać stan i czytać zdarzenia, w których wymieniani są ludzie. Jego hasło uwierzytelnia klienta i nie szyfruje transportu, więc nasłuch sieciowy ujawnia rozmowę każdemu, kto może ją obserwować.

Preferuj lokalne gniazdo lub ściśle ograniczony nasłuch i sprawdź, do którego procesu twój kolektor faktycznie się zwraca, bo produkty serwerowe dostarczają własne API zarządzania, które zachowują się inaczej. Kolektor wskazujący na zły demon daje pewne i błędne wnioski. Potwierdź ścieżkę i proces właściciela, zanim zaczniesz debugować zapytanie, które nic nie zwraca.