Proxy SOCKS5 za OpenVPN: tunel TCP ali proxy za aplikacije?

Omrežja, ki dovolijo izhod samo prek proxyja, so kraj, kjer delujoč profil nenadoma umre. Naslov proxyja je najmanj zanimiva spremenljivka pri tej okvari. Vse odloči oblika prometa, ki ga bo proxy posredoval, ker ti proxyji prenašajo bajtni tok, tunel UDP pa to ni. Ostaneta dve arhitekturi in se lomita na različnih mestih.

Ena omejitev odloči zasnovo

SOCKS5 res določa način pridružitve UDP. Podpora proxyja v odjemalcu OpenVPN je kljub temu zgrajena okoli tokov: socks-proxy je dokumentiran za profile TCP, proxy HTTP CONNECT pa nima nobene poti za datagrame. Ena vrstica dokumentacije razreši arhitekturo, preden se dotaknete konfiguracijske datoteke.

Vprašanje torej ni, kateri proxy izbrati. Je, ali tunel postane tok ali ostane datagram in prepusti posredovanje nečemu drugemu.

Možnost A: spremenite tunel v tok

Za to potrebujete strežnik s poslušalcem TCP in odjemalski profil, ki imenuje proxy. Oba dela sta potrebna, strežniška stran pa je tista, ki jo ljudje pozabijo:

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

Zamenjajte zadnjo vrstico z http-proxy proxy.internal 8080, ko proxy govori HTTP, in dodajte datoteko s poverilnicami, če jo zahteva. Proxy mora biti pripravljen izvesti CONNECT na vaša vrata VPN, strežnik pa mora odgovoriti na TCP; poslušalec samo za UDP ta poskus prezre. Izbira 443 je praktična poteza, ker veliko omejevalnih omrežij dovoli to in malo drugega.

Cena je TCP, zložen na TCP. En izgubljen zunanji segment ustavi vsak notranji tok, ki si deli to povezavo, zato okrevanje, ki bi bilo sicer neodvisno, postane skupno. Nastavitev traja dlje, nestabilna zunanja pot pa postane nestabilen tunel namesto počasnega.

Možnost B: pustite tunel pri miru

Ko mora tunel ostati na UDP, tunel ni kraj, kjer kar koli nastavljate. Namesto tega se izhodni TCP iz aplikacij preusmeri na lokalni poslušalec SOCKS in aplikacije nikoli ne izvedo, da proxy obstaja. V Linuxu je to običajno redsocks skupaj s pravilom NAT REDIRECT v tabeli nat.

Spet samo TCP. Proxy samo za HTTP, kot je privoxy, ne more posredovati poljubnih protokolov, in ta zasnova aplikacijam ne doda podpore za datagrame.

Vsaki aplikaciji povedati za proxy neposredno je običajno bolje tam, kjer programska oprema to podpira. Lažje je revidirati in odpove na mestu, ki ga res lahko vidite.

Kje vsaka možnost odpove

Možnost A odpove, ko strežniku manjka poslušalec TCP, ko proxy zavrne cilj CONNECT ali ko je zunanji tok omejen pod tisto, kar tunel potrebuje. Prva dva pustita vnos v dnevniku proxyja; tretji pusti povezavo, ki se vzpostavi in nato deluje narobe. Preberite ta dnevnik, preden uredite profil, ker loči težavo z dovoljenji od težave z zmogljivostjo. Dokončan CONNECT premakne preiskavo v notranjost tunela.

Možnost B odpove za vse, kar potrebuje datagrame, za protokole, ki jih proxy ne razume, in tiho na gostiteljih, kjer pravilo preusmeritve obstaja, a usmerjanje pošlje promet mimo njega.

Nobena možnost ne spremeni zahteve glede naprave. Paketi še vedno potrebujejo vozlišče TUN ali TAP, preden jih jedro usmeri, zato proces še vedno potrebuje dovoljenje na /dev/net/tun. Ovoj spremeni, kaj se zgodi po odprtju tega vozlišča, ne pa, ali ga potrebujete.

Dokažite, katero pot ste zgradili

Poglejte vtičnice, ne ikone v pladnju. Proces VPN mora držati vzpostavljeno povezavo z naslovom proxyja, proxy pa bi moral zabeležiti cilj, do katerega so ga prosili, naj pride:

ss -tnp | grep openvpn

Nato se odpravite do cilja, ki ga lahko služi samo tunel, in do imena, na katero lahko odgovori samo razreševalnik tunela. Dokončana povezava prek proxyja z mrtvim tunelom običajno pomeni, da oddaljena stran ni nikoli ponudila prenosa, navedenega v vašem profilu.

Zapišite prenos in proxy, ki sprejema, na trajno mesto. Ko isti profil odpove v drugem omrežju, ta zapisek v nekaj sekundah izloči ali potrdi proxy.