Az ISP blokkolja az UDP-t, vagy a tunnelben lévő alkalmazás?

Valaki azt jelenti, hogy a VPN „blokkolja az UDP-t“, és ez a mondat két teljesen különböző állítást rejt. Az egyik arról a szállításról szól, amelyet a hozzáférési hálózat lát, a másik egy alkalmazás csomagjairól, miután azokat a tunnelben visszafejtették. Egy titkosított tunnel kívülről, kulcs nélkül is szűrhető, és egy belső UDP-alkalmazás olyan okokból is meghiúsulhat, amelyeknek semmi közük a szűréshez. Döntse el, melyik állítást vizsgálja, mielőtt bizonyítékot gyűjt.

Két fejléc, egy szó

Egy NAT-traversalos IPsec-telepítésben a külső csomag UDP, amely a két VPN-végpont között van címezve, jellemzően a 4500-as porton. Ezen belül a titkosított hasznos teher mindent szállít, amit a tunnel továbbít, és ez maga is lehet TCP vagy UDP. Az UDP szó tehát kétszer jelenik meg, eltérő jelentéssel és eltérő láthatósággal.

Egy köztes hálózat a külső fejlécet látja, a belsőből semmit. Engedélyezheti, formálhatja vagy eldobhatja a külső folyamot, és ehhez nem kell semmit visszafejtenie. Ez az aszimmetria a teljes oka annak, hogy a két állítás összekeveredik: ugyanaz a szó írja le azt, amit a hálózat szűr, és azt, amit az alkalmazás küld. Ha megállapítást rögzít, írja oda a szó mellé a réteget, és a zavar nagyrészt eltűnik.

A belső fejléc csak a fogadó végponton, a visszafejtés után válik láthatóvá. Attól a ponttól a csomag úgy továbbítódik, mint bármely más, az útvonalaknak, a szabályzatnak és a végpont saját szűrésének alávetve. Ezeket különböző eszközök hozzák meg, külön döntésekként.

Mit lát még a hálózat

A titkosítás a hasznos terhet és a belső szállítási fejlécet rejti el, nem azt a tényt, hogy létezik folyam. A végpontok címei, a portok, a csomagméretek és az időzítés látható marad, és ez elég ahhoz, hogy a forgalmat heurisztikusan osztályozzák vagy egy adott célt blokkoljanak.

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

Az első rögzítés a külső folyamot mutatja a fizikai interfészen, a második a belső folyamot a tunnel interfészén. Mindkettő egyidejű futtatása közvetlenül megválaszolja a kérdést: ha a külső folyam létezik és a belső nem, az alkalmazás soha nem küldött semmit a tunnelbe. Ha mindkettő létezik és semmi nem jön vissza, a probléma a tunnelen túl van, a célnál vagy a visszaúton.

RFC 3948 határozza meg a külső UDP-burkolást, az ESP-specifikáció pedig a benne lévő védett elrendezést. Egyik dokumentum sem ígéri, hogy a hozzáférési hálózat átengedi a külső folyamot, ezért érdemes a külső négyesen elvégezni egy elérhetőségi próbát, mielőtt bármilyen elmélete lenne a belsőről. Egy blokkolt külső négyes olyan tunnelt eredményez, amely soha nem jön létre, nem olyat, amely létrejön, majd elveszít egy alkalmazást.

Miért hiúsul meg egy UDP-alkalmazás egy működő tunnelben

A tunnelnak, amely webes alkalmazást szállít, de UDP-alkalmazást nem, több valószínű magyarázata van, és a belső protokoll ISP általi szűrése nem az első. A leggyakoribb a lefedettség: a két alkalmazás nem jut be ugyanabba a tunnelbe, mert hiányzik az útvonal az UDP-célhoz, vagy az ügyfél osztott tunnel szabályai kizárják.

A második a végpont. Egy VPN-kiszolgáló, amely protokollistát engedélyez, egy céloldali tűzfal, vagy egy szolgáltatás, amely soha nem figyel a várt porton, mindegyik olyan időtúllépést okoz, amely pontosan úgy néz ki, mint egy hálózati blokk.

A harmadik a csomagméret. Az UDP-alkalmazások gyakran nagyobb datagramokat küldenek, mint egy webes kérés, a burkolás pedig csökkenti a használható MTU-t, így egy sikeres kézfogás után csend következhet az első teljes méretű hasznos tehernél. Ezt a mintát könnyű blokként félreolvasni, mert a kis csomagok átjutnak, a nagyok pedig eltűnnek. Egy gyors MTU-próba egy percen belül eldönti, és a válasz általában kisebb hasznos teher vagy javított MSS, nem hálózati szűrő.

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

Az első parancs azt vizsgálja, hogy egy nagy csomag túléli-e az útvonalat kikapcsolt töredezettség mellett, ami gyorsan feltárja az MTU-problémát. A második egy kicsi, korlátozott UDP-folyamot küld, és jelent a veszteségről és a jitterről. Az a folyam, amely elindul, majd megakad, a méretre utal, nem egy blokkra.

A réteget jelentse, ne a protokollt

Írja le a megállapítást három forma egyikében: a külső kézbesítés meghiúsult, a belső továbbítás meghiúsult, vagy az alkalmazás hiúsult meg. Mindegyiknek más a felelőse, és összekeverésük rossz csapathoz küldi a jegyet.

Egy helyi port megváltoztatása nem tud megfelelő figyelőt létrehozni a távoli végén, ezért az ügyféloldali kerülőút, amely segíteni látszik, általában annak bizonyítéka, hogy az eredeti cél hibás volt. Hasonlóképpen egy szolgáltatott alternatív profil valamit bizonyít az elérhetőségről, és semmit arról, hogy az alkalmazás megfelelően van-e beállítva.

Tartsa külön a következtetést a megfigyeléstől. A forgalomelemzés visszafejtés nélkül is sejtetheti, mi egy folyam, és ez hasznos megállapítás, de nem ugyanaz az állítás, mint a belső fejléc elolvasása. Mondja meg, melyik van valóban a kezében.