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 без отговор не доказва нито че сървърът е офлайн, нито че е безопасен. Той доказва, че тази проба, по този път, в този момент, не е била приета.