Kas ISP blokeerib UDP-d või on see tunnelis olev rakendus?

Keegi teatab, et VPN „blokeerib UDP-d“, ja see lause varjab kaht täiesti erinevat väidet. Üks käib transpordi kohta, mida juurdepääsuvõrk näeb, teine rakenduse pakettide kohta pärast nende dekrüpteerimist tunnelis. Krüpteeritud tunnelit saab väljastpoolt filtreerida ilma ühegi võtmeta ja sisemine UDP-rakendus võib ebaõnnestuda põhjustel, millel pole filtreerimisega mingit seost. Otsustage, millist väidet te testite, enne kui tõendeid kogute.

Kaks päist, üks sõna

NAT-traversaliga IPsec-i juurutuses on väline pakett UDP, adresseeritud kahe VPN-i lõpp-punkti vahel, tavaliselt pordil 4500. Selle sees kannab krüpteeritud kasulik koormus kõike, mida tunnel edasi saadab, mis võib ise olla TCP või UDP. Seega esineb sõna UDP kaks korda, erineva tähenduse ja erineva nähtavusega.

Vahepealne võrk näeb välist päist ja sisemisest mitte midagi. See võib välise voo lubada, kujundada või maha visata ning ei pea selleks midagi dekrüpteerima. Just see asümmeetria on kogu põhjus, miks need kaks väidet segi lähevad: sama sõna kirjeldab nii seda, mida võrk filtreerib, kui seda, mida rakendus saadab. Kirjutage kiht sõna kõrvale alati, kui leidu fikseerite, ja segadus kaob suures osas.

Sisemine päis muutub nähtavaks alles vastuvõtvas lõpp-punktis, pärast dekrüpteerimist. Sellest hetkest saadetakse paketti edasi nagu iga teist, sõltuvalt marsruutidest, poliitikast ja lõpp-punkti enda filtreerimisest. Need on eraldi otsused, mille teevad erinevad seadmed.

Mida võrk ikka veel näha võib

Krüpteerimine varjab kasuliku koormuse ja sisemise transpordipäise, mitte asjaolu, et voog on olemas. Lõpp-punktide aadressid, pordid, pakettide suurused ja ajastus jäävad nähtavaks ning sellest piisab, et liiklust heuristiliselt liigitada või konkreetset sihtkohta blokeerida.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Esimene salvestus näitab välist voogu füüsilisel liidesel ja teine sisemist voogu tunneli liidesel. Mõlema korraga käivitamine vastab küsimusele otse: kui väline voog on olemas ja sisemine mitte, ei saatnud rakendus tunnelisse midagi. Kui mõlemad on olemas ja midagi ei tule tagasi, on probleem tunnelist kaugemal, sihtkohas või tagasiteel.

RFC 3948 määratleb välise UDP-kapselduse ja ESP spetsifikatsioon määratleb selle sees oleva kaitstud paigutuse. Kumbki dokument ei luba, et juurdepääsuvõrk välise voo läbi laseb, seepärast tasub enne igasugust sisemise kohta käivat teooriat teha välisel korteežil kättesaadavustest. Blokeeritud väline korteež annab tunneli, mis ei teki kunagi, mitte tunneli, mis tekib ja kaotab seejärel ühe rakenduse.

Miks üks UDP-rakendus töötavas tunnelis ebaõnnestub

Tunnelil, mis kannab veebirakendust, kuid mitte UDP-rakendust, on mitu usutavat seletust, ja ISP-i poolne sisemise protokolli filtreerimine pole esimene. Kõige tavalisem on kate: kaks rakendust ei satu mõlemad samasse tunnelisse, sest UDP-sihtkoha marsruut puudub või kliendi jagatud tunneli reeglid välistavad selle.

Teine on lõpp-punkt. VPN-server, mis lubab protokollide loetelu, sihtkoha tulemüür või teenus, mis ei kuula kunagi oodatud pordil, tekitavad kõik ajalõpu, mis näeb välja täpselt nagu võrgu blokeering.

Kolmas on paketi suurus. UDP-rakendused saadavad sageli suuremaid datagramme kui veebipäring, ja kapseldamine vähendab kasutatavat MTU-d, nii et õnnestunud kätlusele võib järgneda vaikus esimese täissuuruses kasuliku koormuse juures. Seda mustrit on lihtne blokeeringuna valesti lugeda, sest väikesed paketid lähevad läbi ja suured kaovad. Kiire MTU-proov lahendab selle alla minutiga ja vastuseks on tavaliselt väiksem koormus või parandatud MSS, mitte võrgufilter.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Esimene käsk kontrollib, kas suur pakett läbib tee fragmenteerimisega välja lülitatud, mis paljastab MTU-probleemi kiiresti. Teine saadab väikese, piiratud UDP-voo ja teatab kadudest ning jitterist. Voog, mis algab ja siis seiskub, osutab suurusele, mitte blokeeringule.

Teatage kiht, mitte protokoll

Kirjutage leid ühel kolmest kujul: väline kohaletoimetamine ebaõnnestus, sisemine edasisaatmine ebaõnnestus või rakendus ebaõnnestus. Igal on erinev omanik ja nende segamine saadab pileti valele meeskonnale.

Kohaliku pordi muutmine ei saa kaughostas luua vastavat kuulajat, seega kliendipoolne lahendus, mis näib aitavat, on tavaliselt tõend, et algne sihtkoht oli vale. Samuti tõestab antud alternatiivne profiil midagi kättesaadavuse kohta ja mitte midagi selle kohta, kas rakendus on õigesti seadistatud.

Hoidke järeldus vaatlusest eraldi. Liiklusanalüüs võib vihjata, mis voog on, ilma seda dekrüpteerimata, ja see on kasulik leid, kuid see ei ole sama väide kui sisemise päise lugemine. Öelge, kumb neist teil tegelikult on.