OpenVPN-д зориулсан SOCKS5 прокси: TCP туннель эсвэл аппуудыг проксилох уу?

Зөвхөн проксигоор гарц нээсэн сүлжээнүүд бол ажиллаж байсан профайл гэнэт үхдэг газар юм. Прокси хаяг нь тэр бүтэлгүйтэл дэх хамгийн бага сонирхолтой хувьсагч. Бүгдийг прокси дамжуулах траффикийн хэлбэр шийддэг, учир нь эдгээр прокси байтын урсгал дамжуулдаг ба UDP туннель тийм биш. Энэ нь хоёр архитектур үлдээж, тэд өөр өөр газарт эвдэрдэг.

Загварыг нэг хязгаарлалт шийддэг

SOCKS5 үнэхээр UDP холбооны горимыг тодорхойлдог. Гэсэн хэдий ч OpenVPN клиентийн прокси дэмжлэг нь урсгалын эргэн тойронд бүтээгдсэн: socks-proxy нь TCP профайлуудад зориулж баримтжуулсан бөгөөд HTTP CONNECT проксид датаграмд явах зам огт байхгүй. Баримт бичгийн нэг мөр нь тохиргооны файлд хүрэхээс өмнө архитектурыг шийддэг.

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

А хувилбар: туннелийг урсгал болгох

Үүнд TCP сонсогчтой сервер, проксийг нэрлэсэн клиент профайл хэрэгтэй. Хоёр хэсэг нь шаардлагатай бөгөөд хүмүүсийн мартдаг нь серверийн тал юм:

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

Сүүлийн мөрийг http-proxy proxy.internal 8080 гэж сольж, прокси HTTP ярьдаг бол нэвтрэх мэдээллийн файл нэмнэ үү. Прокси таны VPN порт руу CONNECT хийхэд бэлэн байх ёстой, сервер TCP дээр хариулах ёстой; зөвхөн UDP сонсогч энэ оролдлогыг үл тоомсорлодог. 443-ыг сонгох нь практик алхам, учир нь олон хязгаарлагдмал сүлжээ үүнийг болон өөр бага зүйлийг зөвшөөрдөг.

Өртөг нь TCP-г TCP дээр давхарлах явдал. Гадагш нэг алдагдсан сегмент тэр холболтыг хуваалцдаг бүх дотоод урсгалыг саатуулдаг тул ихэвчлэн бие даасан байх сэргэлт хуваалцсан болно. Тохируулга нь бас илүү удаан үргэлжилдэг бөгөөд тогтворгүй гадаад зам удаан биш, тогтворгүй туннель болдог.

Б хувилбар: туннелийг ганцааранг нь орхих

Туннель UDP дээр үлдэх ёстой бол туннель нь ямар нэгэн зүйл тохируулах газар биш. Оронд нь аппуудаас гарч буй TCP локал SOCKS сонсогч руу дахин чиглүүлэгдэж, аппууд прокси байгааг хэзээ ч мэдэхгүй. Linux дээр энэ нь ихэвчлэн redsocks бөгөөд nat хүснэгтэд NAT REDIRECT дүрэм нэмэгддэг.

Дахин зөвхөн TCP. privoxy шиг зөвхөн HTTP прокси нь дурын протокол дамжуулж чадахгүй бөгөөд энэ загвар нь аппуудад датаграмын дэмжлэг нэмдэггүй.

Програм хангамж дэмждэг газарт апп бүрт проксиг шууд хэлэх нь ихэвчлэн дээр. Аудиталт хийхэд хялбар бөгөөд таны үнэхээр харж чадах газарт бүтэлгүйтдэг.

Хувилбар бүр хаана бүтэлгүйтдэг

А хувилбар нь серверт TCP сонсогч байхгүй үед, прокси CONNECT зорилтыг татгалзах үед, эсвэл гадаад урсгал туннельд хэрэгтэй хэмжээнээс доош хязгаарлагдах үед бүтэлгүйтдэг. Эхний хоёр нь прокси логт бичлэг үлдээдэг; гурав дахь нь холбогдож, дараа нь буруу мэт санагдах холболт үлдээдэг. Профайлыг засахын өмнө тэр логыг уншина уу, учир нь энэ нь зөвшөөрлийн асуудлыг багтаамжийн асуудлаас ялгадаг. Дууссан CONNECT нь мөрдөн байцаалтыг туннелийн дотор зөөдөг.

Б хувилбар нь датаграм шаарддаг бүх зүйлд, прокси ойлгодоггүй протоколуудад, мөн дахин чиглүүлэлтийн дүрэм байгаа ч маршрутлалт траффикийг хажуугаар нь илгээдэг хостуудад чимээгүйхэн бүтэлгүйтдэг.

Аль ч хувилбар төхөөрөмжийн шаардлагыг өөрчлөхгүй. Пакетуудад цөм маршрутлахаас өмнө TUN эсвэл TAP зангилаа хэрэгтэй хэвээр, тиймээс процесс /dev/net/tun дээр зөвшөөрөл шаарддаг хэвээр. Бүрхүүл нь тэр зангилаа нээгдсэний дараа юу болохыг өөрчилдөг, танд хэрэгтэй эсэхийг биш.

Ямар зам барьснаа батлаарай

Тавиурын дүрс биш, сокетуудыг хар. VPN процесс прокси хаяг руу тогтоосон холболтыг барих ёстой, прокси нь хүрэхийг хүссэн зорилтыг логт бичсэн байх ёстой:

ss -tnp | grep openvpn

Дараа нь зөвхөн туннель үйлчилж чадах очих газар руу, мөн зөвхөн туннелийн шийдэгч хариулж чадах нэр рүү чиглээрэй. Үхсэн туннельтай дууссан прокси холболт нь ихэвчлэн алслагдсан тал таны профайлд нэрлэсэн тээврийг хэзээ ч санал болгоогүй гэсэн үг.

Тээвэр болон хүлээн авагч проксийг бат бөх газарт тэмдэглэ. Ижил профайл өөр сүлжээнд бүтэлгүйтэх үед тэр тэмдэглэл хэдхэн секундэд проксийг хасаж эсвэл баталгаажуулна.