Tinyproxy-də Listen, Bind və BindSame: hansı ünvan qalib gəlir

Proksi cavab verir, sorğu tamamlanır, amma təyinat yenə də LAN ünvanını qeyd edir. Proksi jurnalında qəribə heç nə görünmür və dəyişdiyiniz sətir sənədləşmənin dəyişməyi tapşırdığı sətirdir. Həm LAN, həm də tunel ünvanı olan hostda hansı ünvanın harada görünəcəyini üç direktiv həll edir və onlardan yalnız biri gedən tərəfə aiddir. Onları səhv ardıcıllıqla oxumaq sizi heç bir səbəb olmadan marşrut cədvəlinə aparır.

Simptom: təyinat LAN ünvanını görür

Bir müştəri LAN ünvanı üzərindən proksiyə qoşulur və proksi təyinat hədəfinə öz bağlantısını açır. Həmin ikinci bağlantı mənbə ünvanını nüvənin qaydaları ilə seçir və susmaya görə bu, marşrut axtarışının seçdiyi ünvandır. Buna görə təyinat hər bayt proksidən keçsə də hostun əsas ünvanını qeyd edir. Yönləndirmə baxımından heç nə pozulmayıb, ona görə də proksi jurnalının bu barədə deyəcəyi bir şey yoxdur.

Bu nasazlığın güzgü tərəfi daha asan seçilir: gedən mənbəni tunel ünvanına bağlayın və LAN müştəriləri dinləyiciyə ümumiyyətlə çatmaz. O versiya özünü bəyan edir, birincisi isə işləyən sorğunun arxasında gizlənir. İkisi də bir direktivin hər iki suala cavab verdiyini güman etməkdən doğur.

Üç direktiv, üç fərqli ünvan

Listen proksi müştərilərini qəbul edən yerli ünvanı adlandırır. Bind proksinin xaricə açdığı bağlantılar üçün mənbə ünvanı verir, BindSame isə ona təzəcə qəbul etdiyi bağlantının yerli ünvanını təkrar istifadə etməyi tapşırır. Bunlar üç ayrı sualdır və bir sətir yalnız birinə cavab verir. Onları qarışdırmaq dəyişikliyin heç bir iş görməməsinin adi səbəbidir.

Quraşdırılmış versiya ilə gələn şərhlənmiş konfiqurasiyanı oxuyun, çünki susmaya olan dəyərlər və qəbul edilən sintaksis buraxılışlar arasında dəyişir. Layihənin nümunə konfiqurasiyası hər direktivi digərlərinin yanında sənədləşdirir. Həmin faylı diskdəki faylla müqayisə edin, başqa distributiv üçün yazılmış bələdçi ilə deyil.

Dinləyicini və gedən mənbəyi ayrı-ayrılıqda qurun

LAN ünvanı 192.168.50.10, tunel ünvanı 10.90.0.3 olan bir host götürün. LAN müştəriləri proksiyə çatmalı, sorğuları isə tuneldən çıxmalıdırsa, bunlar iki ayrı qərardır və hər ikisi yazılmalıdır. Aşağıdakı fraqment məhz bunu ifadə edir, başqa heç nəyi deyil.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Bu tam konfiqurasiya deyil, ona görə təsdiqlənmiş portu, autentifikasiyanı, müştəri girişinə nəzarəti və təyinat məhdudiyyətlərini saxlayın. Hər iki ünvan Tinyproxy-nin şəbəkə ad məkanı daxilində bu hosta məxsus olmalıdır, çünki prosesin sahiblənə bilmədiyi Bind dəyəri başlanğıcda deyil, qoşulma anında uğursuz olur. BindSame yes başqa siyasəti təsvir edir: qəbul edilən bağlantının yerli ünvanı gedən mənbəyə çevrilir. Hazırkı buraxılışlarda bu budaq Bind siyahısından üstün tutulur və konfiqurasiya edilmiş mənbə xətasız məhz belə yox olur.

Mənbənin nəzərdə tutduğu marşrutu yoxlayın

Mənbə ünvanı seçmək yol yaratmır, ona görə nüvədən soruşun ki, o mənbə və o təyinatla nə edərdi. Tunel interfeysini göstərən axtarış minimum sübutdur, LAN interfeysini göstərən axtarış isə mənbənin yazıldığı kimi işləyə bilməyəcəyi deməkdir. Axtarış kontekstualdır: o, həmin ad məkanı üçün qüvvədə olan siyasət qaydalarını və cədvəli qiymətləndirir. Bu, bağlantı deyil və aşağı axındakı NAT-ın xidmətə nə təqdim edəcəyi barədə heç nə demir.

ip -4 route get 203.0.113.25 from 10.90.0.3

Nümunədə sənədləşmə ünvanından istifadə edin və onu test etməyə icazəniz olan xidmətlə əvəz edin. Proksi konteynerdə işləyirsə, axtarışı proksinin ad məkanı daxilində aparın, çünki hostun qaydaları prosesin gördüyü qaydalar deyil. Nəzərdə tutulan tunel marşrutu yoxdursa, proksi hostuna təyinata xas qaydalar əlavə etmək əvəzinə şəbəkə sahibinə onu düzəltməyi tapşırın. Axtarışın uğurlu olması üçün host marşrutlarını silməyin və serverin göndərdiyi marşrutları söndürməyin, köhnə bələdçi bunu etmiş olsa belə, çünki belə dəyişikliklər bir proksi yolunu düzəltmək üçün bütün hostun təsdiqlənmiş VPN davranışını yerindən oynadır.

Mənbəni təyinatda təsdiqləyin

Mənbəni sorğunun gəldiyi yerdə oxuyun, getdiyi yerdə deyil. Təyinatın tətbiq jurnalı və ya onun qarşısındakı kənar cihaz həqiqətən gördüyü ünvanı qeyd edir, proksi isə sizə yalnız niyyətini deyə bilər. Dəyişiklikdən sonra nəzərdə tutulan dinləyici üzərindən bir təzə sorğu göndərin, çünki keşlənmiş bağlantı yeni bağlanma barədə heç nə sübut etmir. Sonra qeyd olunan ünvanı konfiqurasiya etdiyiniz ünvanla müqayisə edin.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl yalnız trafik generatorudur; yoxlanmağa dəyər ünvan uzaq tərəfin qeyd etdiyi ünvandır, curl-un təsadüfən qoşulduğu həmkar deyil. İkisi uyğun gəlmirsə, fərqin mənbə seçimindən, yoxsa daha sonrakı çevrilmədən qaynaqlandığını müəyyən edin, çünki onlar müxtəlif yerlərdə düzəldilir. Ünvan dəyişikliklərini və proksinin yenidən başladılmasını birlikdə planlaşdırın, çünki tunelin artıq saxlamadığı ünvanı bağlamaq yenidən qoşulmadan sonra səssizcə uğursuz olur. DNS və IPv6 davranışını da ayrıca müəyyənləşdirin, çünki yuxarıdakı IPv4 fraqmenti ikisi barədə heç nə sübut etmir.