Wiek uzgadniania WireGuard to nie limit czasu sesji
Liczniki wymiany kluczy rządzą kluczami, a nie dostępem użytkownika. Odczyt latest-handshakes mówi o stanie protokołu jednego peera, a nie o tym, czy jego autoryzacja wygasła.
Peer, który przestaje przepuszczać ruch, nie traci przez to swojego klucza, a nowe uzgadnianie nie dowodzi, że ktoś odnowił pozwolenie na jego użycie. Liczniki WireGuard utrzymują klucze świeże, a pakiety w ruchu; nie modelują użytkownika, który wylogowuje się po ustalonej liczbie minut. Mieszają się tu trzy pytania i każde ma inne dowody. To rozróżnienie decyduje, po jakie narzędzie sięgniemy.
Trzy pytania, jedno wyjście polecenia
Operatorzy pytają, czy peer jest osiągalny, czy był aktywny i czy nadal jest dozwolony. Pierwsze to stan protokołu, drugie to liczniki ruchu, a trzecie to autoryzacja. Tylko dwa pierwsze można odczytać z interfejsu WireGuard i rutynowo używa się ich do odpowiedzi na wszystkie trzy.
| Question | Evidence it needs | What does not answer it |
|---|---|---|
| Is the peer reachable now? | A recent handshake and a working return path | An interface that exists |
| Has it been active? | Transfer counters moving over time | A handshake timestamp alone |
| Is access still granted? | The configuration or controller that authorizes it | Any protocol timer |
Czytaj wiersze jako trzy osobne śledztwa. Dwa pierwsze są tanie i można na nie odpowiedzieć własnymi licznikami interfejsu. Trzecie wymaga konfiguracji, która przyznaje dostęp, a ta mieszka w innym pliku lub innym systemie. Wybór złego wiersza to proszenie licznika protokołu o pracę polityki.
Czym naprawdę rządzą liczniki
Protokół definiuje stałe dla ponawiania uzgadniania, rotacji kluczy transportowych i odrzucania pakietów chronionych starym kluczem. Reagują one na ruch i na stan, a nie na kalendarz czy politykę mówiącą, że ktoś może być połączony do 17:00. Dlatego bezczynny peer może godzinami wyglądać na nieaktywny i wciąż być autoryzowany.
PersistentKeepalive bywa mylony z brakującym limitem czasu. Wysyła uwierzytelnione puste pakiety, aby utrzymać mapowanie NAT przy życiu, a ustawienie go na zero zatrzymuje te pakiety bez odbierania czegokolwiek.
Czytaj stan wykonania dla każdego peera, używając klucza publicznego, a nie komentarza:
wg show wg0 latest-handshakes
wg show wg0 transferŚwieże uzgadnianie mówi, że jedno uzgadnianie się zakończyło. Nie mówi, że prywatna usługa za tunelem jest osiągalna, a stary znacznik czasu może należeć do peera, który po prostu milczy.
Dlaczego bezczynny peer to nie wylogowany peer
WireGuard nie ma obiektu sesji z początkiem i końcem. Peer to klucz publiczny z dozwolonymi adresami, a uzgadnianie chroniące jego ruch jest wymieniane w razie potrzeby bez żadnego widocznego dla użytkownika logowania. Traktowanie braku świeżego ruchu jako wylogowania odwraca model.
Jeśli prawdziwym zarzutem jest to, że połączenie zawodzi po okresie bezczynności, przyczyna jest zwykle gdzie indziej: wygasłe mapowanie NAT, urządzenie, które zasnęło, albo zapora, która zgubiła stan. Testuj, wysyłając ruch z drugiej strony i rozpoczynając nowy przepływ, i porównaj, co się zmienia.
Umieść termin tam, gdzie mieszka autoryzacja
Jeśli dostęp ma się skończyć o określonej godzinie, termin należy do tego, co przyznaje dostęp. Kontroler, który wydaje konfiguracje peerów, może wymagać odnowionej zgody, zanim wyda nową, i jest to właściwość kontrolera, a nie ukryty parametr interfejsu.
W przypadku peerów zarządzanych ręcznie usunięcie musi dotrzeć w dwa miejsca: działający interfejs i zapisaną konfigurację. Usunięcie peera tylko w czasie działania jest cofane przez restart lub pętlę uzgadniania, która przywraca tożsamość, którą uważałeś za wygasłą:
sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0Potem testuj granicę, a nie etykietę. Potwierdź, że peer jest odrzucany po terminie, potwierdź, że ścieżka odnowienia działa, i potwierdź, że stan przetrwa przeładowanie menedżera. Wiek uzgadniania to użyteczny sygnał operacyjny i nie jest rejestrem dostępu.