Бодлогын маршрутлалт ба SOCKS: аль давхарга трафикийг үнэхээр прокси хийдэг вэ

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

Маршрутлалт, DNAT ба SOCKS өөр өөр зүйлийг өөрчилдөг

Бодлогын маршрут 3-р давхаргын шийдвэрийг дахин бичдэг. Нэг клиентийн трафикийг сонгосон дараагийн үсрэлт рүү илгээхэд хоёр мөр хангалттай:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Үүний дараа цөм пакетыг 10.50.0.2 руу дамжуулж, анхны очих газар IP толгойд хэвээр байна. Хэрэв 10.50.0.2 нь маршрутлагч бол пакетыг дамжуулна. Хэрэв энэ нь 1080 дээр SOCKS демонтой хост бол пакет түүнийг хүлээн авах чадвартай зүйл рүү хаяглагдаагүй бөгөөд 1080 порт руу DNAT ч тусалдахгүй, учир нь хөрвүүлсэн пакет SOCKS мэндчилгээний оронд аппын анхны ачааллыг агуулснаар байна.

SOCKS5 хувилбарын байт, аргуудын жагсаалт, баталгаажуулалтын солилцоо, очих газрыг нэрлэсэн хүсэлтээр эхэлдэг. Энэ нь аппын өгөгдөл. Ямар ч маршрутлалтын бичлэг, netfilter зорилт үүнийг үүсгэдэггүй бөгөөд нэг мөрөнд харьцуулбал: маршрутлалт зам сонгодог, SOCKS серверээс хоёр дахь холболт үүсгэхийг хүсдэг.

Эхний тохиолдол: апп өөрөө SOCKS ярьж чадна

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Прокси орчны хувьсагчдыг үл тоомсорлодог эсвэл түүхий сокет нээдэг програмуудад энэ аргаар туслах боломжгүй. Хөтөч болон ихэнх HTTP хэрэгслүүд хэвийн; тоглоомын клиент, шуудангийн демон эсвэл нийлүүлэгчийн дурын бинары ихэвчлэн тийм биш. Хил нь апп бүр, протокол бүрт байдаг тул энэ сонголт туршилтад маш сайн, бүх VPN-ийн хариулт болж сул байдаг.

Хоёр дахь тохиолдол: IP урсгалыг прокси сесс болгон хөрвүүлдэг адаптер

SOCKS ярьж чадахгүй програмуудад хөрвүүлэлт нь IP трафикийг зогсоож, тэдний өмнөөс прокси сесс нээдэг зүйлд явагдах ёстой. Тухайн бүрэлдэхүүн нь туннелийн интерфейстэй, бодлогын маршрутлалтын сонгосон урсгалыг хүлээн авч, тус бүрд нь SOCKS гар барилтыг хийж, хариултуудыг дахин бүтээдэг. Маршрут трафикийг тийш нь чиглүүлдэг; сессийг үүсгэдэг нь адаптер.

Бүхэл дэд сүлжээг түүнд даатгахаас өмнө баримт бичгийг нь уншина уу. Олон адаптер TCP-г сайн зөөдөг ч UDP-г зөвхөн SOCKS5 UDP холбоогоор боловсруулдаг бөгөөд тэдгээрийн аль нь ч ICMP-г прокси трафик болгон хувиргадаггүй тул амжилттай ping нь прокси замын тухай юу ч хэлэхгүй. DNS нь өөр нэг урхи: адаптер нэрсийг локал шийдвэл зөвхөн дотоод бүртгэлүүд буруу хариулт руу эсвэл огт юу ч руу шийдэгдэнэ.

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

Гурав дахь тохиолдол: хост нь үнэндээ маршрутлагдсан гарц

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

Гурван тохиолдол хурдан ялгардаг. Юу үнэхээр сонсож байгааг шалгаад, дараа нь хост руу хүрэх эхний байтуудыг хараарай:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Жинхэнэ SOCKS клиентийн эхний ачааллын байт нь 0x05, мэндчилгээний хувилбар. Хэрэв бичлэг оронд нь анхны аппын өгөгдлийг харуулбал ямар ч SOCKS демон хариулахгүй, учир нь хэлэлцээр хэзээ ч эхлээгүй. Хэрэв 1080 дээр юу ч сонсохгүй бол хост нь гарц бөгөөд асуулт нь тэр дамжуулдаг уу, буцах зам байгаа юу гэдэг болно.

Давхаргыг дөрвөн асуултаар сонгоно уу

Программд прокси тохиргоо байна уу? Ашиглаад тэнд зогсоно уу. Трафикт амьд үлдэх ёстой UDP эсвэл ICMP байна уу? ICMP-г зөвхөн маршрутлагдсан эсвэл NAT гарц зөөдөг, UDP-д хоёр тал дэмждэг SOCKS5 холбоо хэрэгтэй. Машины бүх процессыг, тохируулж чадахгүй байгаагуйг ч хамарсан байх ёстой юу? Тэгвэл интерфейсийг эзэмшиж, урсгалыг зогсоодог адаптер хэрэгтэй. Та түүний маршрутлалт, DNS, давталтаас сэргийлэх үл хамаарах зүйлсийг ч хариуцаж чадах уу? Чадахгүй бол энгийн гарц ажиллуулахад бага зардалтай.

Нэг ялгааг шулуун барих нь зүйтэй. VPN клиентийн өөрийн socks-proxy сонголт нь гадаад туннелийн холболт өөрийн серверт хэрхэн хүрдэгийг тайлбарладаг бөгөөд дотоод клиентийн урсгалыг хөрвүүлэх тухай юу ч хэлдэггүй. Энэ хоёрыг нэг тасалбар дээр байнга андуурдаг. Маршрутад хүрэхийн өмнө ямар харилцаа хэрэгтэйгээ шийдээрэй.