OpenVPN përmes SOCKS5: përputhja e versionit, transportit dhe DNS

Një rrugë daljeje nga kjo stacion pune është një proxy SOCKS, dhe OpenVPN pas tij raporton skadim të kohës së lidhjes pa asnjë detaj të dobishëm. Shfletuesi në të njëjtën makinë punon përmes atij proxy, kredencialet janë të sakta dhe porta përgjigjet. Tri gjëra ndryshojnë mjaft shpesh sa për t'i kontrolluar të parat: versioni i SOCKS që flet proxy-i, transporti që zgjodhi klienti dhe vendi ku ndodh zgjidhja e emrave. Konfirmoni secilin para se të fajësoni murin e zjarrit.

Përputhni versionin e SOCKS para murit të zjarrit

OpenVPN i komunitetit flet SOCKS5 për socks-proxy. Drejtojeni në një proxy që ofron vetëm SOCKS4 dhe lidhja TCP hapet, pastaj ngec, sepse klienti pret përgjigje për një përshëndetje që pala tjetër nuk e analizon kurrë. Nga jashtë, ky ngecje duket saktësisht si portë e filtruar, prandaj çështja e versionit vjen para çdo rregulli të murit të zjarrit. Një tërheqje me njohuri SOCKS e zgjidh me një komandë.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Një kërkesë e përfunduar vërteton dy gjëra njëherësh: proxy-i pranoi kërkesën SOCKS dhe e zgjidhi emrin. Nuk nevojitet skemë URL, sepse curl e trajton hostin e zhveshur si HTTP, dhe kjo mjafton për këtë provë.

Ajo tërheqje përjashton edhe dështimin që fsheh regjistri i klientit. Proxy-i mund të lejojë shfletuesin dhe prapë të refuzojë destinacionin VPN, dhe atëherë refuzimi ndodh në CONNECT, para çdo vërtetimi VPN. OpenVPN raporton vetëm skadimin e kohës, prandaj përgjigjja e vetë proxy-t është prova që ju nevojitet.

Transporti duhet të jetë TCP në të dyja anët

Këtu SOCKS5 mbart një rrjedhë TCP, prandaj vetë tuneli kërkon proto tcp-client. Një profil që është ende në UDP nuk do të punojë në këtë rrugë, sepse klienti nuk e përdor modalitetin e shoqërimit UDP të protokollit. Kthimi i profilit është ndryshim i vërtetë, jo formalitet: pala e largët duhet të dëgjojë TCP në të njëjtën portë. Pastaj ngarkesa bëhet TCP brenda TCP, ku segmenti i humbur ridërgohet dy herë dhe ritmi përkeqësohet, gjë që sesionet interaktive e ndiejnë shumë më shumë se transferimet e mëdha.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Kjo direktivë merr hostin e proxy-t, një portë opsionale dhe një skedar opsional kredencialesh. Vendosini në vetë profilin, që një kopje diku tjetër të sillet njësoj.

Mbyllni të gjithë zinxhirin në një kontejner

Të bësh zinxhirin në host do të thotë të marrësh rrugën e tij të paracaktuar dhe ta lësh zgjidhësin në një gjendje që askush nuk do ta shpjegojë më vonë. Një hapësirë emrash ose një kontejner e kufizon në vend të kësaj, kështu që hosti mban rrugën e vet, ndërsa hapi SOCKS dhe tuneli jetojnë bashkë. Brenda nuk ngrihet asgjë pa një pajisje tuneli, të drejta për konfigurimin e saj dhe një proxy të arritshëm. Një shërbim Compose e merr këtë me cap_add: NET_ADMIN dhe /dev/net/tun të montuar me bind.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Ky çift është më i ngushtë se sa të ekzekutosh kontejnerin me privilegje të plota, dhe është i gjithë aksesi i nevojshëm në pajisje. Një klient Tor ose një kontejner i veçantë proxy mund të furnizojë dëgjuesin. Në të dyja rastet lidheni me loopback dhe arrini tek ai nga hapësira e emrave përmes hostit, në vend që ta ekspozoni proxy-n në rrjet.

Zgjidhja e emrave është vendi ku izolimi dështon

Një tunel që mbart paketa dhe njëkohësisht pyet zgjidhësin e hostit nuk izoloi asgjë. Dy gjëra e bëjnë izolimin të vërtetë: hapësira e emrave ka zgjidhësin e vet dhe kërkesat e tij kalojnë përmes proxy-t ose tunelit, kurrë përmes ndërfaqes fizike. Për provën përdorni dy emra: një që ekziston vetëm pas tunelit dhe një publik që duhet të ndjekë të njëjtën rrugë.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Nëse emri i largët zgjidhet dhe ai publik jo, zinxhiri është selektiv, jo i thyer, dhe ndryshimi ju tregon se cilën rrugë ndoqi çdo kërkesë. Nëse të dy zgjidhen nga hosti por asnjë brenda kontejnerit, kontejneri ende huazon zgjidhësin e hostit. Regjistroni skedarin e zgjidhësit që gjetët, sepse ai është konfigurimi që duhet ndryshuar.

Provoni çdo hap sipas radhës

Lista është e shkurtër. Një kërkesë SOCKS5 merr përgjigje, tuneli arrin dëgjuesin e vet përmes proxy-t dhe paketat që dalin nga hapësira e emrave mbartin adresën që pret pala e largët. Konfirmoni një nga një, në vend që të shtoni më shumë konfigurim. Kur klienti thotë i lidhur dhe asgjë nuk lëviz, thyerja është pothuajse gjithmonë në faktin e dytë ose të tretë.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

Shkruani kombinimin që funksionoi: versioni i SOCKS, transporti, zgjidhësi dhe konfigurimet e hapësirës së emrave. Zgjidhja e këtij zinxhiri herën e dytë nga kujtesa kushton më shumë se shënimi. Mbajini ato katër fakte në biletë, jo në bisedë.

Një zinxhir që raporton i lidhur dhe nuk kalon asgjë zakonisht ka dështuar në hapin që nuk e keni provuar ende. Provoni atë hap para se të shtoni një shtresë tjetër.