UDP VPN молчи при скенирање на порта? Зошто се случува тоа
WireGuard и зацврстениот OpenVPN отфрлаат датаграми што не поминуваат автентикација без да одговорат. Молчењето од скенер е очекувано однесување, а не затворена порта.
Ја скенирате портата на VPN, не добивате одговор и заклучувате дека услугата е падната или дека огнениот ѕид е затворен. Кај WireGuard и кај контролните канали на OpenVPN што носат сопствена автентикација, тој заклучок не следи. Датаграм без валиден автентикациски материјал се отфрла без одговор, па молчењето е како изгледа здрава услуга однадвор. Пробата е погрешна пред тунелот да биде.
Молчењето е протоколот, а не дефект
UDP нема воспоставување на врска, па нема SYN ниту потврда што би му овозможила на скенерот да разликува отворена порта од филтрирана. Пробата пристигнува како изолиран датаграм и услугата проверува дали одговара на протоколот што го очекува. Кога не одговара, пакетот се отфрла, а отфрлањето е документирано однесување, а не дефект.
WireGuard криптографски ги проверува своите пораки за ракување и ги игнорира сите што не поминуваат. OpenVPN со tls-auth или tls-crypt го прави истото за својот контролен канал. Во двата случаи произволното полезно оптоварување никогаш не стигнува до фаза насочена кон корисникот, па нема со што да се одговори и нема грешка што треба да се врати.
TCP ќе ви дадеше ресетирање од затворена порта. UDP ве остава во нејасност, која скенерите ја решаваат со печатење отворена или филтрирана наместо со погодување.
Што скенерот може, а што не може да заклучи
Резултатот од скенирање е толку информативен колку што е информативно испратеното полезно оптоварување. Подредете ги можните набљудувања според тоа што секое од нив навистина го поддржува:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Читајте го третиот ред како единствен позитивен тест во списокот. Тој бара вистински профил, вистински клуч и правилна крајна точка, а тоа е токму она што го нема општ скенер.
Погледнете ги двата краја на патеката
За сервер што го администрирате, снимајте на интерфејсот пред да донесете каков било заклучок, потоа прашајте ја услугата што видела. Двете команди бараат root на портата:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showАко на интерфејсот не се појави ниту еден пакет, патеката го отфрлила пред услугата да види нешто, а следното застанување е рутирање и филтрирање. Ако пакетите пристигнуваат, но ниту едно ракување не завршува, услугата е достапна и несовпаѓањето е во клучевите, конфигурацијата на крајната точка или верзијата на протоколот. Таа споредба одговара на прашањето на кое скенерот не можеше. Извршете ја додека вистински клиент се обидува да се поврзе, а не додека скенерот се повторува.
Сменете го тестот, а не заштитата
Примамливиот кратен пат е да ја исклучите заштитата на контролниот канал за да добие дијагностиката одговор. Тоа разменува вистинска безбедносна својство за поубав резултат од скенирање, и тоа е погрешна насока. Наместо тоа користете валиден профил од одобрена мрежа и забележете ја крајната точка и времето за споредбата да биде повторлива.
Најкорисниот тест е диференцијален: истиот профил на патека што работи и на патеката што не работи. Ако работната патека создаде ракување, а неуспешната патека не создаде ништо на интерфејсот, ја лоциравте точката на прекин без да ослабите ништо.
Затоа неодговорениот UDP пакет не докажува ниту дека серверот е офлајн, ниту дека е безбеден. Тој докажува дека оваа проба, на оваа патека, во овој момент, не е прифатена.