Proxy SOCKS5 pentru OpenVPN: tunel TCP sau proxy pentru aplicații?

Un proxy retransmite un flux, nu un datagramă. Comparați un tunel TCP în spatele socks-proxy cu o redirecționare redsocks și vedeți unde eșuează mai întâi fiecare proiect.

Rețelele care permit ieșirea doar printr-un proxy sunt locul unde un profil care funcționa moare brusc. Adresa proxy este cea mai puțin interesantă variabilă din acea defecțiune. Totul este decis de forma traficului pe care proxy-ul îl va retransmite, pentru că aceste proxy-uri transportă un flux de octeți, iar un tunel UDP nu este așa. Rămân două arhitecturi, și se rup în locuri diferite.

O singură constrângere decide proiectul

SOCKS5 specifică într-adevăr un mod de asociere UDP. Suportul de proxy al clientului OpenVPN este totuși construit în jurul fluxurilor: socks-proxy este documentat pentru profiluri TCP, iar un proxy HTTP CONNECT nu are niciun traseu pentru datagrame. O linie de documentație lămurește arhitectura înainte să atingeți un fișier de configurare.

Așadar întrebarea nu este ce proxy să alegeți. Este dacă tunelul devine un flux sau rămâne un datagramă și lasă altceva să absoarbă proxying-ul.

Opțiunea A: transformați tunelul într-un flux

Asta cere un server cu un ascultător TCP și un profil de client care numește proxy-ul. Ambele piese sunt necesare, iar partea de server este cea pe care lumea o uită:

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

Înlocuiți ultima linie cu http-proxy proxy.internal 8080 când proxy-ul vorbește HTTP, și adăugați un fișier de acreditări dacă îl cere. Proxy-ul trebuie să accepte să execute CONNECT către portul VPN, iar serverul trebuie să răspundă pe TCP; un ascultător doar UDP ignoră încercarea. Alegerea 443 este o mișcare practică, pentru că multe rețele restrictive o permit pe ea și puțin altceva.

Costul este TCP stivuit pe TCP. Un segment exterior pierdut blochează fiecare flux interior care partajează acea conexiune, așa că recuperarea care ar fi în mod normal independentă devine partajată. Configurarea durează și ea mai mult, iar o cale exterioară instabilă devine un tunel instabil în loc de unul lent.

Opțiunea B: lăsați tunelul în pace

Când tunelul trebuie să rămână pe UDP, tunelul nu este locul unde configurați ceva. În schimb, TCP-ul de ieșire din aplicații este redirecționat către un ascultător SOCKS local, iar aplicațiile nu află niciodată că există un proxy. Pe Linux asta este de obicei redsocks plus o regulă NAT REDIRECT în tabela nat.

Din nou doar TCP. Un proxy doar HTTP precum privoxy nu poate retransmite protocoale arbitrare, iar acest proiect nu adaugă nici suport pentru datagrame pentru aplicații.

Să spui fiecărei aplicații despre proxy direct este de obicei mai bine acolo unde software-ul permite. Este mai ușor de auditat și eșuează într-un loc pe care îl puteți vedea cu adevărat.

Unde eșuează fiecare opțiune

Opțiunea A eșuează când serverului îi lipsește un ascultător TCP, când proxy-ul refuză ținta CONNECT sau când fluxul exterior este limitat sub ce are nevoie tunelul. Primele două lasă o intrare în jurnalul proxy-ului; a treia lasă o conexiune care se stabilește și apoi pare greșită. Citiți acel jurnal înainte de a edita profilul, pentru că separă o problemă de permisiuni de una de capacitate. Un CONNECT finalizat mută investigația în interiorul tunelului.

Opțiunea B eșuează pentru orice are nevoie de datagrame, pentru protocoalele pe care proxy-ul nu le înțelege și în tăcere pe gazdele unde regula de redirecționare există, dar rutarea trimite traficul pe lângă ea.

Nicio opțiune nu schimbă cerința dispozitivului. Pachetele au în continuare nevoie de un nod TUN sau TAP înainte ca nucleul să le ruteze, așa că procesul are în continuare nevoie de permisiune pe /dev/net/tun. Un înveliș schimbă ce se întâmplă după ce nodul este deschis, nu dacă aveți nevoie de el.

Dovediți ce cale ați construit

Uitați-vă la socketuri, nu la pictograma din tavă. Procesul VPN ar trebui să țină o conexiune stabilită către adresa proxy-ului, iar proxy-ul ar fi trebuit să înregistreze ținta la care i s-a cerut să ajungă:

ss -tnp | grep openvpn

Apoi mergeți către o destinație pe care doar tunelul o poate deservi și către un nume la care doar resolver-ul tunelului poate răspunde. O conexiune proxy finalizată cu un tunel mort înseamnă de obicei că capătul îndepărtat nu a oferit niciodată transportul numit în profilul dvs.

Notați transportul și proxy-ul acceptant într-un loc durabil. Când același profil eșuează într-o altă rețea, acea notă exclude sau confirmă proxy-ul în câteva secunde.

Articole similare