Ang edad ng handshake ng WireGuard ay hindi timeout ng session
Kinokontrol ng mga timer ng pag-renew ng key ang mga key, hindi ang pag-access ng user. Ang pagbasa ng latest-handshakes ay nagsasabi tungkol sa protocol state ng isang peer, hindi kung nag-expire na ang authorization nito.
Ang peer na tumigil sa pagpapadala ng traffic ay hindi dahil dito nawawala ang key nito, at ang bagong handshake ay hindi nagpapatunay na may nag-renew ng pahintulot na gamitin ito. Ang mga timer ng WireGuard ay nagpapanatili ng sariwang key at tuloy-tuloy na packet; hindi nila ginagaya ang user na nagla-log out pagkatapos ng takdang bilang ng minuto. Tatlong tanong ang napagkakahalo dito, at bawat isa ay may ibang ebidensya. Ang pagkakaibang ito ang nagtatakda kung aling tool ang gagamitin.
Tatlong tanong, isang output ng command
Nagtatanong ang mga operator kung naaabot ang isang peer, kung naging aktibo ito, at kung pinapayagan pa ito. Ang una ay protocol state, ang pangalawa ay mga counter ng traffic at ang pangatlo ay authorization. Tanging ang unang dalawa ang nababasa mula sa isang WireGuard interface, at karaniwang ginagamit ang mga ito upang sagutin ang tatlo.
| 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 |
Basahin ang mga hilera bilang tatlong hiwalay na imbestigasyon. Ang unang dalawa ay mura at masasagot gamit ang sariling counter ng interface. Ang pangatlo ay nangangailangan ng configuration na nagbibigay ng access, at ito ay nasa ibang file o ibang system. Ang pagpili ng maling hilera ay paghingi sa isang protocol timer na gawin ang trabaho ng isang patakaran.
Ano ba talaga ang kinokontrol ng mga timer
Tinutukoy ng protocol ang mga constant para sa muling pagsubok ng handshake, pag-ikot ng transport key at pagtanggi sa mga packet na protektado ng lumang key. Tumutugon ang mga ito sa traffic at sa state, hindi sa kalendaryo o sa patakarang nagsasabing puwedeng kumonekta ang isang tao hanggang 17:00. Iyon ang dahilan kung bakit ang isang idle peer ay maaaring magmukhang hindi aktibo nang maraming oras at nananatiling awtorisado.
PersistentKeepalive ay madalas napagkakamalang nawawalang timeout. Nagpapadala ito ng mga authenticated na walang laman na packet upang panatilihing buhay ang isang NAT mapping, at ang pagtatakda nito sa zero ay nagpapahinto sa mga packet na iyon nang walang binabawi.
Basahin ang runtime state bawat peer, gamit ang public key sa halip na ang komento:
wg show wg0 latest-handshakes
wg show wg0 transferAng kamakailang handshake ay nagsasabi na isang handshake ang natapos. Hindi nito sinasabi na naaabot ang pribadong serbisyo sa likod ng tunnel, at ang lumang timestamp ay maaaring pag-aari ng isang peer na tahimik lamang.
Bakit ang idle peer ay hindi logged-out na peer
Walang session object na may simula at wakas ang WireGuard. Ang peer ay isang public key na may pinapayagang address, at ang handshake na nagpoprotekta sa traffic nito ay pinapalitan kapag kailangan nang walang anumang login na nakikita ng user. Ang pagtrato sa kawalan ng kamakailang traffic bilang pag-log out ay binabaligtad ang modelo.
Kung ang tunay na reklamo ay nabibigo ang koneksyon pagkatapos ng idle, ang sanhi ay karaniwang nasa ibang lugar: isang nag-expire na NAT mapping, isang device na natulog, o isang firewall na nagbaba ng state. Subukan sa pamamagitan ng pagpapadala ng traffic mula sa kabilang panig at pagpapasimula ng bagong flow, at ihambing kung ano ang nagbabago.
Ilagay ang deadline kung saan nakatira ang authorization
Kung ang access ay dapat magtapos sa isang tiyak na oras, ang deadline ay pag-aari ng nagbibigay ng access. Ang controller na naglalabas ng peer configuration ay maaaring mangailangan ng na-renew na approval bago magbigay ng bago, at ito ay katangian ng controller at hindi isang nakatagong parameter sa interface.
Para sa mga peer na pinamamahalaan sa kamay, ang pag-alis ay dapat umabot sa dalawang lugar: ang tumatakbong interface at ang naka-save na configuration. Ang pag-alis sa peer habang tumatakbo lamang ay nababaligtad ng restart o reconciliation loop, na nagbabalik sa identity na akala mo ay nag-expire na:
sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0Pagkatapos ay subukan ang hangganan at hindi ang label. Kumpirmahin na tinatanggihan ang peer pagkatapos ng deadline, kumpirmahin na gumagana ang renewal path, at kumpirmahin na ang state ay tumatagal pagkatapos ma-reload ang manager. Ang edad ng handshake ay kapaki-pakinabang na operational signal, at hindi ito access record.