OpenVPN ба SOCKS5: хувилбар, тээвэр, DNS-ийг тохируулах

SOCKS гинжин холбоо нь проксигийн хувилбар, тээвэр эсвэл DNS зам зөрүүтэй үед бүтэлгүйтдэг. SOCKS5-ыг тааруулж, TCP-оор зөөж, гинжийг нэг нэрийн орон зайд байлгаарай.

Энэ ажлын станцаас гарах нэг зам нь SOCKS прокси бөгөөд түүний ард байгаа OpenVPN нь ямар ч хэрэгтэй мэдээлэлгүйгээр холболтын хугацаа дууссан гэж мэдээлдэг. Ижил машины хөтөч тэр проксигоор ажиллаж, итгэмжлэл зөв, порт хариулдаг. Гурван зүйл эхэлж шалгах хангалттай олон удаа зөрдөг: проксигийн ярьдаг SOCKS хувилбар, клиент сонгосон тээвэр, мөн нэрийг шийдвэрлэх газар. Галт ханыг буруутгахаас өмнө тус бүрийг баталгаажуулаарай.

Галт ханаас өмнө SOCKS хувилбарыг тааруул

Нийгэмлэгийн OpenVPN нь socks-proxy-д SOCKS5 ярьдаг. Зөвхөн SOCKS4 санал болгодог прокси руу чиглүүлбэл TCP холболт нээгдээд дараа нь гацдаг, учир нь клиент нөгөө тал хэзээ ч задлан шинжлэхгүй мэндчилгээний хариуг хүлээж байна. Гаднаас харахад энэ гацалт шүүгдсэн порттой яг адилхан харагддаг тул хувилбарын асуулт аливаа галт хананы дүрмээс өмнө ирдэг. SOCKS мэддэг нэг татлага үүнийг нэг командаар шийддэг.

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

Биелэгдсэн хүсэлт хоёр зүйлийг нэгэн зэрэг батална: прокси SOCKS хүсэлтийг хүлээн авч, нэрийг шийдвэрлэсэн. URL схем шаардлагагүй, учир нь curl нүцгэн хост-ыг HTTP гэж үздэг бөгөөд энэ туршилтад хангалттай.

Тэр татлага нь клиентийн бүртгэл нуудаг алдааг ч хасдаг. Прокси хөтчийг зөвшөөрөөд VPN-ийн очих газрыг татгалзаж болох бөгөөд тэгвэл татгалзал CONNECT дээр, ямар ч VPN баталгаажуулалтаас өмнө болдог. OpenVPN зөвхөн хугацаа дууссаныг мэдээлдэг тул проксигийн өөрийн хариу л танд хэрэгтэй нотолгоо юм.

Тээвэр хоёр талдаа TCP байх ёстой

Энд SOCKS5 нь TCP урсгал зөөдөг тул туннель өөрөө proto tcp-client шаардана. UDP дээр хэвээр тохируулсан профайл энэ замаар ажиллахгүй, учир нь клиент протоколын UDP холбооны горимыг ашигладаггүй. Профайлыг эргүүлэх нь жинхэнэ өөрчлөлт, ёслол биш: холын тал ижил порт дээр TCP сонсох ёстой. Дараа нь ачаалал TCP доторх TCP болж, алдагдсан сегмент хоёр удаа дахин илгээгдэж, хурд мууддаг бөгөөд үүнийг интерактив сессүүд том дамжуулалтаас хамаагүй илүү мэдэрдэг.

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

Энэ заавар нь проксигийн хост, сонголтот порт, сонголтот итгэмжлэлийн файлыг авдаг. Тэдгээрийг профайл дотор нь тавьж, өөр газар байрлуулсан хуулбар ижил ажиллана.

Бүх гинжийг нэг контейнерт хорь

Гинжийг хост дээр хийх нь түүний өгөгдмөл замыг эзэлж, шийдвэрлэгчийг дараа нь хэн ч тайлбарлаж чадахгүй байдалд үлдээх гэсэн үг. Харин нэрийн орон зай эсвэл контейнер үүнийг хязгаарладаг тул хост өөрийн замаа хадгалж, SOCKS алхам ба туннель хамт амьдардаг. Дотор нь туннелийн төхөөрөмж, түүнийг тохируулах эрх, хүрч болох проксигүйгээр юу ч босохгүй. Compose үйлчилгээ үүнийг cap_add: NET_ADMIN ба bind-холбосон /dev/net/tun-оор авдаг.

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

Энэ хос нь контейнерийг privileged горимд ажиллуулахаас нарийн бөгөөд төхөөрөмжид хандах бүх шаардлагатай хэсэг нь энэ. Tor клиент эсвэл тусдаа прокси контейнер сонсогчийг өгч чадна. Аль ч тохиолдолд түүнийг loopback-д холбож, проксийг сүлжээнд ил гаргахын оронд нэрийн орон зайгаас хост-оор дамжин хүрээрэй.

Нэрийн шийдвэрлэлт бол тусгаарлалт бүтэлгүйтдэг газар

Пакет зөөж байхдаа хост-ын шийдвэрлэгчээс асуудаг туннель юу ч тусгаарлаагүй. Хоёр зүйл тусгаарлалтыг жинхэнэ болгодог: нэрийн орон зай өөрийн шийдвэрлэгчтэй байх, мөн түүний асуултууд прокси эсвэл туннелээр дамжиж, хэзээ ч физик интерфэйсээр дамжихгүй байх. Туршилтад хоёр нэр хэрэглээрэй: нэг нь зөвхөн туннелийн ард оршдог, нөгөө нь мөн замаар явах ёстой нийтийн нэр.

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

Холын нэр шийдвэрлэгдэж, нийтийн нэр шийдвэрлэгдэхгүй бол гинж нь эвдэрсэн биш, сонгомол бөгөөд ялгаа нь асуулт бүр ямар зам явсныг хэлнэ. Хоёулаа хост-оос шийдвэрлэгдэх боловч контейнер дотор аль нь ч шийдвэрлэгдэхгүй бол контейнер хост-ын шийдвэрлэгчийг зээлсээр байна. Олдсон шийдвэрлэгчийн файлыг тэмдэглээрэй, учир нь өөрчлөх ёстой тохиргоо нь тэр.

Алхам бүрийг дарааллаар нь батал

Жагсаалт богино. SOCKS5 хүсэлт хариу авч, туннель проксигоор дамжин сонсогчдоо хүрч, нэрийн орон зайгаас гарсан пакетууд холын талын хүлээж буй хаягийг зөөдөг. Илүү их тохиргоо нэмэхийн оронд нэг бүрийг тусад нь баталгаажуулаарай. Клиент холбогдсон гэж хэлэхэд юу ч хөдлөхгүй бол тасралт бараг үргэлж хоёр дахь эсвэл гурав дахь баримтад байдаг.

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

Ажилласан хослолыг бичээрэй: SOCKS хувилбар, тээвэр, шийдвэрлэгч, нэрийн орон зайн тохиргоо. Энэ гинжийг хоёр дахь удаа ойгоос бодох нь тэмдэглэлээс үнэтэй. Тэр дөрвөн баримтыг тасалбарт хадгал, чатын хэлхээнд биш.

Холбогдсон гэж мэдээлээд юу ч дамжуулдаггүй гинж нь ихэвчлэн таны батлаагүй алхал дээр бүтэлгүйтсэн байдаг. Дараагийн давхарга нэмэхийн өмнө тэр алхмыг туршаарай.

Холбоотой нийтлэлүүд