UDP-scan seit filtere: is dyn WireGuard-peer echt del?

Skenners printsje iepen of filtere foar in UDP-poarte, en de konklúzje folget meastentiids binnen sekonden: de tunnel is stikken. It kin wêze, mar de scan hat dat net fêststeld. UDP draacht gjin ferbining-hanske, en WireGuard antwurdet neat dat it net ferifiearje kin, dus stilte is it ferwachte antwurd op de measte probes.

Werkje ynstee fan de klient nei bûten ta, en behannelje de scan as ien swak datapunt ûnder ferskate.

Wat de skenner wol en net sjen kin

In UDP-skenner stjoert in lading en wachtet. As der in ICMP port-unreachable weromkomt, kin er de poarte as sletten rapportearje. As der neat weromkomt, is it resultaat fanwege it ûntwerp dûbelsinnich: in filtere paad, in ôfwêzige host en in rinnende tsjinst dy’t de lading negearre hat, produsearje allegear deselde stilte. Trije ferskillende steaten, ien útfierstring.

WireGuard makket dy dûbelsinnigens mei opsetsin slimmer. It protokol akseptearret in pakket allinnich as it ferifiearret, dus in probe mei de ferkearde kaaien wurdt sûnder antwurd fuortsmitten. Der is gjin banner, gjin ferzje-string en gjin flaterberjocht om te fingerprinten.

In TCP-test op itselde poartenûmer testet neat besibbe. Hy oefenet in oare listener út dy’t miskien net bestiet, en syn wegering seit neat oer UDP.

Iepen filtere steaten beskriuwe dus de ûnwissichheid fan de skenner krekter as dat se dyn server beskriuwe.

Gean de echte klient fan it profyl nei binnen ta troch

Begjin mei de eigen werjefte fan de klient. Hat de ynterface in adres, neamt de konfiguraasje it juste einpunt, en beweecht de hânskut-teller as in ferbining besocht wurdt? In klient dy’t nea in pakket stjoerd hat en in klient waans pakketten fuortsmitten binne, lykje identyk yn in statusfinster. Allinnich de tellers ûnderskiede se, dus lês earst de tellers.

Besjoch dêrnei de serverkant wylst ien autorisearre besykjen bart, ynstee fan in aparte scan fan in tredde lokaasje te draaien:

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

It earste kommando rapportearret de lêste hânske per peer, wat direkte bewiis is dat in ferifiearre útwiksel foltôge is. It twadde lit sjen oft pakketten foar de listener oeral oankomme, wat in paadprobleem yn ien stap fan in konfiguraasjeprobleem skiedt.

As de opname neat lit sjen, hat it pakket de host nea berikt en is de tunnelkonfiguraasje net de fertochte. As it oankommende pakketten fan it ferwachte adres lit sjen wylst de hânske op nul bliuwt, binne de kaaien of de tastiene adressen fan de peer it folgjende plak om te sykjen.

Korrelearje op de server as jo dy beheare

Befêstigje dat de listener bestiet en dat de firewall fan de provider de UDP-poarte tastean. In host-firewallregel en in cloud-feiligheidsgroep binne twa ûnôfhinklike poarten, en elk fan beide kin in pakket fuortsmite dat de oare tastien hat. Kontrolearje beide tsjin de werklike poarte yn de konfiguraasje ynstee fan de poarte dy’t jo ûnthâlde.

It adres is like wichtich as de poarte. In server dy’t op in spesifyk adres harket, sil gjin antwurd jaan op in pakket dat op in oar oankomt, en in host mei meardere ynterfaces kin de probe ûntfange op de ynterface dy’t jo net bedoelden.

Hâld elke test binnen systemen dêr’t jo foar autorisearre binne om te testen. De nuttige ferliking is tusken ien echte klientbesykjen en it ferwachte serverpaad, net in breder sweep fan adressen dy’t tafallich by deselde provider hearre.

In scanresultaat earlik lêze

In scan is in goedkeape manier om te kontrolearjen dat in host bestiet en dat in poarte net fanselssprekkend troch in tuskenlizzend apparaat blokkearre wurdt. It is gjin berikberheidsbewiis foar in ferifiearre protokol, en it is perfoarst gjin konfiguraasjetest.

It sterkere bewiis is in foltôge hânske fan de klient dy’t jo echt oanbelanget, folge troch in fersyk dat de tunnel brûkt en antwurd krijt. Dy searje oefenet de kaaien, de tastiene adressen, beide firewalls en it werompaad yn ien kear út.

Wêr’t it echte besykjen mislearret, moat de flater dochs diagnostisearre wurde mei de tellers fan de klient en de opname fan de server, net mei noch in probe. De protokolbeskriuwing ferklearret wêrom’t in net-ferifiearre pakket gjin antwurd krijt, en dat is de hiele reden dat it scanresultaat dûbelsinnich is.