Ini-scan mo ang port ng VPN, walang sagot na dumarating at hinihinuha mong patay ang serbisyo o sarado ang firewall. Sa WireGuard, at sa mga control channel ng OpenVPN na may sariling authentication, hindi sumusunod ang hinuha na iyon. Ang datagram na walang wastong authentication material ay itinatapon nang walang sagot, kaya ang katahimikan ang hitsura ng malusog na serbisyo mula sa labas. Mali na ang pagsubok bago pa mali ang tunnel.

Ang katahimikan ang protocol, hindi ang sira

Walang connection setup ang UDP, kaya walang SYN at walang acknowledgement na magpapahintulot sa scanner na makilala ang bukas na port sa na-filter na port. Dumarating ang pagsubok bilang isang nakahiwalay na datagram, at tinitingnan ng serbisyo kung tumutugma ito sa protocol na inaasahan nito. Kapag hindi tumutugma, itinatapon ang packet, at ang pagtatapon ay ang dokumentadong pag-uugali, hindi ang sira.

Bineberipika ng WireGuard ang mga handshake message nito sa paraang cryptographic at binabalewala ang lahat ng nabibigo. OpenVPN na may tls-auth o tls-crypt ay ganoon din sa control channel nito. Sa dalawang kaso, hindi kailanman umabot ang anumang arbitraryong payload sa yugtong nakaharap sa user, kaya walang maisasagot at walang error na maibabalik.

Bibigyan ka sana ng TCP ng reset mula sa saradong port. Ang UDP ay nag-iiwan sa iyo ng kalabuan, na nilulutas ng mga scanner sa pamamagitan ng pag-print ng bukas o na-filter sa halip na manghula.

Ano ang mahihinuha at hindi mahihinuha ng scanner

Ang resulta ng scan ay kasing-informative lamang ng payload na ipinadala nito. Ayusin ang mga posibleng obserbasyon ayon sa aktwal na sinusuportahan ng bawat isa:

ProbeObserved resultWhat it supports
Empty datagramNo replyNothing beyond the fact that UDP was used
Random payloadNo replyConsistent with an authenticated service
Valid handshake from a real clientA protocol replyThe service is alive and reachable
ICMP port unreachableUnreachable messageThe host answered, usually because nothing listens

Basahin ang ikatlong hilera bilang ang tanging positibong pagsubok sa listahan. Nangangailangan ito ng tunay na profile, tunay na key at tamang endpoint, at iyon mismo ang wala sa isang generic na scanner.

Tingnan ang dalawang dulo ng landas

Para sa server na pinangangasiwaan mo, kumuha ng capture sa interface bago maghinuha, pagkatapos ay tanungin ang serbisyo kung ano ang nakita nito. Kailangan ng root sa gateway ang dalawang command:

tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show

Kung walang packet na lumilitaw sa interface, itinapon ito ng landas bago pa makakita ng kahit ano ang serbisyo, at ang susunod na hintuan ay routing at filtering. Kung dumarating ang mga packet pero walang handshake na natatapos, naaabot ang serbisyo at ang pagkakaiba ay sa mga key, configuration ng endpoint o bersyon ng protocol. Sinasagot ng paghahambing na iyon ang tanong na hindi kayang sagutin ng scanner. Patakbuhin ito habang sinusubukan ng tunay na client na kumonekta, hindi habang inuulit ng scanner ang sarili nito.

Palitan ang pagsubok, hindi ang proteksyon

Ang nakakaakit na shortcut ay patayin ang proteksyon ng control channel para makatanggap ng sagot ang diagnostic. Ipinagpapalit nito ang tunay na katangian ng seguridad sa mas magandang resulta ng scan, at mali ang direksyong iyon. Sa halip, gumamit ng wastong profile mula sa aprubadong network, at itala ang endpoint at oras para maulit ang paghahambing.

Ang pinakakapaki-pakinabang na pagsubok ay differential: parehong profile sa landas na gumagana at sa landas na hindi. Kung ang gumaganang landas ay gumagawa ng handshake at ang nabigong landas ay walang ginagawa sa interface, natukoy mo ang pagkaputol nang walang pinahina.

Kaya ang UDP packet na walang sagot ay hindi nagpapatunay na offline ang server o kaya ay ligtas ito. Pinatutunayan lamang nito na ang pagsubok na ito, sa landas na ito, sa sandaling ito, ay hindi tinanggap.

Kaugnay na mga artikulo