UDP-skandering sê gefiltreer: is jou WireGuard-eweknie werklik af?

Skandeerders druk oop of gefiltreer vir ’n UDP-poort, en die gevolgtrekking volg gewoonlik binne sekondes: die tonnel is stukkend. Dit mag wees, maar die skandering het dit nie vasgestel nie. UDP dra geen verbinding-handskud nie, en WireGuard antwoord niks wat hy nie kan verifieer nie, so stilte is die verwagte antwoord op die meeste probes.

Werk eerder van die kliënt af uitwaarts, en beskou die skandering as een swak datapunt onder verskeie.

Wat die skandeerder kan sien en wat nie

’n UDP-skandeerder stuur ’n vrag en wag. As ’n ICMP-poort-onbereikbaar terugkom, kan dit die poort as gesluit rapporteer. As niks terugkom nie, is die resultaat volgens ontwerp dubbelsinnig: ’n gefiltreerde pad, ’n afwesige gasheer en ’n lopende diens wat die vrag geïgnoreer het, lewer almal dieselfde stilte. Drie verskillende toestande, een uitsetstring.

WireGuard maak daardie dubbelsinnigheid doelbewus erger. Die protokol aanvaar ’n pakket net wanneer dit verifieer, so ’n probe met die verkeerde sleutels word sonder antwoord weggegooi. Daar is geen banier, geen weergawe-string en geen foutboodskap om te vingerafdruk nie.

’n TCP-toets op dieselfde poortnommer toets niks verwants nie. Dit oefen ’n ander luisteraar uit wat dalk nie bestaan nie, en sy weiering sê niks oor UDP.

Oop gefiltreerde toestande beskryf dus die skandeerder se onsekerheid akkurater as wat dit jou bediener beskryf.

Stap die werklike kliënt van die profiel af inwaarts

Begin met die kliënt se eie siening. Hou die koppelvlak ’n adres, noem die konfigurasie die regte eindpunt, en beweeg die handskudteller wanneer ’n verbinding probeer word? ’n Kliënt wat nooit ’n pakket gestuur het nie en ’n kliënt wie se pakkette laat val is, lyk identies in ’n statusvenster. Net die tellers onderskei hulle, so lees eers die tellers.

Kyk dan na die bedienerkant terwyl een gemagtigde poging plaasvind, eerder as om ’n aparte skandering vanaf ’n derde plek te hardloop:

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

Die eerste opdrag rapporteer die laaste handskud per eweknie, wat direkte bewyse is dat ’n geverifieerde uitruiling voltooi is. Die tweede wys of pakkette vir die luisteraar hoegenaamd aankom, wat ’n padprobleem in een stap van ’n konfigurasieprobleem skei.

As die opname niks wys nie, het die pakket nooit die gasheer bereik nie en is die tonnelkonfigurasie nie die verdagte nie. As dit aankomende pakkette van die verwagte adres wys terwyl die handskud op nul bly, is die sleutels of die eweknie se toegelate adresse die volgende plek om te kyk.

Korreleer by die bediener wanneer jy dit administreer

Bevestig dat die luisteraar bestaan en dat die verskaffer se firewall die UDP-poort toelaat. ’n Gasheer-firewallreël en ’n wolksaanheidsgroep is twee onafhanklike hekke, en enigeen kan ’n pakket laat val wat die ander toegelaat het. Kontroleer beide teen die werklike poort in die konfigurasie eerder as die poort wat jy onthou.

Die adres maak net soveel saak soos die poort. ’n Bediener wat op ’n spesifieke adres luister, sal nie ’n pakket antwoord wat op ’n ander een aankom nie, en ’n gasheer met veelvuldige koppelvlakke kan die probe op die koppelvlak ontvang wat jy nie bedoel het nie.

Hou elke toets binne stelsels wat jy gemagtig is om te toets. Die nuttige vergelyking is tussen een werklike kliëntpoging en die verwagte bedienerpad, nie ’n wyer vee van adresse wat toevallig aan dieselfde verskaffer behoort nie.

Om ’n skanderingsresultaat eerlik te lees

’n Skandering is ’n goedkoop manier om te kontroleer dat ’n gasheer bestaan en dat ’n poort nie ooglopend deur ’n tussenliggende toestel geblokkeer word nie. Dit is nie ’n bereikbaarheidsbewys vir ’n geverifieerde protokol nie, en dit is beslis nie ’n konfigurasietoets nie.

Die sterker bewyse is ’n voltooide handskud van die kliënt waarvoor jy regtig sorg, gevolg deur ’n versoek wat die tonnel gebruik en ’n antwoord kry. Daardie reeks oefen die sleutels, die toegelate adresse, beide firewalls en die terugpad in een slag uit.

Waar die werklike poging misluk, moet die mislukking steeds met die kliënt se tellers en die bediener se opname gediagnoseer word, nie met nog ’n probe nie. Die protokolbeskrywing verduidelik waarom ’n ongeverifieerde pakket geen antwoord kry nie, en dit is juis die rede waarom die skanderingsresultaat dubbelsinnig is.