Proksi javob beradi, so‘rov tugaydi va shunga qaramay manzil hali ham LAN manzilini yozib oladi. Proksi jurnalida hech narsa noto‘g‘ri ko‘rinmaydi va siz o‘zgartirgan qator hujjat o‘zgartirishni aytgan qatorning o‘zi. Ham LAN manzili, ham tunnel manzili bo‘lgan xostda qaysi manzil qayerda ko‘rinishini uchta direktiva hal qiladi va ulardan faqat bittasi chiquvchi tomonga tegishli. Noto‘g‘ri tartibda o‘qisangiz, sababsiz marshrutlash jadvaliga tushasiz.

Alomat: manzil LAN manzilini ko‘radi

Mijoz LAN manzilida proksiga ulanadi, proksi esa manzilga o‘z ulanishini ochadi. O‘sha ikkinchi ulanish manba manzilini yadro qoidalari bo‘yicha tanlaydi va sukut bo‘yicha marshrut qidiruvi tanlagani bo‘ladi. Shuning uchun har bir bayt proksidan o‘tgan bo‘lsa ham manzil xostning asosiy manzilini yozib oladi. Yo‘naltirish nuqtai nazaridan hech narsa buzilmagan, shuning uchun proksi jurnalida bu haqda aytadigan gapi yo‘q.

Bu xatoning ko‘zgu tasvirini payqash osonroq: chiquvchi manbani tunnel manziliga qadab qo‘ying, LAN mijozlari tinglovchiga umuman yetib bormaydi. O‘sha versiya o‘zini e’lon qiladi, birinchisi esa ishlayotgan so‘rov orqasiga yashirinadi. Ikkisi ham bitta direktivani ikkala savolga javob beradi deb qarashdan kelib chiqadi.

Uch direktiva, uch xil manzil

Listen proksi mijozlarini qabul qiluvchi mahalliy manzilni nomlaydi. Bind proksi tashqariga ochadigan ulanishlar uchun manba manzilini beradi, BindSame esa unga hozir qabul qilingan ulanishning mahalliy manzilini qayta ishlatishni buyuradi. Bu uchta alohida savol va bitta qator faqat bittasiga javob beradi. Ularni aralashtirish o‘zgarish hech narsa qilmayotgandek ko‘rinishining odatiy sababi.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

O‘rnatilgan versiya bilan keladigan izohli konfiguratsiyani o‘qing, chunki sukut qiymatlari va qabul qilinadigan sintaksis nashrlar orasida o‘zgaradi. Loyihaning namunali konfiguratsiyasi har bir direktivani boshqalari yonida hujjatlashtiradi. O‘sha faylni diskdagi fayl bilan solishtiring, boshqa distributiv uchun yozilgan qo‘llanma bilan emas.

Tinglovchi va chiquvchi manbani alohida sozlang

LAN manzili 192.168.50.10, tunnel manzili 10.90.0.3 bo‘lgan xostni oling. Agar LAN mijozlari proksiga yetishi, so‘rovlari esa tunneldan chiqishi kerak bo‘lsa, bu ikki mustaqil qaror va ikkalasini ham yozish kerak. Quyidagi parcha aynan shuni ifodalaydi, boshqa hech narsani emas.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Bu to‘liq konfiguratsiya emas, shuning uchun tasdiqlangan port, autentifikatsiya, mijozlar kirishini nazorat qilish va manzil cheklovlarini saqlang. Ikkala manzil ham Tinyproxy tarmoq nom fazosida shu xostga tegishli bo‘lishi kerak, chunki protsess egalik qila olmaydigan Bind qiymati ishga tushishda emas, ulanish paytida muvaffaqiyatsiz bo‘ladi. BindSame yes boshqa siyosatni tavsiflaydi: qabul qilingan ulanishning mahalliy manzili chiquvchi manbaga aylanadi. Joriy nashrlarda bu tarmoq Bind ro‘yxatidan ustun, va shu tariqa sozlangan manba xatosiz yo‘qoladi.

Manba nazarda tutgan marshrutni tekshiring

Manba manzilini tanlash yo‘l yaratmaydi, shuning uchun yadrodan o‘sha manba va o‘sha manzil bilan nima qilishini so‘rang. Tunnel interfeysini nomlaydigan qidiruv minimal dalil, LAN interfeysini nomlaydigani esa manba yozilganidek ishlay olmasligini bildiradi. Qidiruv kontekstli: u o‘sha nom fazosi uchun amaldagi siyosat qoidalari va jadvalni baholaydi. Bu ulanish emas va quyi NAT xizmatga nimani ko‘rsatishi haqida hech narsa demaydi.

ip -4 route get 203.0.113.25 from 10.90.0.3

Misolda hujjat manzilidan foydalaning va sinashga ruxsat berilgan xizmatni qo‘ying. Proksi konteynerda ishlayotganda qidiruvni proksi nom fazosi ichida bajaring, chunki xost qoidalari protsess ko‘radigan qoidalar emas. Ko‘zlangan tunnel marshruti bo‘lmasa, proksi xostiga manzilga xos qoidalar qo‘shish o‘rniga tarmoq egasi tuzatsin. Qidiruv muvaffaqiyatli bo‘lishi uchun xost marshrutlarini tozalamang va server yuboradigan marshrutlarni o‘chirmang, eski qo‘llanma shunday qilgan bo‘lsa ham, chunki bunday o‘zgarishlar bitta proksi yo‘lini tuzatish uchun butun xostning tasdiqlangan VPN xatti-harakatini siljitadi.

Manbani manzilda tasdiqlang

Manbani so‘rov keladigan joyda o‘qing, u chiqadigan joyda emas. Manzildagi dastur jurnali yoki uning oldidagi chekka qurilma o‘zi haqiqatan ko‘rgan manzilni yozadi, proksi esa faqat niyatini aytadi. O‘zgarishdan keyin ko‘zlangan tinglovchi orqali bitta yangi so‘rov yuboring, chunki keshdagi ulanish yangi bog‘lanish haqida hech narsani isbotlamaydi. So‘ng yozilgan manzilni siz sozlagan manzil bilan solishtiring.

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

curl faqat trafik generatori; tekshirishga arziydigan manzil uzoq tomon yozgan manzil, curl tasodifan ulangan sherik emas. Ikkisi mos kelmasa, farq manba tanlovidan yoki keyingi o‘zgartirishdan kelishini aniqlang, chunki ular turli joylarda tuzatiladi. Manzil o‘zgarishlari va proksini qayta ishga tushirishni birga rejalashtiring, chunki tunnel endi egalik qilmaydigan manzilni bog‘lash qayta ulanishdan keyin jimgina muvaffaqiyatsiz bo‘ladi. DNS va IPv6 xatti-harakatini ham alohida belgilang, chunki yuqoridagi IPv4 parchasi ikkisining birortasi haqida hech narsani isbotlamaydi.

O'xshash maqolalar