SOCKS5 proxy OpenVPN-hez: TCP-alagút vagy az alkalmazások proxizása?

Azok a hálózatok, amelyek csak proxyn keresztüli kimenő forgalmat engednek, azok, ahol egy működő profil hirtelen meghal. A proxy címe a legkevésbé érdekes változó ebben a hibában. Mindent a forgalom alakja dönt el, amit a proxy továbbítani fog, mert ezek a proxyk bájtfolyamot továbbítanak, és az UDP-alagút nem az. Ez két architektúrát hagy, és ezek különböző helyeken törnek el.

Egy korlát dönti el a tervet

A SOCKS5 valóban meghatároz egy UDP-társítási módot. Az OpenVPN-kliens proxy-támogatása mégis folyamok köré épül: socks-proxy TCP-profilokhoz van dokumentálva, és a HTTP CONNECT proxy-nak egyáltalán nincs datagram-útvonala. Egy sor dokumentáció eldönti az architektúrát, mielőtt hozzányúlna egy konfigurációs fájlhoz.

A kérdés tehát nem az, melyik proxyt válassza. Hanem hogy az alagút folyammá válik-e, vagy datagram marad, és valami más nyeli el a proxizást.

A lehetőség: tegye az alagutat folyammá

Ehhez TCP-figyelővel rendelkező szerver és a proxyt megnevező kliensprofil kell. Mindkét darab szükséges, és a szerveroldal az, amit az emberek elfelejtenek:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Cserélje ki az utolsó sort erre: http-proxy proxy.internal 8080, amikor a proxy HTTP-t beszél, és adjon hozzá hitelesítőadat-fájlt, ha ilyet kér. A proxynak hajlandónak kell lennie CONNECT-et végrehajtani a VPN-portjára, a szervernek pedig TCP-n kell válaszolnia; a csak UDP-t figyelő figyelmen kívül hagyja a kísérletet. A 443 választása gyakorlati lépés, mert sok korlátozó hálózat engedi ezt és kevés mást.

Az ár a TCP a TCP tetején. Egy elveszett külső szegmens minden belső folyamot megakaszt, amely ezt a kapcsolatot megosztja, így a helyreállítás, amely egyébként független lenne, megosztottá válik. A beállítás is tovább tart, és egy ingatag külső útvonal ingatag alagúttá válik lassú helyett.

B lehetőség: hagyja békén az alagutat

Amikor az alagútnak UDP-n kell maradnia, nem az alagút az a hely, ahol bármit beállít. Ehelyett az alkalmazások kimenő TCP-je egy helyi SOCKS-figyelőre irányul, és az alkalmazások soha nem tudják meg, hogy létezik proxy. Linuxon ez általában redsocks plusz egy NAT REDIRECT szabály a nat táblában.

Megint csak TCP. Egy csak HTTP-s proxy, mint a privoxy, nem tud tetszőleges protokollokat továbbítani, és ez a terv az alkalmazásoknak sem ad datagram-támogatást.

Ha minden alkalmazásnak közvetlenül elmondjuk a proxyt, az általában jobb ott, ahol a szoftver támogatja. Könnyebb auditálni, és olyan helyen bukik el, amit tényleg lát.

Hol bukik el az egyes lehetőségek

Az A lehetőség akkor bukik el, ha a szervernek nincs TCP-figyelője, ha a proxy elutasítja a CONNECT-célt, vagy ha a külső folyamot a szükséges alá szorítják. Az első kettő bejegyzést hagy a proxy naplójában; a harmadik olyan kapcsolatot hagy, amely létrejön, majd rossznak tűnik. Olvassa el azt a naplót, mielőtt szerkeszti a profil, mert elválasztja az engedélyproblémát a kapacitásproblémától. Egy befejezett CONNECT az alagút belsejébe viszi a vizsgálatot.

A B lehetőség mindenre elbukik, aminek datagramok kellenek, azokra a protokollokra, amelyeket a proxy nem ért, és csendben azokon a gazdagépeken, ahol az átirányítási szabály létezik, de az útválasztás elkerüli a forgalmat.

Egyik lehetőség sem változtat az eszközkövetelményen. A csomagoknak továbbra is kell TUN- vagy TAP-csomópont, mielőtt a kernel továbbítja őket, tehát a folyamatnak továbbra is engedély kell a /dev/net/tun fájlra. Egy burkoló azt változtatja meg, ami a csomópont megnyitása után történik, nem azt, hogy szüksége van-e rá.

Bizonyítsa, melyik utat építette

Nézze a socketeket, ne a tálcai ikont. A VPN-folyamatnak fenn kell tartania egy létrejött kapcsolatot a proxy címével, és a proxynak naplóznia kellett a célt, ahová el kellett jutnia:

ss -tnp | grep openvpn

Ezután keressen olyan célt, amelyet csak az alagút tud kiszolgálni, és olyan nevet, amelyre csak az alagút névfeloldója tud válaszolni. Egy befejezett proxykapcsolat halott alagúttal általában azt jelenti, hogy a távoli vég soha nem kínálta a profiljában megnevezett átvitelt.

Jegyezze fel az átvitelt és az elfogadó proxyt egy tartós helyre. Amikor ugyanaz a profil egy másik hálózaton elbukik, ez a feljegyzés másodpercek alatt kizárja vagy megerősíti a proxyt.