VPN mbi UDP hesht në skanimin e porteve? Përse ndodh kjo
WireGuard dhe OpenVPN i forcuar i hedhin poshtë datagramet që nuk kalojnë vërtetimin pa u përgjigjur. Heshtja nga një skaner është sjellje e pritur, jo një port i mbyllur.
Skanoni portën e VPN-së, nuk merrni përgjigje dhe arrini në përfundimin se shërbimi ka rënë ose se muri i zjarrit është i mbyllur. Me WireGuard, dhe me kanalet e kontrollit të OpenVPN që mbajnë vërtetimin e tyre, ky përfundim nuk rrjedh. Një datagram pa material vërtetimi të vlefshëm hidhet poshtë pa përgjigje, prandaj heshtja është pamja që ka një shërbim i shëndoshë nga jashtë. Prova është e gabuar përpara se të jetë tuneli.
Heshtja është protokolli, jo një defekt
UDP nuk ka vendosje lidhjeje, prandaj nuk ka SYN as konfirmim që do t'i lejonte një skaneri të dallojë një port të hapur nga një i filtruar. Prova vjen si një datagram i izoluar, dhe shërbimi kontrollon nëse përputhet me protokollin që pret. Kur nuk përputhet, paketa hidhet poshtë, dhe hedhja është sjellja e dokumentuar dhe jo një avari.
WireGuard vërteton në mënyrë kriptografike mesazhet e tij të handshake dhe injoron çdo gjë që dështon. OpenVPN me tls-auth ose tls-crypt bën të njëjtën gjë për kanalin e tij të kontrollit. Në të dyja rastet një ngarkesë arbitrare nuk arrin kurrë në një fazë të drejtuar nga përdoruesi, prandaj nuk ka me çfarë të përgjigjesh dhe asnjë gabim për të kthyer.
TCP do të të kishte dhënë një reset nga një port i mbyllur. UDP të lë në paqartësi, të cilën skanerët e zgjidhin duke shtypur i hapur ose i filtruar në vend që të hamendësojnë.
Çfarë mund dhe çfarë nuk mund të përfundojë një skaner
Rezultati i një skanimi është aq informativ sa ngarkesa që dërgoi. Renditni vëzhgimet e mundshme sipas asaj që secili prej tyre mbështet vërtet:
| 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 |
Lexoni rreshtin e tretë si provën e vetme pozitive në listë. Kërkon profilin e vërtetë, çelësin e vërtetë dhe pikën fundore të saktë, dhe pikërisht këtë nuk e ka një skaner i përgjithshëm.
Shikoni të dy skajet e rrugës
Për një server që administroni, regjistroni në ndërfaqe përpara se të nxjerrni ndonjë përfundim, më pas pyesni shërbimin çfarë pa. Të dy komandat kërkojnë root në gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showNëse në ndërfaqe nuk shfaqet asnjë paketë, rruga e hodhi poshtë përpara se shërbimi të shihte ndonjë gjë, dhe ndalesa tjetër është rrugëzimi dhe filtrimi. Nëse paketat mbërrijnë por asnjë handshake nuk përfundon, shërbimi është i arritshëm dhe mospërputhja është në çelësa, konfigurimin e pikës fundore ose versionin e protokollit. Ai krahasim i përgjigjet pyetjes që skaneri nuk mundi. Ekzekutojeni ndërsa një klient i vërtetë përpiqet të lidhet, jo ndërsa skaneri përsërit veten.
Ndryshoni provën, jo mbrojtjen
Rruga e shkurtër joshëse është të çaktivizoni mbrojtjen e kanalit të kontrollit që një diagnostikim të marrë përgjigje. Kjo shkëmben një veti reale sigurie me një rezultat skanimi më të bukur, dhe është drejtimi i gabuar. Në vend të kësaj përdorni një profil të vlefshëm nga një rrjet i miratuar dhe shënoni pikën fundore dhe kohën që krahasimi të jetë i përsëritshëm.
Prova më e dobishme është ajo diferenciale: i njëjti profil në një rrugë që funksionon dhe në rrugën që nuk funksionon. Nëse rruga funksionuese prodhon një handshake dhe rruga dështuese nuk prodhon asgjë në ndërfaqe, e keni lokalizuar thyerjen pa dobësuar asgjë.
Një paketë UDP pa përgjigje, pra, nuk provon as që serveri është jashtë linje as që është i sigurt. Provon vetëm se kjo provë, në këtë rrugë, në këtë çast, nuk u pranua.