Dlaczego przypomnienie VPN na 23 godziny uruchamia się dla niewłaściwej sesji
Powiadomienie po 23 godzinach powinno dotyczyć jednej sesji, a nie konta. Przypnij licznik do połączenia, które się zaczęło, a uśpienie i ponowne połączenie traktuj jako osobne przypadki.
Powiadomienie pojawiło się dwadzieścia minut po połączeniu. Licznik pod nim działał od poprzedniego ranka albo od ostatniego uwierzytelnienia konta, a nic w alercie nie mówiło, od którego. To jest objaw: przypomnienie przypięte do czegoś innego niż połączenie przed tobą.
Rozwiązaniem nie jest lepszy alert. To decyzja, który zegar ma na myśli wymaganie, a potem przypięcie licznika do obiektu, który istnieje w tym zegarze.
Co się uruchomiło i co odliczało
Trzy prawdopodobne źródła dają ten sam komunikat. Reguła kalendarza działa o stałej godzinie lokalnej i nic nie wie o tunelach. Licznik w kliencie narasta, dopóki jakiekolwiek połączenie jest aktywne, i przeżywa ponowne połączenia. Polityka bramy wygasza sesję po stronie serwera i najpierw wysyła ostrzeżenie.
Tylko dwa ostatnie dotyczą sesji i nawet one się nie zgadzają. Licznik klienta mierzy to, co zaobserwował proces lokalny; brama mierzy to, co uwierzytelniła i rozliczyła. Uśpienie, zmiana sieci albo restart obserwatora mogą je rozdzielić o godziny, i dlatego ostrzeżenie i wymuszone wygaśnięcie rozjeżdżają się.
Trzy zegary za jednym wymaganiem
Zacznij od zapisania zdania, którego naprawdę chcesz. Ostrzeżenie, zanim brama zakończy to połączenie, to nie to samo wymaganie co przypomnienie po dobie połączonego czasu. To także nie to samo co zgłoszenie, że ta sesja trwa już 23 godziny. Każda wersja nazywa inne zdarzenie, a inny komponent musi na nie odpowiedzieć.
Potem sprawdź, czy dane istnieją. Lokalny znacznik czasu rozpoczęcia daje wiek sesji bez zależności od serwera. Polityka bramy daje pozostały czas życia, ale tylko wtedy, gdy brama go udostępnia. Raport użycia daje czas trwania po fakcie, a to nie może sterować powiadomieniem z wyprzedzeniem.
Przypnij licznik do sesji, a nie do konta
Najpierw wybierz obiekt. Konto może mieć kilka urządzeń i kilka równoczesnych sesji, więc przypomnienie oparte na nazwie użytkownika nie powie, które połączenie osiągnęło ten wiek. Przypnij je do profilu i tego aktywowania, a gdy aktywowanie się skończy, anuluj oczekujące powiadomienie.
| Evidence you can read | What it establishes | Where it misleads |
|---|---|---|
| Connection state changes to active | A session started now | Does not carry the gateway's own session identifier |
| Duration reported at disconnect | Total service time for that session | Arrives too late for any advance notice |
| Interim usage update | Time accounted up to that update | Staleness equals the update interval |
| Local timestamp taken at activation | Age of your observation | Resets whenever the observer restarts |
Ta tabela to kontrakt dla twojego własnego powiadamiacza, a nie opis API wywołań zwrotnych jakiegokolwiek klienta. To, co zainstalowany produkt dokumentuje o stanie połączenia, jest źródłem, do którego trzeba się przywiązać; tam, gdzie udostępnia tylko zdarzenia uwierzytelniania, powiedz to głośno i zaakceptuj grubsze zachowanie, zamiast wnioskować o sesji.
Sprawdź to krótkim progiem
Nigdy nie debuguj dobowego licznika dobowym czekaniem. Dodaj konfigurowalny próg, ustaw go na trzydzieści sekund i wykonaj po kolei cztery przejścia: połącz, poczekaj, rozłącz, połącz ponownie. Każde przejście powinno dać dokładnie jedną zmianę stanu, a ponowne połączenie powinno zaplanować nowy termin, a nie odziedziczyć stary.
# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work
# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o cat
Patrz na znaczniki czasu, a nie na sformułowanie. Powiadomienie, które przychodzi z czasem rozpoczęcia poprzedniej sesji, przypięło zły obiekt, a powiadomienie, które przychodzi dwa razy na jeden termin, znaczy, że flaga wysłania nigdy nie została zapisana.
Uśpienie, ponowne połączenie i utracone doręczenie
Uśpienie psuje oba naiwne projekty. Monotoniczne odliczanie zatrzymuje się, gdy maszyna śpi, termin według zegara ściennego wciąż się przesuwa, a licznik, który zadziała podczas uśpienia, jest dostarczany późno albo wcale. Zdecyduj, jakiego zachowania wymaga twoje wymaganie, potem uśpij maszynę poza progiem i potwierdź to.
Dostarczanie zasługuje na taką samą troskę. Jeśli powiadomienia nie można pokazać, ustaw je w kolejce i przed ostatecznym pokazaniem sprawdź ponownie, czy docelowa sesja nadal istnieje; inaczej użytkownik jest ostrzegany o połączeniu, które już się skończyło. Wymuszone rozłączenie i odnowienie poświadczeń zostają poza tą ścieżką, bo przypomnienie, które po cichu zmienia los połączenia, jest decyzją polityki ubraną w powiadomienie.