Walang ipinapakitang pinakabagong handshake ang WireGuard: ano ang unang titingnan

Ang walang laman na field ng pinakabagong handshake ay karaniwang nangangahulugang hindi pa nakumpleto ng interface ang anumang handshake mula nang bumangon ito, na mas kaunti ang sinasabi tungkol sa configuration kaysa sa tila. Nananatiling tahimik ang WireGuard hanggang may packet na kailangang lumabas sa interface, kaya ang isang idle peer na walang maipadala ay iniuulat mismo iyon. Alamin muna kung may tunay na inihandog bago suriin ang mga key.

Ang pagsubok ay isang pinapayagang packet patungo sa destinasyong dapat dalhin ng peer. Ang lahat ng iba pa sa status screen na iyon ay naglalarawan ng layunin, hindi ng aktibidad.

Walang maipapaalam ang isang idle na interface

Tamad na gumagawa ng handshake ang WireGuard: ang unang packet na nangangailangan ng tunnel ang nagpapasimula ng palitan, at tahimik ang interface hanggang doon. Ang isang peer na na-configure at hindi kailanman ginamit ay nagpapakita ng walang laman na handshake, zero byte na natanggap at lumalawak na agwat mula sa huli. Malusog ang estadong iyon para sa isang idle na kliyente at nakakaalarma lamang kung inaasahan mong dumaloy na ang trapiko. Suriin din ang mga transfer counter, dahil hinihiwalay nila ang walang-ipinadala sa sinubukan-at-bigo.

Kung zero ang mga counter sa magkabilang panig, ang problema ay nasa itaas ng tunnel. Walang nakarating sa interface upang magpukaw ng anuman.

Pukawin ang trapikong pinapayagang dalhin ng peer

Pumili ng address sa loob ng mga pinapayagang prefix ng peer, sa lokal na makina, at kumpirmahin na ipapadala ito ng routing table sa pamamagitan ng interface. Ang destinasyong labas ng mga prefix na iyon ay gumagawa ng ordinaryong routed na kahilingan nang walang anumang pakikilahok ng WireGuard. Gumamit ng serbisyong mabilis sumagot, tulad ng ping o maikling TCP connection, upang may nakikitang simula at wakas ang pagtatangka. Pagkatapos ay basahin muli ang linya ng handshake sa halip na titigan ang screen at maghintay.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

Mas mahalaga ang query sa ruta kaysa sa ping. Kung pinapangalanan nito ang pisikal na interface, hindi kailanman pumasok ang packet sa tunnel at ang walang laman na handshake ay sagot sa routing, hindi cryptographic. Ayusin ang ruta bago i-debug ang peer.

Ihambing ang pares ng key at ang endpoint

Kapag tunay na inihandog ang trapiko, ang pagkakakilanlan ang susunod na pagsusuri. Dapat tumugma ang lokal na pribadong key sa pampublikong key na pinapayagan ng kabilang panig, dapat tukuyin ng naka-configure na malayong pampublikong key ang nilalayong peer, at dapat magtugma ang anumang paunang ibinahaging key sa magkabilang dulo. Ang isang karakter na pagkakaiba sa isang base64 key ay gumagawa ng peer na mukhang naka-configure at hindi kailanman nakukumpleto ang palitan. Ihambing sa talaan ng provisioning sa halip na muling buuin ang mga key, dahil ang bagong key ay nagpapawalang-bisa sa bawat peer na nagtiwala sa luma.

Kailangan ng endpoint ang parehong pagsusuri: hostname, address, UDP port at ang pamilyang ginamit upang maabot ito. Ang lumang address o maling port ay nagbubunga ng katahimikan sa halip na mensahe.

Bantayan ang panlabas na landas ng UDP

Nagbibiyahe ang handshake bilang UDP patungo sa endpoint, kaya dapat itong dalhin ng panlabas na landas. Sinusuri ng mga utos sa ibaba kung may nakikinig, kung naglabas ang lokal na stack ng datagram, at kung aling endpoint ang naka-configure. Patakbuhin ang pagkuha habang pinupukaw ang trapiko, hindi bago.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Ang pagkuha na nagpapakita ng pagsisimula nang walang sagot ay tumuturo sa labas ng makina, dahil ang kabilang dulo ay maaaring hindi nakikinig, na-filter, o mali ang address. Ang pagkuha na walang ipinapakita ay nangangahulugang hindi kailanman lumabas ang packet, na nagbabalik sa iyo sa ruta at sa anumang socket mark na kasangkot. Kapag pinangangasiwaan mo ang magkabilang dulo, iugnay ang pagtatangka ayon sa timestamp sa makitid na pagkuha sa server sa halip na pangkalahatan. Walang pinatutunayan ang TCP port test dito, dahil UDP lamang ang protocol.

Sa sandaling lumitaw ang handshake, subukan ang isang aplikasyon sa tunnel, dahil ang nakumpletong palitan ay nagpapatunay ng pagkakakilanlan at maabot, hindi ng magagamit na throughput o tamang DNS. Itabi ang output ng status bago at pagkatapos ng pagbabago, at ang pagkakaiba ang magiging ebidensya mo.