Do kogo należą logi OpenVPN: do demona, rsyslog czy logrotate?

Rotacja logów psuje się w przewidywalny sposób: trzy komponenty każde uważa, że posiada plik, a wynikiem jest obrócony log, który dalej rośnie, podczas gdy nowy pozostaje pusty. Demon trzyma deskryptor, logrotate zmienia nazwę ścieżki, a rsyslog pisze zupełnie gdzie indziej. Wybierz jednego pisarza i jeden rotator, zanim dołożysz kolejną regułę do stosu. Poniższa lista kontrolna idzie w tej kolejności, bo każdy późniejszy krok od niej zależy.

Zdecyduj, kto zapisuje plik

Dwa projekty są uprawnione. W pierwszym proces VPN sam zapisuje plik przez własną opcję log lub log-append. W drugim wysyła rekordy do systemowego loggera, a rsyslog albo journald decyduje, gdzie wylądują.

To alternatywy, nie warstwy. Host, który włączy oba, kończy z dwoma plikami, które się nie zgadzają, a ten, który czytasz, często jest przestarzały. Wybierz ścieżkę świadomie, a potem usuń drugiego pisarza.

Przeczytaj obowiązującą konfigurację usługi, zanim cokolwiek zmienisz, w tym pliki drop-in, które mogą nadpisać plik unit. Dyrektywa obecna w profilu, który edytowałeś, nie jest dowodem, że to ta, którą załadował działający proces. Porównaj unit z argumentami procesu, a potem z plikami, które naprawdę otworzył.

Nazwij demona, aby filtr mógł być wąski

Na ścieżce syslog daj demonowi odrębną tożsamość i filtruj po niej. Reguła pasująca do nazwy programu tej instancji VPN trzyma jej rekordy poza wspólnym plikiem, którego polityka przechowywania należy do czegoś innego.

Wąskie reguły czynią też odpowiadalnym następne pytanie: która usługa wytworzyła tę linię? Filtr pasujący do wszystkiego, co zawiera słowo VPN, chętnie zbierze ruch drugiego tunelu i rozmyje oba. Dopasuj dokładny identyfikator, który unit przekazuje loggerowi.

Zamknij regułę po akcji, aby rekordy nie wpadały także do domyślnego miejsca docelowego. Zduplikowane linie w dwóch plikach wyglądają jak błąd logowania, a naprawdę są brakującym zatrzymaniem. To jedno przeoczenie podwaja też koszt dyskowy polityki przechowywania.

Rotuj bez utraty deskryptora

Gdy demon zapisuje plik, logrotate zmienia nazwę ścieżki, ale proces zachowuje swój otwarty deskryptor. Nowe rekordy trafiają nadal do przemianowanego pliku, dopóki coś nie zmusi procesu do ponownego otwarcia pierwotnej ścieżki; dlatego rotacja może wyglądać na działającą, podczas gdy nowy plik pozostaje pusty.

Rozwiązaniem jest akcja postrotate, która uruchamia udokumentowane zachowanie przeładowania lub restartu usługi. Wysłanie sygnału do loggera to zupełnie inna akcja i nic nie robi dla demona trzymającego własny plik.

Tam, gdzie ponowne otwarcie jest niemożliwe, copytruncate jest wariantem zapasowym: skopiuj plik, a potem utnij go w miejscu. Zachowuje ważny deskryptor kosztem utraty wszystkiego, co zapisano między kopią a ucięciem, więc jest to wymiana, a nie rozwiązanie. Pod obciążeniem ta luka może pochłonąć właśnie tę awarię, którą próbujesz złapać.

Dla każdego pliku wybierz jedno z dwojga i zapisz wybór, bo mieszanie ich na tej samej ścieżce tworzy luki, które później bardzo trudno przypisać. Czytelnik, który w jednym katalogu znajdzie oba wzorce, nie potrafi powiedzieć, który jest wiążący.

Ustaw przechowywanie według okna incydentu

Przechowywanie, kompresja i maksymalny rozmiar powinny wynikać z tego, jak głęboko naprawdę badasz. Okno siedmiu dni z kompresją i limitem rozmiaru to rozsądny punkt wyjścia dla wielu wdrożeń; liczba skopiowana z poradnika nie jest.

Trzymaj politykę w jednym miejscu. Jeśli logrotate rotuje plik i rsyslog też go rotuje, wygrywa druga rotacja, a schemat nazewnictwa pierwszej zostaje jako bałagan. Wybierz właściciela, wyłącz drugą rotację i zapisz tę decyzję obok polityki.

Dokumentacja rsyslog omawia jego model routingu i akcji, a dokumentacja usługi OpenVPN pozostaje wiążąca dla własnych opcji logowania demona. Żadna z nich nie decyduje za ciebie o twojej polityce przechowywania.

Przetestuj jedną rotację i jedno nowe zdarzenie

Wymuś jedną rotację, a potem wygeneruj jedno nowe zdarzenie, na przykład nieudaną autoryzację. Potwierdź, że nowy rekord pojawia się w nowym pliku i że stary plik przestał rosnąć.

Sprawdź też uprawnienia nowego pliku, bo rotacja, która odtwarza go z innym właścicielem, psuje pisarza przy następnym zapisie i tworzy lukę wyglądającą jak awaria. Porównaj właściciela i tryb z kontem usługi, zanim odejdziesz. Potem potwierdź, że skompresowane archiwum jest czytelne, bo archiwum, którego nikt nie może otworzyć, nie jest przechowywaniem. Szybkie odczytanie najnowszego rekordu w starym pliku dowodzi zarówno kompresji, jak i uprawnień.

Zakończ, zapisując właściciela każdego kroku: który komponent pisze, który rotuje i gdzie mieszka polityka przechowywania. Ten zapis zamienia następny incydent z logami w pięciominutowe sprawdzenie zamiast popołudnia zgadywania, która warstwa zgubiła linię.