Sabi ng UDP scan ay filtered: talaga bang down ang WireGuard peer mo?

Nagpi-print ang mga scanner ng open o filtered para sa isang UDP port, at kadalasan dumarating ang konklusyon sa loob ng mga segundo: sira ang tunnel. Maaaring oo, pero hindi iyon pinatunayan ng scan. Walang dalang handshake ng koneksyon ang UDP, at walang sinasagot ang WireGuard na hindi nito ma-authenticate, kaya ang katahimikan ang inaasahang sagot sa karamihan ng probe.

Sa halip, magtrabaho mula sa client papalabas, at ituring ang scan bilang isang mahinang data point sa ilang iba pa.

Ano ang nakikita at hindi nakikita ng scanner

Nagpapadala ng payload ang isang UDP scanner at naghihintay. Kung may bumabalik na ICMP port-unreachable, maaari nitong iulat ang port bilang sarado. Kung walang bumabalik, malabo ang resulta ayon sa disenyo: isang filtered na landas, isang host na wala at isang serbisyong tumatakbo na hindi pinansin ang payload ay lahat gumagawa ng parehong katahimikan. Tatlong magkaibang estado, isang output string.

Sinasadyang pinapalala ng WireGuard ang kalabuan na iyon. Tumatanggap lang ang protocol ng packet kapag nagpapatotoo ito, kaya ang probe na may maling key ay itinatapon nang walang sagot. Walang banner, walang version string at walang error message na maaaring i-fingerprint.

Ang TCP test sa parehong port number ay walang sinusubukang kaugnay. Sinasanay nito ang ibang listener na maaaring wala, at walang sinasabi ang pagtanggi nito tungkol sa UDP.

Kaya mas tumpak na inilalarawan ng open filtered states ang kawalan ng katiyakan ng scanner kaysa sa paglalarawan nito sa server mo.

Lakarin ang tunay na client mula sa profile pabalik sa loob

Magsimula sa pananaw ng client mismo. May address ba ang interface, tinutukoy ba ng configuration ang tamang endpoint, at gumagalaw ba ang handshake counter kapag sinubukan ang koneksyon? Ang client na hindi kailanman nagpadala ng packet at ang client na itinapon ang mga packet ay magkamukha sa isang status window. Ang mga counter lang ang nagtatangi sa kanila, kaya basahin muna ang mga counter.

Pagkatapos, panoorin ang panig ng server habang nagaganap ang isang awtorisadong pagtatangka, sa halip na magpatakbo ng hiwalay na scan mula sa ikatlong lokasyon:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Iniuulat ng unang command ang huling handshake bawat peer, na direktang ebidensya na natapos ang isang authenticated na palitan. Ipinapakita ng pangalawa kung dumarating man lang ang mga packet para sa listener, na naghihiwalay ng problema sa landas mula sa problema sa configuration sa isang hakbang.

Kung wala itong ipinapakita ang capture, hindi kailanman nakarating ang packet sa host at hindi ang configuration ng tunnel ang pinaghihinalaan. Kung ipinapakita nito ang mga packet na dumarating mula sa inaasahang address habang nananatiling zero ang handshake, ang mga key o ang mga pinapayagang address ng peer ang susunod na titingnan.

I-ugnay sa server kapag pinangangasiwaan mo ito

Kumpirmahin na umiiral ang listener at pinapayagan ng firewall ng provider ang UDP port. Ang host firewall rule at ang cloud security group ay dalawang magkahiwalay na gate, at alinman sa kanila ay maaaring magtapon ng packet na pinayagan ng isa. Suriin ang dalawa laban sa aktwal na port sa configuration at hindi sa port na naaalala mo.

Kasinghalaga ng port ang address. Ang server na nakikinig sa isang partikular na address ay hindi sasagot sa packet na dumarating sa iba, at ang host na may maraming interface ay maaaring makatanggap ng probe sa interface na hindi mo sinadya.

Panatilihin ang bawat test sa loob ng mga sistemang awtorisado kang subukan. Ang kapaki-pakinabang na paghahambing ay sa pagitan ng isang tunay na pagtatangka ng client at ng inaasahang landas ng server, hindi isang mas malawak na sweep ng mga address na nagkataong pag-aari ng parehong provider.

Ang tapat na pagbasa ng resulta ng scan

Ang scan ay isang murang paraan para masuri na umiiral ang isang host at hindi halatang hinaharangan ng isang intermediate device ang isang port. Hindi ito patunay ng reachability para sa isang authenticated protocol, at tiyak na hindi ito test ng configuration.

Ang mas matibay na ebidensya ay isang natapos na handshake mula sa client na talagang mahalaga sa iyo, na sinusundan ng request na gumagamit ng tunnel at nakakakuha ng sagot. Sinasanay ng sequence na iyon ang mga key, ang mga pinapayagang address, ang dalawang firewall at ang return path sa isang iglap.

Kapag nabigo ang tunay na pagtatangka, kailangan pa ring i-diagnose ang pagkabigo gamit ang mga counter ng client at ang capture ng server, hindi gamit ang isa pang probe. Ipinapaliwanag ng paglalarawan ng protocol kung bakit walang sagot ang isang hindi authenticated na packet, at iyon ang buong dahilan kung bakit malabo ang resulta ng scan.