VPN blokkolva egy csak webes hálózaton? Dolgozza fel a rétegeket

Egy campus- vagy hotelhálózat, ahol a böngésző működik és minden alagút meghal, nem egy probléma, hanem négy egymásra rakott. Az útvonal talán csak a TCP 443-at engedi, hitelesített proxyt követel, vizsgálja a kézfogást, vagy egyszerűen szabályzattal tiltja a távoli hozzáférést. Sorrendben kezelve elkerülhető, hogy új klienst vegyen egy hálózati szabály javításához. Az alábbi útmutató körülbelül tíz percet vesz igénybe, és egy írásos válasszal zárul arról, melyik réteg utasította el.

Bizonyítsa, melyik réteg utasítja el a kapcsolatot

Ne a VPN-klienssel kezdje. Kezdje egy egyszerű HTTPS-kéréssel ugyanahhoz a gazdagéphez, és olvassa ki az időfázisokat, mert a meghiúsuló fázis megmondja, melyik eszköz a felelős:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Nincs válasz és nincs connect-idő azt jelenti, hogy a TCP soha nem fejeződött be, tehát tűzfal, proxykövetelmény vagy rossz cél van játékban. connect-idő tls-idő nélkül azt jelenti, hogy valami középen elfogadta a kapcsolatot, majd megállította a kézfogást, és pontosan így néz ki egy vizsgáló proxy a kliens oldaláról.

Most vizsgálja meg a ténylegesen kapott tanúsítványt. Ez a leggyorsabb módja annak megállapítására, hogy a szerverrel beszél-e, vagy egy köztes dobozzal, amely újra aláírta a munkamenetet:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Olvassa el a kibocsátó sorát. A saját CA azt jelenti, hogy elérte a szolgáltatást; vállalati vagy eszközkibocsátó azt jelenti, hogy egy szűrő megszüntette a kapcsolatot, és eldönti, mi történik ezután. Rögzítse mindkét kimenetet időbélyeggel, mert ugyanaz a teszt egy órával később a vendéghálózaton más választ adhat.

A proxyra figyelő kliens az első csomagot változtatja meg, nem a szabályzatot

Ha a hálózat CONNECT-et követel hitelesített proxyn keresztül, azt meg kell mondani a VPN-kliensnek, különben olyan címre próbál socketet nyitni, amelyet nem tud irányítani. Tesztelje a proxyt külön a kliensől, hogy a hiba egy magyarázatot kapjon:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Az első parancs bizonyítja, hogy a proxy viszi a célt. A második arra kéri a klienst, hogy TCP-t használjon a 443-on, ez az egyetlen szállítás, amelyet a legtöbb csak webes útvonal egyáltalán továbbít. Ha az első parancs sikerül és a második továbbra is meghiúsul, a proxy nem akadály.

Egyes kliensek az operációs rendszer proxyját olvassák felülírás helyett, mások egyiket sem. Ellenőrizze az alkalmazás saját dokumentációját, mielőtt feltételezi, hogy egy rendszerszintű beállítás érvényes. Az a kliens, amely a végpontot olyan feloldón keresztül old fel, amelyet a proxy nem szolgál ki, itt is meghiúsul, ezért tűnhet a DNS-változtatás javításnak, amikor csak kitérő.

Figyeljen a terelési mintára is. Egy szűrt hálózat válaszolhat egy szállító észlelési gazdagépnevére a sajátjával, ami megváltoztatja, melyik proxyprofilt választja a kliens. Ne építsen folyamatot erre a furcsaságra. Helyszínenként változik, előzetes értesítés nélkül változik, és nem olyasmi, amit másnak támogathat.

A 443-as port elérhető, nem engedélyezett

Az alagút TLS-be csomagolása a 443-on az elérhetőséget oldja meg, és semmi mást. A portot ellenőrző szűrő átengedi; a kézfogás ujjlenyomatát vevő szűrő nem, és a titkosított kliens helló csak akkor rejti el a kiszolgáló nevét, ha mindkét vég támogatja. Futtassa a tesztet, és derítse ki, milyen szűrő mögött van, ahelyett hogy reménykedne.

Van egy teljesítményköltség is, amelyet az emberek később fedeznek fel. Megbízható szállítás megbízható szállításon belül felerősíti a veszteséget, mert a belső verem újraküldi azokat a szegmenseket, amelyeket a külső verem már újraküldött. Tiszta kapcsolaton senki nem veszi észre. Zsúfolt campus vezeték nélküli hálózaton az alagút pontosan akkor válik használhatatlanná, amikor szüksége van rá, és a grafikon csomagvesztésnek látszik, pedig semmi nem dobódik el szándékosan.

Az UDP általában az első áldozat, és ezt érdemes megerősíteni, nem kikövetkeztetni. Ha a WireGuard vagy az alapértelmezett OpenVPN soha nem fejez be kézfogást, miközben a TCP 443 működik, a hálózat eldobja az UDP-t, és semmilyen kulcsújragenerálás nem változtat ezen:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Az üres kézfogás-időbélyeg egy tegnap működő partner mellett az UDP válasza. A két DNS-lekérdezés más kérdésre válaszol: ha a helyi feloldó és egy nyilvános feloldó nem ért egyet a végpont címében, terelik, és a szállítási érv a rossz.

Ellenőrizze, mi hagyta el valóban a gépet

A kliensnaplók azt írják le, mit hisz a kliens. A rögzítés azt írja le, mit látott a hálózat, és a kettő közötti különbség az, ahol ezeknek az eseteknek a többsége megoldódik:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Ha SYN-csomagokat lát és nincs SYN-ACK, a blokk feljebb van, és a kliens ártatlan. Ha befejezett kézfogást lát egy olyan címre, amely nem a szerveré, proxyval vagy elfogóval beszél. Ha semmit nem lát, ellenőrizze, hogy a megfelelő interfészen rögzített-e, mielőtt bármit levonna.

A socketlista finomabb esetet fog meg: egy második alagút már birtokolja az alapértelmezett útvonalat. Két kliens, amely az útválasztási tábláért harcol, időszakos hibákat okoz, amelyek pontosan blokkolt hálózatnak látszanak, és a rögzítés olyan interfészen kilépő forgalmat fog mutatni, amelyre nem számított.

Visszaállítás, és a megőrzésre érdemes jegyzet

Vonja vissza a változtatásokat a létrehozásuk fordított sorrendjében. Távolítsa el a proxyváltozókat, állítsa le a kézzel indított klienst, és távolítson el minden hozzáadott útvonal- vagy feloldó-felülírást:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Egy kézzel indított kliens futva hagyása az, ahogy egy laptop a következő irodalátogatáskor törött hálózattal végzi. A shell-profilban hagyott proxyváltozók hetekkel később független eszközöket törnek el, és aki ezeket hibakeresi, nem fogja összekötni a két eseményt.

Aztán írjon négy sort: a hálózat, az időbélyeg, a meghiúsult fázis és a látott kibocsátó. Egy campuson működő, a következőn meghiúsuló útvonal normális, és a következő embernek tudnia kell, hogy a különbség a proxy, a feloldó vagy a szűrő volt. Ha a válasz az, hogy a hálózat tiltja a távoli hozzáférést, álljon meg ott, és kérje az adminisztrátortól a támogatott útvonalat, ahelyett hogy egy kerülőutat vinne egy olvasatlan szabályzatba.