Redsocks loopback дээр сонсож байна, гэхдээ VPN трафик хэзээ ч ирэхгүй

Туннель босч, клиент гарц руу ping хийж чадах боловч прокси замаар явсан бүх вэб хүсэлт үхдэг. redsocks процесс ажиллаж, порт нь сонсож байгаа тул үйлчилгээ нь гарцаас өөрөөс нь эрүүл харагдана. Бүтэлгүйтдэг зүйл бол хүргэлтийн алхам: туннелээс дамжуулсан пакет таны эхлүүлсэн socket дээр буухгүй. Холболтын хаяг болон дамжуулалтын зорилт тохирох ёстой бөгөөд ихэвчлэн зөвхөн нэгийг нь шалгадаг.

Дамжуулсан пакет үнэндээ хаана буудаг вэ

Гарц дээрх тунгалаг прокси PREROUTING дахь nat хүснэгтийн REDIRECT-ийг ашиглан ирж буй холболтын очих газрыг локал порт руу дахин бичдэг. Дахин бичсэн очих газар нь пакет ирсэн интерфейсээс харагдах локал хаяг бөгөөд өөр газар эхлүүлсэн процессын loopback хаяг биш юм. Зөвхөн 127.0.0.1-д холбогдсон сонсогч хост дээр аль хэдийн локал байсан холболтыг хүлээн авдаг бөгөөд туннелийн трафик бүтэлгүйтэх үед үргэлжлүүлэн ажилладаг тохиолдол яг энэ юм. Клиентийн өөрийн loopback нь гурав дахь хаяг бөгөөд хэзээ ч гарцын дүрмийн зорилт болдоггүй.

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

Сонсогч ба дамжуулалтын дүрмийг хамт уншина уу

Socket хүснэгт болон nat дүрмүүдийг нэг дамжуулалтад хэвлэнэ үү, учир нь хэн ч эзэмшдэггүй порт руу заасан дүрэм буруу хаяг руу заасан дүрэмтэй яг адил харагдана. sudo ss -ltnp | grep redsocks холболтын хаяг болон эзэмшигч процессыг харуулна. sudo iptables -t nat -S PREROUTING REDIRECT зорилтыг харуулна, sudo iptables -t nat -L PREROUTING -v -n түүнд ямар нэгэн зүйл тохирсон эсэхийг харуулна.

REDSOCKS нэртэй хэрэглэгчийн гинжид үсрэх нь тухайн гинж байхгүй бөгөөд зориудын үл хамаарах зүйлс болон REDIRECT үйлдлийг агуулаагүй бол юу ч бүтээхгүй. Нэр нь ажлыг хийнэ гэж таамаглахын оронд түүний үсрэх гинжийг sudo iptables -t nat -S REDSOCKS-аар уншина уу.

Дараа нь хоёр утгыг харьцуулна уу. Хэрэв дүрэм 12345 порт дээрх гарцын хаяг руу дамжуулж, сонсогч 127.0.0.1:12345 гэж мэдээлбэл, зөрүү нь бүтэлгүйтлийг нэмэлт оношилгоогүйгээр тайлбарлана.

Нарийн холбоод, дараа нь юу хүрч болохыг хязгаарлана уу

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

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

Клиентээс шинэ холболтоор нотлоорой

Гарц дээрх shell-ээс биш, бодит VPN клиентээс шинэ TCP холболтоор шалгана уу. Клиент дээрх curl -sS -o /dev/null -w '%{http_code}\n' http://example.com нь дамжуулсан замыг эхнээс нь дуустал нь гүйцэтгэдэг.

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

Эцэст нь энэ зам юуг хамардаггүйг санаарай. Энгийн redsocks TCP дамжуулалт нь UDP, QUIC эсвэл DNS-ийг SOCKS трафик болгохгүй бөгөөд хувийн очих газрууд ихэвчлэн тодорхой үл хамаарах зүйлс шаарддаг. Амжилттай локал туршилт нь хэзээ ч асуудал байгаагүй loopback замыг л нотолдог.