Plik stanu liczy sesje, a nie LAN za nimi

Ktoś pyta, ile maszyn jest w VPN, a plik stanu jest przedstawiany jako dowód. Odpowiada on na węższe pytanie: ile sesji istnieje w tym zrzucie i które adresy wirtualne routuje serwer. Właśnie w luce między tymi pytaniami mieszka większość błędów raportowania, a jej zamknięcie zaczyna się od czytania nagłówków samego pliku.

Co naprawdę zawiera zrzut

Plik jest zapisywany w interwale, gdy dla tej instancji serwera skonfigurowano wyjście stanu, więc jest to obraz okresowy, a nie strumień na żywo. Jego sekcje oddzielnie wymieniają sesje i wewnętrzny stan routingu, a wersja formatu decyduje o układzie kolumn.

status /run/openvpn/office.status 30
status-version 3

Wersja 3 zapisuje pola rozdzielone tabulatorami z wierszem nagłówka, starsze formaty się różnią, a późniejsze wersje mogą dodawać pola. Czytaj nagłówek zamiast zakodować numer kolumny, bo skrypt zakładający pozycje cicho psuje się przy następnej aktualizacji.

Licz sesje, nie ludzi ani maszyny

Jedno połączenie lokacji może nieść ruch kilku autoryzowanych maszyn za sobą. Jedna osoba może też mieć więcej niż jedną sesję naraz, z laptopa i telefonu. Żaden z tych wzorców nie jest widoczny w liczbie, dlatego połączeni użytkownicy mają sens dopiero po zdefiniowaniu jednostki. Zapytaj, jakiej jednostki potrzebuje raport, zanim ktokolwiek zacznie liczyć.

Jeśli liczba ma znaczenie dla licencjonowania lub pojemności, zdefiniuj jednostkę w tym samym dokumencie co raport. Raport, który nie mówi, czy liczy sesje, tożsamości czy urządzenia, zostanie odczytany jako jednostka, której oczekiwał czytelnik.

Adres zewnętrzny nie jest identyfikatorem

Pole rzeczywistego adresu to adres i port peera, tak jak widzi je serwer. Kilku klientów za jednym przetłumaczonym adresem publicznym dzieli ten adres, więc grupowanie według niego łączy niepowiązane sesje. Port też zmienia się między połączeniami, co czyni parę bezużyteczną jako stabilny klucz. Raport pogrupowany w ten sposób wygląda precyzyjnie i jest błędny.

Do grupowania używaj efektywnej tożsamości klienta, a adres traktuj jako szczegół transportu. Gdy dwa wiersze dzielą tożsamość, zwykle oznacza to równoczesne sesje, a nie zduplikowany rekord.

Wiersze routingu nie są inwentarzem hostów

Wpis routingu może nazwać podsieć, za którą odpowiada jeden peer, a podsieć nie jest listą jej hostów. Serwer wie, że powinien wysyłać ten zakres do konkretnej sesji, i nie ma pojęcia, które z tych maszyn są włączone, uwierzytelnione w aplikacji lub komukolwiek przydatne. Tabela routingu opisuje osiągalność, a nie zajętość. Ta różnica jest całym powodem, dla którego VPN nie może odpowiedzieć na pytanie inwentarzowe.

Kilka wierszy może też wskazywać ten sam peer, ponieważ lokacja może ogłaszać więcej niż jeden zakres. Liczenie wierszy i nazywanie wyniku liczbą urządzeń zawyża wdrożenie o dowolny współczynnik.

Jeśli wymaganie jest naprawdę inwentarzem zasobów, użyj procesu inwentaryzacji, który jest właścicielem tej sieci. VPN może ustalić, który peer niesie trasę, i to jest inny fakt niż to, które hosty istnieją za nim.

Wiek, uprawnienia i podgląd na żywo

Zachowuj czas modyfikacji pliku przy każdej odpowiedzi. Serwer, który zatrzymał się godzin temu, zostawia swój ostatni zrzut, a nieaktualny plik przedstawiony jako bieżący jest gorszy niż brak raportu.

Katalog musi istnieć i być zapisywalny dla konta, pod którym usługa faktycznie działa, o czym łatwo zapomnieć po rundzie utwardzania. Plik zwykle zawiera nazwy i adresy, więc trzymaj go w miejscu administracyjnym, a nie gdziekolwiek, skąd serwer WWW może go podać. Sprawdzaj uprawnienia z konta usługi, a nie ze swojej powłoki. Zrzut, który po cichu przestaje się aktualizować, wygląda dokładnie jak spokojna sieć.

Do potrzeb opartych na zdarzeniach używaj obsługiwanego interfejsu zarządzania zamiast szybszego odpytywania. Traktuj ten interfejs jako sterowanie, a nie metryki, i nigdy nie wystawiaj go do internetu tylko po to, by liczyć sesje.