Siyasət marşrutlaşdırması SOCKS-a qarşı: trafiki hansı qat əslində proksiləyir

Siz VPN müştərisinin trafikini 1080 portunda SOCKS dinləyicisi işlədən hosta göndərən siyasət marşrutu əlavə etdiniz. Paketlər gəlir, dinləyici heç nə qeyd etmir və bağlantı asılı qalır. Marşrutda heç bir qüsur yoxdur: növbəti hop paketin hara getdiyini seçir, SOCKS isə müştərinin başlatmalı olduğu söhbətdir. İnsanların trafiki proksi vasitəsilə göndərməkdən adətən nəyi nəzərdə tutduğunu göstərən üç arxitekturanı müqayisə edin və qurğunuzda hansı hissənin çatışmadığı aydın olacaq.

Marşrutlaşdırma, DNAT və SOCKS fərqli şeyləri dəyişir

Siyasət marşrutu 3-cü qat qərarını yenidən yazır. Bir müştərinin trafikini seçilmiş növbəti hopa göndərmək üçün iki sətir kifayətdir:

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

Bundan sonra nüvə paketi 10.50.0.2-yə ötürür və orijinal təyinat hələ də IP başlığında qalır. Əgər 10.50.0.2 marşrutlaşdırıcıdırsa, paketi yönləndirir. Əgər o, 1080 portunda SOCKS demonu işlədən hostdursa, paket onu qəbul edə biləcək heç bir ünvana göndərilməyib və 1080 portuna DNAT da kömək etmir, çünki çevrilmiş paket yenə də SOCKS salamlaması əvəzinə orijinal tətbiq yükünü daşıyır.

SOCKS5 versiya baytı, metod siyahısı, autentifikasiya mübadiləsi və təyinatı adlandıran sorğu ilə başlayır. Bu, tətbiq məlumatıdır. Nə marşrut qeydi, nə də netfilter hədəfi onu yaradır və bir sətirlik müqayisə budur: marşrutlaşdırma yol seçir, SOCKS isə serverdən ikinci bağlantı yaratmağı xahiş edir.

Birinci hal: tətbiq özü SOCKS danışa bilir

Proqramın proksi parametri varsa, bu ən qısa yoldur və nüvədə heç bir dəyişiklik tələb etmir. Onu dinləyiciyə yönəldin, server istəsə etimadnamələri verin və adların yerli olaraq həll edilib-edilməyəcəyinə və ya proksiyə ötürüləcəyinə qərar verin. curl ilə bunlar fərqli açarlardır və təyinat yalnız proksi tərəfindən həll edildikdə fərq vacibdir:

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

Proksi mühit dəyişənlərini saymayan və ya xam soketlər açan tətbiqlərə bu yolla kömək etmək mümkün deyil. Brauzerlər və əksər HTTP alətləri yaxşıdır; oyun müştərisi, poçt demonu və ya təsadüfi satıcı binary faylı adətən belə deyil. Sərhəd hər tətbiq və hər protokol üçündür, buna görə də bu seçim test üçün əladır və bütün VPN üçün zəif cavabdır.

İkinci hal: IP axınlarını proksi sessiyalarına çevirən adapter

SOCKS danışa bilməyən proqramlar üçün çevrilmə IP trafikini sonlandıran və onların adından proksi sessiyaları açan bir şeydə baş verməlidir. Həmin komponent tunel interfeysinə sahibdir, siyasət marşrutlaşdırmasının seçdiyi axınları qəbul edir, hər biri üçün SOCKS əl sıxışmasını yerinə yetirir və cavabları yenidən qurur. Marşrut trafiki ora yönəldir; sessiyanı yaradan isə adapterdir.

Onu bütöv bir alt şəbəkəyə etibar etməzdən əvvəl sənədlərini oxuyun. Bir çox adapter TCP-ni yaxşı daşıyır və UDP ilə yalnız SOCKS5 UDP assosiasiyası vasitəsilə davranır, heç biri ICMP-ni proksi trafikinə çevirmir, buna görə də uğurlu ping proksi yolu haqqında heç nə demir. DNS digər tələdir: adapter adları yerli həll edirsə, yalnız daxili qeydlər səhv cavaba və ya heç bir cavaba həll olunur.

Dövrənin qarşısının alınması əməliyyat baxımından dişləyən detaldır. Adapterin SOCKS serverinə öz bağlantıları yenidən adapterə marşrutlanmamalıdır, buna görə onun trafikinə qaydada istisna və ya ayrılmış mənbə ünvanı lazımdır. Bunu səhv etsəniz, proksi sessiyası özünü proksiləməyə çalışacaq.

Üçüncü hal: host əslində marşrutlanmış şlüzdür

Bəzən işlək quraşdırmada ümumiyyətlə SOCKS olmur. Uzaq host paketləri yönləndirir və ya onlara NAT tətbiq edir, mənbəyə əsaslanan qayda isə onu sadəcə çıxış kimi seçir. Bu dizayn qanunidir və kopyalanmış konfiqurasiyanın bir şəbəkədə işləyib digərində uğursuz olmasını izah edir: qayda eynidir, çatışmayan hissə qarşı tərəfdəki yönləndirmə xidmətidir.

Üç hal tez ayrılır. Əslində nəyin dinlədiyini yoxlayın, sonra hosta çatan ilk baytlara baxın:

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

Həqiqi SOCKS müştərisinin ilk yük baytı 0x05-dir, yəni salamlamadakı versiyadır. Əgər tutma əvəzinə orijinal tətbiq məlumatı göstərirsə, heç bir SOCKS demonu cavab verməyəcək, çünki danışıqlar heç başlamayıb. Əgər 1080 portunda heç nə dinləmirsə, host şlüzdür və sual onun yönləndirib-yönləndirmədiyi və geri yolun olub-olmadığıdır.

Qatı dörd sualla seçin

Proqramın proksi parametri varmı? Ondan istifadə edin və orada dayanın. Trafikdə sağ qalmalı olan UDP və ya ICMP varmı? ICMP-ni yalnız marşrutlanmış və ya NAT şlüzü daşıyır, UDP isə hər iki tərəfin dəstəklədiyi SOCKS5 assosiasiyası tələb edir. Maşındakı hər proses, o cümlədən konfiqurasiya edə bilmədikləriniz əhatə olunmalıdırmı? Onda interfeysə sahib olan və axınları sonlandıran adapter lazımdır. Onun marşrutlaşdırma, DNS və dövrənin qarşısının alınması istisnalarına da sahib ola bilirsinizmi? Əgər yoxsa, adi şlüz istismarda daha ucuz başa gələcək.

Bir fərqi düzgün saxlamağa dəyər. VPN müştərisinin öz socks-proxy seçimi xarici tunel bağlantısının serverinə necə çatdığını təsvir edir və daxili müştəri axınlarının çevrilməsi barədə heç nə demir. Bu ikisi eyni biletdə daim qarışdırılır. Marşruta toxunmazdan əvvəl hansı əlaqəyə ehtiyacınız olduğuna qərar verin.