De leeftijd van een WireGuard-handshake is geen sessietime-out

Een peer die geen verkeer meer doorlaat verliest daardoor zijn sleutel niet, en een nieuwe handshake bewijst niet dat iemand de toestemming om hem te gebruiken heeft vernieuwd. De timers van WireGuard houden sleutels vers en pakketten in beweging; ze modelleren geen gebruiker die na een vast aantal minuten uitlogt. Hier worden drie vragen verward, en elk heeft ander bewijs. Het onderscheid bepaalt naar welk gereedschap je grijpt.

Drie vragen, één commando-uitvoer

Beheerders vragen of een peer bereikbaar is, of hij actief is geweest en of hij nog is toegestaan. Het eerste is protocolstatus, het tweede zijn verkeerstellers en het derde is autorisatie. Alleen de eerste twee zijn uit een WireGuard-interface te lezen, en ze worden routineus gebruikt om alle drie te beantwoorden.

Lees de rijen als drie afzonderlijke onderzoeken. De eerste twee zijn goedkoop en kunnen met de eigen tellers van de interface worden beantwoord. De derde heeft de configuratie nodig die toegang verleent, en die staat in een ander bestand of een ander systeem. De verkeerde rij kiezen is een protocoltimer vragen om het werk van een beleid te doen.

Wat de timers werkelijk beheren

Het protocol definieert constanten voor het opnieuw proberen van de handshake, rotatie van transport-sleutels en het verwerpen van pakketten die door een oude sleutel zijn beschermd. Ze reageren op verkeer en op toestand, niet op een kalender of op een beleid dat zegt dat iemand tot 17:00 verbonden mag zijn. Daarom kan een inactieve peer urenlang inactief lijken en toch geautoriseerd blijven.

PersistentKeepalive wordt vaak voor de ontbrekende time-out aangezien. Het stuurt geauthenticeerde lege pakketten om een NAT-koppeling in leven te houden, en op nul zetten stopt die pakketten zonder iets in te trekken.

Lees de runtime-toestand per peer, met de publieke sleutel in plaats van het commentaar:

wg show wg0 latest-handshakes
wg show wg0 transfer

Een recente handshake zegt dat één handshake is voltooid. Hij zegt niet dat de privédienst achter de tunnel bereikbaar is, en een oude tijdstempel kan bij een peer horen die simpelweg stil is.

Waarom een inactieve peer geen uitgelogde peer is

WireGuard heeft geen sessieobject met een begin en een einde. Een peer is een publieke sleutel met toegestane adressen, en de handshake die zijn verkeer beschermt wordt zo nodig vervangen zonder enige voor de gebruiker zichtbare login. Het ontbreken van recent verkeer als uitloggen behandelen keert het model om.

Als de echte klacht is dat een verbinding na stilstand mislukt, ligt de oorzaak meestal elders: een verlopen NAT-koppeling, een apparaat dat heeft geslapen of een firewall die toestand heeft laten vallen. Test door verkeer van de andere kant te sturen en een nieuwe stroom te starten, en vergelijk wat er verandert.

Zet de deadline waar de autorisatie woont

Als toegang op een bepaald tijdstip moet eindigen, hoort de deadline bij wat de toegang verleent. Een controller die peer-configuraties uitgeeft kan een vernieuwde goedkeuring eisen voordat hij een nieuwe uitdeelt, en dat is een eigenschap van de controller en geen verborgen parameter op de interface.

Voor handmatig beheerde peers moet verwijdering beide plaatsen bereiken: de draaiende interface en de opgeslagen configuratie. De peer alleen tijdens runtime verwijderen wordt ongedaan gemaakt door een herstart of een afstemmingslus, die de identiteit herstelt waarvan je dacht dat die verlopen was:

sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0

Test dan de grens in plaats van het label. Bevestig dat de peer na de deadline wordt geweigerd, bevestig dat het vernieuwingspad werkt en bevestig dat de toestand een herlaad van de beheerder overleeft. De leeftijd van een handshake is een nuttig operationeel signaal, en het is geen toegangsregistratie.