UDP-skanning säger filtrerat: är din WireGuard-peer faktiskt nere?
En oautentiserad probe får ofta inget svar från en frisk peer. Testa den riktiga klienten och korrelera sedan lyssnaren och paketvägen på servern.
Skannrar skriver ut öppen eller filtrerad för en UDP-port, och slutsatsen följer vanligtvis inom sekunder: tunneln är trasig. Det kan den vara, men skanningen har inte fastställt det. UDP bär ingen anslutningshandskakning, och WireGuard svarar inte på något det inte kan autentisera, så tystnad är det förväntade svaret på de flesta prober.
Arbeta istället från klienten och utåt, och behandla skanningen som en svag datapunkt bland flera.
Vad skannern kan och inte kan se
En UDP-skanner skickar en nyttolast och väntar. Om ett ICMP port-unreachable kommer tillbaka kan den rapportera porten som stängd. Om inget kommer tillbaka är resultatet tvetydigt av design: en filtrerad väg, en frånvarande värd och en körande tjänst som ignorerade nyttolasten ger alla samma tystnad. Tre olika tillstånd, en enda utdatasträng.
WireGuard förvärrar den tvetydigheten med avsikt. Protokollet accepterar bara ett paket när det autentiserar sig, så en probe med fel nycklar kastas utan svar. Det finns ingen banner, ingen versionssträng och inget felmeddelande att fingeravtrycka.
Ett TCP-test på samma portnummer testar ingenting besläktat. Det övar en annan lyssnare som kanske inte finns, och dess avvisning säger ingenting om UDP.
Öppna filtrerade tillstånd beskriver därför skannerns osäkerhet mer exakt än de beskriver din server.
Gå igenom den riktiga klienten från profilen och inåt
Börja med klientens egen bild. Har gränssnittet en adress, namnger konfigurationen rätt slutpunkt och rör sig handskakningsräknaren när en anslutning försöks? En klient som aldrig skickade ett paket och en klient vars paket släpptes ser identiska ut i ett statusfönster. Bara räknarna skiljer dem, så läs räknarna först.
Titta sedan på serversidan medan ett auktoriserat försök sker, istället för att köra en separat skanning från en tredje plats:
wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10
Det första kommandot rapporterar den senaste handskakningen per peer, vilket är direkt bevis på att ett autentiserat utbyte slutfördes. Det andra visar om paket för lyssnaren överhuvudtaget anländer, vilket skiljer ett vägproblem från ett konfigurationsproblem i ett steg.
Om inspelningen inte visar något nådde paketet aldrig värden och tunnelkonfigurationen är inte den misstänkta. Om den visar paket som anländer från den förväntade adressen medan handskakningen stannar på noll är nycklarna eller peerns tillåtna adresser nästa ställe att titta på.
Korrelera på servern när du administrerar den
Bekräfta att lyssnaren finns och att leverantörens brandvägg tillåter UDP-porten. En värdbrandväggsregel och en molnsäkerhetsgrupp är två oberoende portar, och vilken som helst av dem kan släppa ett paket som den andra tillät. Kontrollera båda mot den faktiska porten i konfigurationen istället för porten du minns.
Adressen spelar lika stor roll som porten. En server som lyssnar på en specifik adress svarar inte på ett paket som anländer på en annan, och en värd med flera gränssnitt kan ta emot proben på det gränssnitt du inte avsåg.
Håll varje test inom system du har tillstånd att testa. Den användbara jämförelsen är mellan ett riktigt klientförsök och den förväntade servervägen, inte en bredare genomgång av adresser som råkar tillhöra samma leverantör.
Att läsa ett skanningsresultat ärligt
En skanning är ett billigt sätt att kontrollera att en värd finns och att en port inte uppenbart blockeras av en mellanliggande enhet. Det är inte ett nåbarhetsbevis för ett autentiserat protokoll, och absolut inte ett konfigurationstest.
Det starkare beviset är en slutförd handskakning från den klient du faktiskt bryr dig om, följt av en begäran som använder tunneln och får ett svar. Den sekvensen övar nycklarna, de tillåtna adresserna, båda brandväggarna och returvägen på en gång.
Där det riktiga försöket misslyckas måste felet ändå diagnostiseras med klientens räknare och serverns inspelning istället för med ännu en probe. Protokollbeskrivningen förklarar varför ett oautentiserat paket inte får något svar, och det är hela anledningen till att skanningsresultatet är tvetydigt.