Redsocks yerli geri döngə üzərində dinləyir, lakin VPN trafiki heç vaxt gəlib çatmır

Tunel qalxır, müştəri şlüzü ping edə bilir, amma proksi yolu ilə gedən hər veb sorğusu ölür. redsocks prosesi işləyir və portu dinləyir, ona görə xidmət şlüzün özündən sağlam görünür. Uğursuz olan çatdırılma mərhələsidir: tuneldən yönləndirilən paket sizin başlatdığınız soketə düşmür. Bağlantı ünvanı ilə yönləndirmə hədəfi uyğun olmalıdır və adətən onlardan yalnız biri yoxlanılır.

Yönləndirilmiş paket əslində hara düşür

Şlüz üzərində şəffaf proksiləşdirmə, daxil olan bağlantının təyinatını yerli porta yenidən yazmaq üçün PREROUTING-də nat cədvəlində REDIRECT istifadə edir. Yenidən yazılmış təyinat paketin gəldiyi interfeysdən görünən yerli ünvandır, başqa yerdə başlamış prosesin geri döngə ünvanı deyil. Yalnız 127.0.0.1 ünvanına bağlanmış dinləyici hostda artıq yerli olan bağlantıları qəbul edir və tunel trafiki uğursuz olarkən işləməyə davam edən hal məhz budur. Müştərinin öz geri döngə ünvanı üçüncü ünvandır və heç vaxt şlüz qaydasının hədəfi olmur.

Buna görə yuxarı axın etimad məlumatlarına toxunmadan əvvəl iki faktı müəyyənləşdirin: qayda hansı yerli ünvana yenidən yazır və proksi soketi hansı ünvana bağlanıb.

Dinləyicini və yönləndirmə qaydasını birlikdə oxuyun

Soket cədvəlini və nat qaydalarını eyni keçiddə çap edin, çünki heç kimin sahib olmadığı porta baxan qayda səhv ünvana baxan qayda ilə eyni görünür. sudo ss -ltnp | grep redsocks bağlantı ünvanını və sahib prosesi göstərir. sudo iptables -t nat -S PREROUTING REDIRECT hədəfini göstərir, sudo iptables -t nat -L PREROUTING -v -n isə ona nəyinsə uyğun gəlib-gəlmədiyini göstərir.

REDSOCKS adlı istifadəçi zəncirinə keçid o zəncir mövcud olmadan və nəzərdə tutulan istisnaları və REDIRECT əməliyyatını daşımadan heç nə etmir. Adın işi gördüyünü güman etmək əvəzinə, keçid etdiyi zənciri sudo iptables -t nat -S REDSOCKS ilə oxuyun.

Sonra iki dəyəri müqayisə edin. Qayda 12345 portundaki şlüz ünvanına yönləndirirsə və dinləyici 127.0.0.1:12345 bildirirsə, uyğunsuzluq nasazlığı əlavə diaqnostika olmadan izah edir.

Dar bağlayın, sonra ona çata biləcəkləri məhdudlaşdırın

Yuxarı axın nümunə konfiqurasiyası dinləyicini yaxşı səbəbdən geri döngəyə kökləyir: şəffaf proksi ona çata bilən hər kəsin adından bağlantı qəbul edir. Bağlantını 0.0.0.0-a dəyişmək çatdırılmanı düzəldir və eyni zamanda portu hər interfeysdə açır, bu isə təhlükəsizlik dəyişikliyidir, neytral təmir deyil. Yönləndirmənin hədəflədiyi xüsusi yerli ünvana bağlanmağa üstünlük verin və portu etibarsız interfeyslərdə bağlı saxlayın. Daha geniş bağlantı qaçılmazdırsa, yalnız tunel mənbə aralığına və şlüzün öz yerli trafikinə icazə verən host firewall qaydası əlavə edin.

Portu ümumi interfeysdə açmaq yönləndirilmiş VPN trafiki üçün heç vaxt tələb olunmur, çünki bağlantı yenidən yazmadan sonra yerli olaraq bitir. Yerli yönləndirməni işlətmək üçün proksini internetə açmayın.

Müştəridən yeni bağlantı ilə sübut edin

Şlüzün üzərindəki shell-dən deyil, real VPN müştərisindən təzə TCP bağlantısı ilə sınaqdan keçirin. Müştəridəki curl -sS -o /dev/null -w '%{http_code}\n' http://example.com yönləndirilmiş yolu başdan-başa yoxlayır.

Sonra etibarsız şəbəkədən dinləyiciyə birbaşa bağlantının hələ də rədd edildiyini və proksinin öz yuxarı axın bağlantısının eyni qayda ilə yenidən tutulmadığını təsdiqləyin. Təkrarlanan tutma özünə qoşulan və heç vaxt sorğunu tamamlamayan proksi kimi görünür. Proksinin təyinatını istisna dəstinə əlavə edin və ya onun çıxan paketlərini işarələyin ki, zəncir onları atlassın.

Nəhayət, bu yolun nələri əhatə etmədiyini xatırlayın. Adi redsocks TCP yönləndirməsi UDP, QUIC və ya DNS-i SOCKS trafikinə çevirmir və özəl təyinatlar adətən açıq istisnalar tələb edir. Uğurlu yerli sınaq yalnız heç vaxt problem olmayan geri döngə yolunu sübut edir.