VPN праз UDP маўчыць пры сканаванні порта? Чаму так адбываецца
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 без адказу не даказвае ні таго, што сервер па-за сеткай, ні таго, што ён бяспечны. Ён даказвае, што гэтая проба, на гэтым шляху, у гэты момант не была прынята.