SOCKS5 proxy para sa OpenVPN: TCP tunnel o i-proxy ang mga app?

Ang mga network na pinapayagan lamang ang paglabas sa pamamagitan ng proxy ang lugar kung saan biglang namamatay ang gumaganang profile. Ang address ng proxy ang pinakamababa sa interes na variable sa pagkabigo na iyon. Ang lahat ay pinagpapasyahan ng hugis ng trapikong ipapasa ng proxy, dahil ang mga proxy na ito ay nagpapadala ng byte stream at ang UDP tunnel ay hindi ganoon. Nag-iiwan iyon ng dalawang arkitektura, at nasisira sila sa magkaibang lugar.

Isang hadlang ang nagpapasya sa disenyo

Totoong tinutukoy ng SOCKS5 ang isang UDP association mode. Gayunpaman, ang suporta sa proxy ng kliyenteng OpenVPN ay itinayo sa paligid ng mga stream: socks-proxy ay dokumentado para sa mga TCP profile, at ang HTTP CONNECT proxy ay walang anumang landas para sa mga datagram. Isang linya ng dokumentasyon ang nagpapasya sa arkitektura bago mo pa hipuin ang configuration file.

Kaya ang tanong ay hindi kung aling proxy ang pipiliin. Ito ay kung ang tunnel ay magiging stream, o mananatiling datagram at hayaang may ibang sumipsip ng proxying.

Opsyon A: gawing stream ang tunnel

Kailangan nito ng server na may TCP listener at client profile na nagngangalan sa proxy. Kailangan ang dalawang piraso, at ang panig ng server ang nakakalimutan ng mga tao:

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

Palitan ang huling linya ng http-proxy proxy.internal 8080 kapag nagsasalita ng HTTP ang proxy, at magdagdag ng credential file kung hinihiling nito. Kailangang pumayag ang proxy na magsagawa ng CONNECT sa iyong VPN port, at kailangang tumugon ang server sa TCP; ang listener na UDP lamang ay binabalewala ang pagtatangka. Ang pagpili ng 443 ay praktikal na hakbang, dahil maraming mahigpit na network ang pinapayagan iyon at kaunti pa.

Ang halaga ay TCP na nakapatong sa TCP. Isang nawalang panlabas na segment ang humihinto sa bawat panloob na stream na nagbabahagi ng koneksiyong iyon, kaya ang pagbangon na karaniwang malaya ay nagiging pinagsasaluhan. Mas matagal din ang pag-setup, at ang hindi matatag na panlabas na landas ay nagiging hindi matatag na tunnel sa halip na mabagal.

Opsyon B: iwanan ang tunnel

Kapag dapat manatili ang tunnel sa UDP, ang tunnel ay hindi ang lugar kung saan ka nagko-configure ng anuman. Sa halip, ang palabas na TCP mula sa mga app ay ire-redirect sa isang lokal na SOCKS listener, at hindi alam ng mga app na may proxy. Sa Linux iyon ay karaniwang redsocks kasama ang isang panuntunang NAT REDIRECT sa nat table.

TCP lang, muli. Ang proxy na HTTP lamang tulad ng privoxy ay hindi makapagpasa ng mga arbitraryong protocol, at ang disenyong ito ay hindi rin nagdadagdag ng suporta sa datagram para sa mga app.

Ang pagsasabi sa bawat app tungkol sa proxy nang direkta ay karaniwang mas mabuti kung saan sinusuportahan ito ng software. Mas madaling i-audit, at nabibigo ito sa lugar na aktuwal mong nakikita.

Saan nabibigo ang bawat opsyon

Nabibigo ang Opsyon A kapag walang TCP listener ang server, kapag tinanggihan ng proxy ang CONNECT target, o kapag ang panlabas na stream ay hinihigpitan sa mas mababa sa kailangan ng tunnel. Ang unang dalawa ay nag-iiwan ng entry sa log ng proxy; ang pangatlo ay nag-iiwan ng koneksiyong naitatag at pagkatapos ay parang mali. Basahin ang log na iyon bago i-edit ang profile, dahil hinihiwalay nito ang problema sa pahintulot mula sa problema sa kapasidad. Ang kumpletong CONNECT ay naglilipat ng imbestigasyon sa loob ng tunnel.

Nabibigo ang Opsyon B para sa anumang nangangailangan ng datagram, para sa mga protocol na hindi nauunawaan ng proxy, at tahimik sa mga host kung saan umiiral ang panuntunan ng redirect ngunit ipinapadala ng routing ang trapiko sa tabi nito.

Wala sa mga opsyon ang nagbabago sa pangangailangan ng device. Kailangan pa rin ng mga packet ng TUN o TAP node bago i-route ng kernel ang mga ito, kaya kailangan pa rin ng proseso ng pahintulot sa /dev/net/tun. Binabago ng wrapper ang nangyayari pagkatapos mabuksan ang node na iyon, hindi kung kailangan mo ito.

Patunayan kung aling landas ang itinayo mo

Tingnan ang mga socket at hindi ang tray icon. Dapat hawakan ng proseso ng VPN ang naitatag na koneksiyon sa address ng proxy, at dapat na naitala ng proxy ang target na hiniling na maabot:

ss -tnp | grep openvpn

Pagkatapos pumunta sa isang destinasyon na tanging tunnel lang ang makapaghahain, at sa isang pangalan na tanging resolver ng tunnel lang ang makasasagot. Ang kumpletong koneksiyon sa proxy na may patay na tunnel ay karaniwang nangangahulugang hindi kailanman inalok ng malayong dulo ang transport na pinangalanan sa iyong profile.

Itala ang transport at ang proxy na tumatanggap sa isang matibay na lugar. Kapag nabigo ang parehong profile sa ibang network, ibinubukod o kinukumpirma ng tala na iyon ang proxy sa loob ng ilang segundo.