Proxy SOCKS5 për OpenVPN: tunel TCP apo proxy për aplikacionet?

Rrjetet që lejojnë dalje vetëm përmes një proxy janë vendi ku një profil që funksiononte vdes papritur. Adresa e proxy-t është variabli më pak interesant në atë dështim. Gjithçka vendoset nga forma e trafikut që proxy-i do të përcjellë, sepse këto proxy përcjellin një rrjedhë bajtësh dhe një tunel UDP nuk është i tillë. Kjo lë dy arkitektura, dhe ato thyhen në vende të ndryshme.

Një kufizim vendos dizajnin

SOCKS5 vërtet specifikon një modalitet shoqërimi UDP. Megjithatë, mbështetja e proxy-t të klientit OpenVPN është ndërtuar rreth rrjedhave: socks-proxy është dokumentuar për profilet TCP, dhe një proxy HTTP CONNECT nuk ka fare rrugë për datagrame. Një rresht dokumentacioni e zgjidh arkitekturën para se të prekni një skedar konfigurimi.

Pyetja pra nuk është cilin proxy të zgjidhni. Është nëse tuneli bëhet rrjedhë, apo mbetet datagram dhe lë diçka tjetër të thithë proxying-un.

Opsioni A: kthejeni tunelin në rrjedhë

Kjo kërkon një server me një dëgjues TCP dhe një profil klienti që emërton proxy-n. Të dyja pjesët janë të nevojshme, dhe ana e serverit është ajo që njerëzit harrojnë:

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

Zëvendësoni rreshtin e fundit me http-proxy proxy.internal 8080, kur proxy-i flet HTTP, dhe shtoni një skedar kredencialesh nëse e kërkon. Proxy-i duhet të jetë i gatshëm të ekzekutojë CONNECT në portin tuaj VPN, dhe serveri duhet të përgjigjet në TCP; një dëgjues vetëm UDP e injoron përpjekjen. Zgjedhja e 443 është një veprim praktik, sepse shumë rrjete kufizuese lejojnë atë dhe pak gjë tjetër.

Kostoja është TCP i grumbulluar mbi TCP. Një segment i jashtëm i humbur bllokon çdo rrjedhë të brendshme që ndan atë lidhje, kështu që rikuperimi që normalisht do të ishte i pavarur bëhet i përbashkët. Konfigurimi zgjat më shumë, dhe një rrugë e jashtme e paqëndrueshme bëhet tunel i paqëndrueshëm në vend të një tuneli të ngadaltë.

Opsioni B: lini tunelin në paqe

Kur tuneli duhet të mbetet në UDP, tuneli nuk është vendi ku konfiguroni diçka. Në vend të kësaj, TCP-ja dalëse nga aplikacionet ridrejtohet në një dëgjues lokal SOCKS, dhe aplikacionet nuk mësojnë kurrë se ekziston një proxy. Në Linux kjo është zakonisht redsocks plus një rregull NAT REDIRECT në tabelën nat.

Përsëri vetëm TCP. Një proxy vetëm HTTP si privoxy nuk mund të përcjellë protokolle arbitrare, dhe ky dizajn nuk shton as mbështetje për datagrame për aplikacionet.

T'i thuash çdo aplikacioni për proxy-n drejtpërdrejt është zakonisht më mirë aty ku softueri e mbështet. Është më e lehtë për t'u audituar, dhe dështon në një vend që mund ta shihni vërtet.

Ku dështon secili opsion

Opsioni A dështon kur serverit i mungon një dëgjues TCP, kur proxy-i refuzon objektivin CONNECT, ose kur rrjedha e jashtme kufizohet nën atë që i nevojitet tunelit. Dy të parat lënë një zë në regjistrin e proxy-t; i treti lë një lidhje që vendoset dhe më pas duket e gabuar. Lexoni atë regjistër përpara se të modifikoni profilin, sepse ndan një problem lejeje nga një problem kapaciteti. Një CONNECT i përfunduar e zhvendos hetimin brenda tunelit.

Opsioni B dështon për çdo gjë që kërkon datagrame, për protokollet që proxy-i nuk i kupton, dhe në heshtje në hostet ku rregulli i ridrejtimit ekziston, por rrugëtimi e dërgon trafikun përtej tij.

Asnjë opsion nuk e ndryshon kërkesën e pajisjes. Paketat ende kanë nevojë për një nyje TUN ose TAP përpara se kerneli t'i rrugëtojë, kështu që procesi ende ka nevojë për leje në /dev/net/tun. Një mbështjellës ndryshon atë që ndodh pasi ajo nyje është e hapur, jo nëse ju nevojitet.

Provoni cilën rrugë ndërtuat

Shikoni soketat dhe jo ikonën e tabakës. Procesi VPN duhet të mbajë një lidhje të vendosur me adresën e proxy-t, dhe proxy-i duhet të ketë regjistruar objektivin që iu kërkua të arrinte:

ss -tnp | grep openvpn

Më pas shkoni drejt një destinacioni që vetëm tuneli mund ta shërbejë, dhe drejt një emri të cilit vetëm zgjidhësi i tunelit mund t'i përgjigjet. Një lidhje proxy e përfunduar me një tunel të vdekur zakonisht do të thotë që skaji i largët nuk ofroi kurrë transportin e emërtuar në profilin tuaj.

Shënoni transportin dhe proxy-n pranuese në një vend të qëndrueshëm. Kur i njëjti profil dështon në një rrjet tjetër, ai shënim e përjashton ose konfirmon proxy-n brenda sekondave.