Buhay ang handshake, nawala ang address: tatlong estado ng WireGuard
Pinatutunayan ng bagong handshake na sumagot ang peer, hindi na hawak ng interface ang address nito o na ang susunod na packet ay dadaan sa nais na uplink.
Maaaring magkasabay ang bagong handshake at kawalan ng address sa WireGuard, at ang estadong iyon ay magkakaugnay, hindi magkasalungat. Ang handshake ay pangyayari ng peer, ang address ay pag-aari ng interface, at ang ruta ang nagpapasya kung saang uplink lalabas ang packet. Tatlong patong, tatlong may-ari, at bawat isa ay maaaring mabigo habang ang dalawa ay mukhang maayos.
Ang pagbasa sa mga ito bilang isang estado lang ang nagpapalit ng dalawang minutong pagsusuri sa buong hapon ng pag-restart ng mga serbisyo.
Ang handshake ay pangyayari ng peer, hindi pangyayari ng pag-address
Pinatutunayan ng handshake ng WireGuard na sumagot ang naka-configure na peer gamit ang wastong key at ang mga session key ay bago. Wala itong sinasabi tungkol sa lokal na address sa interface, at wala rin tungkol sa kung may rutang tumuturo doon. Ang address ay ibinibigay ng helper o ng network manager, habang ang configuration ng protocol ay nagpangalan lamang ng mga peer at key. Ang paghahalo ng dalawang ito ang dahilan kung bakit ang maayos na handshake ay nababasa bilang gumaganang tunnel.
Kaya nga ang wg show ay makapag-uulat ng handshake na ilang segundo ang edad sa isang interface na hindi kayang tumanggap ng kahit isang packet mula sa application.
Ang manager na gumagawa muli ng interface ay maaaring magpabagsak ng address nang hindi ginagalaw ang configuration ng peer, at ang susunod na handshake ay agad na nagtagumpay dahil hindi kailanman nagbago ang mga key. Ang log line tungkol sa matagumpay na handshake ay tumpak at walang kaugnayan sa pagkasira.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
May sariling may-ari ang address ng interface
Ang address sa tunnel device ay maaaring magmula sa Address na linya ng helper, sa DHCP client na tumatakbo sa interface, o sa management daemon na gumagawa nito kapag kumonekta. Anuman ito, pag-aari ng bahaging iyon ang address at ibabalik ito o hindi ayon sa sariling lohika. Ang pagbasa ng address nang hindi pinapangalanan ang may-ari ay nag-iiwan sa iyo na walang paliwanag kung bakit ito nawala.
Dalawang may-ari sa isang interface ang klasikong pagkasira. Ang pagpapatakbo ng helper at desktop network manager sa iisang device ay gumagawa ng karera kung saan inaalis ng isa ang kalilinisang i-configure ng isa pa, at patuloy na sumasagot ang endpoint sa buong panahon.
Pumili ng isang may-ari at hayaang magmasid ang kabilang tool sa halip na mamahala. Sulit na isulat ang desisyong iyon, dahil lumilitaw ang sintomas pagkalipas ng mga linggo at mukhang random na pagkawala ng address.
Ruta ang pumipili ng uplink, hindi ang interface
Ang panloob na ruta na tumuturo sa wg0 ay nagpapasyang pumapasok ang trapiko sa tunnel. Ang hiwalay na desisyon ang nagpapadala ng naka-encrypt na panlabas na packet patungo sa peer, at sa host na may ilang uplink ang desisyong iyon ay nagmumula sa forwarding table at sa mga patakaran ng polisiya. Ang Wi-Fi roaming ay makapagbabago ng panlabas na landas nang hindi ginagalaw ang panloob na address.
Kaya ang gumaganang tunnel at ang peer na hindi maabot ay magkatugmang estado, gayundin ang tamang peer at ang sirang panloob na ruta. Ang tatlong obserbasyon ay dapat kunin nang sama-sama, sa iisang sandali, kung hindi ay walang saysay ang paghahambing.
Ihambing ang tatlong estado sa isang pagdaan
Tatlong command na basa-lamang ang sumasagot sa tatlong tanong sa ayos na pinakamabilis na naghihiwalay ng pagkasira. Patakbuhin ang mga ito nang walang binabago sa gitna.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer
Ipinapakita ng una kung may address man ang interface, at ipinapakita ng pangalawa kung aling device ang gagamitin ng isang partikular na destinasyon ngayon. Ang pangatlo ay nag-uulat ng oras ng huling handshake at ng mga byte counter, at ito lamang sa tatlo ang naglalarawan sa peer at hindi sa lokal na host.
Basahin ang mga counter kasama ang timestamp. Ang handshake na paulit-ulit na nagre-refresh habang patagilid ang paglilipat ay nangangahulugang sumasagot ang peer ngunit walang kapaki-pakinabang na dumadaan, na tumuturo sa routing o isang ACL at hindi sa mga key. Ang timestamp na tumitigil sa pag-usad habang may address ay tumuturo sa itaas sa halip. Ang dalawang pagbasa ay nagmumula sa iisang linya ng output, at wala sa kanila ang nakikita kung ang titingnan mo lamang ay kung may handshake.
Itama ang partikular na estadong mali, pagkatapos ay subukan muli ang application at hindi ang tunnel. Ang bagong handshake ay ebidensya tungkol sa peer, at ang ebidensya tungkol sa peer ay hindi ebidensya na ang susunod na kahilingan mula sa iyong browser ay makakatagpo ng address, ruta at gumaganang uplink. Ang manwal ng wg-quick ay malinaw kung alin sa mga ito ang inaayos ng helper at alin ang kabilang sa protocol.