Listen، Bind و BindSame در Tinyproxy: کدام نشانی برنده است
Listen نشانی‌ای را انتخاب می‌کند که کارخواهان را می‌پذیرد، Bind منبع اتصال‌های خروجی را انتخاب می‌کند. هیچ‌کدام مسیری نصب نمی‌کند، پس مسیر را جداگانه بررسی کنید.
پروکسی پاسخ می‌دهد، درخواست کامل می‌شود، و با این حال مقصد همچنان نشانی شبکه محلی را ثبت می‌کند. هیچ چیز در گزارش پروکسی نادرست به نظر نمی‌رسد، و خطی که تغییر داده‌اید همان خطی است که مستندات گفته بود تغییر دهید. روی میزبانی که هم نشانی شبکه محلی و هم نشانی تونل دارد، سه دستور تعیین می‌کنند کدام نشانی کجا ظاهر شود، و تنها یکی از آن‌ها به سمت خروجی مربوط است. اگر آن‌ها را به ترتیب نادرست بخوانید، بی‌دلیل به جدول مسیریابی می‌رسید.
نشانه: مقصد نشانی شبکه محلی را می‌بیند
کارخواه از طریق نشانی شبکه محلی به پروکسی وصل می‌شود و پروکسی اتصال خودش را به مقصد باز می‌کند. آن اتصال دوم نشانی مبدأ را بر پایه قواعد هسته انتخاب می‌کند و به‌طور پیش‌فرض همانی است که جست‌وجوی مسیر برمی‌گزیند. بنابراین مقصد نشانی اصلی میزبان را ثبت می‌کند، هرچند هر بایت از پروکسی گذشته است. از نظر ارسال به جلو چیزی خراب نیست، و به همین دلیل گزارش پروکسی چیزی برای گفتن ندارد.
تصویر آینه‌ای این خطا آسان‌تر دیده می‌شود: مبدأ خروجی را به نشانی تونل سنجاق کنید و کارخواهان شبکه محلی دیگر به شنونده نمی‌رسند. آن نسخه خودش را اعلام می‌کند، در حالی که نسخه نخست پشت یک درخواست سالم پنهان می‌شود. هر دو از این می‌آید که یک دستور را چنان ببینیم که گویی به هر دو پرسش پاسخ می‌دهد.
سه دستور، سه نشانی متفاوت
Listen نشانی محلی‌ای را نام می‌برد که کارخواهان پروکسی را می‌پذیرد. Bind نشانی مبدأ را برای اتصال‌هایی که پروکسی به بیرون می‌سازد فراهم می‌کند، و BindSame به آن می‌گوید نشانی محلی همان اتصالی را که تازه پذیرفته دوباره به کار ببرد. این‌ها سه پرسش جداگانه‌اند و یک خط تنها به یکی پاسخ می‌دهد. اشتباه گرفتن آن‌ها دلیل معمول بی‌اثر به نظر رسیدن یک تغییر است.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
پیکربندی توضیح‌داری را که همراه نسخه نصب‌شده ارائه می‌شود بخوانید، چون مقادیر پیش‌فرض و نحو پذیرفته‌شده میان انتشارها تغییر می‌کند. پیکربندی نمونه پروژه هر دستور را کنار بقیه مستند می‌کند. آن پرونده را با پرونده روی دیسک مقایسه کنید، نه با راهنمایی که برای توزیع دیگری نوشته شده است.
شنونده و مبدأ خروجی را مستقل تنظیم کنید
میزبانی را بگیرید که نشانی شبکه محلی‌اش 192.168.50.10 و نشانی تونلش 10.90.0.3 است. اگر کارخواهان شبکه محلی باید به پروکسی برسند و در همان حال درخواست‌هایشان از تونل خارج شود، این دو تصمیم مستقل‌اند و هر دو باید نوشته شوند. قطعه زیر دقیقاً همین را بیان می‌کند و نه چیز دیگر.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noاین پیکربندی کامل نیست، پس درگاه تأییدشده، احراز هویت، کنترل دسترسی کارخواهان و محدودیت‌های مقصد را نگه دارید. هر دو نشانی باید درون فضای نام شبکه Tinyproxy به این میزبان تعلق داشته باشند، چون مقدار Bind که فرایند نمی‌تواند صاحبش باشد در زمان اتصال شکست می‌خورد، نه در زمان راه‌اندازی. BindSame yes سیاست دیگری را توصیف می‌کند: نشانی محلی اتصال پذیرفته‌شده مبدأ خروجی می‌شود. در انتشارهای کنونی این شاخه بر فهرست Bind اولویت دارد، و بدین‌سان یک مبدأ پیکربندی‌شده بدون هیچ خطایی ناپدید می‌شود.
مسیری را که مبدأ ایجاب می‌کند بررسی کنید
انتخاب نشانی مبدأ مسیری نمی‌سازد، پس از هسته بپرسید با آن مبدأ و آن مقصد چه می‌کند. جست‌وجویی که رابط تونل را نام می‌برد کمترین شاهد است، و جست‌وجویی که رابط شبکه محلی را نام می‌برد یعنی مبدأ به شکلی که نوشته شده کار نمی‌کند. جست‌وجو زمینه‌مند است: قواعد سیاست و جدولی را که در آن فضای نام جاری است ارزیابی می‌کند. این یک اتصال نیست و درباره آنچه NAT پایین‌تر به سرویس نشان می‌دهد چیزی نمی‌گوید.
ip -4 route get 203.0.113.25 from 10.90.0.3در مثال از نشانی مستندات استفاده کنید و سرویسی را بگذارید که اجازه آزمودنش را دارید. وقتی پروکسی در کانتینر است، جست‌وجو را درون فضای نام پروکسی اجرا کنید، چون قواعد میزبان همان قواعدی نیست که فرایند می‌بیند. اگر مسیر تونل مورد نظر وجود ندارد، بگذارید صاحب شبکه آن را درست کند، نه اینکه قواعد ویژه مقصد به میزبان پروکسی بیفزایید. برای موفقیت یک جست‌وجو مسیرهای میزبان را پاک نکنید و مسیرهای فشرده‌شده از سوی سرور را غیرفعال نکنید، حتی اگر راهنمای قدیمی‌تری چنین کرده باشد، چون این تغییرها تمام رفتار تأییدشده VPN میزبان را جابه‌جا می‌کنند تا یک مسیر پروکسی درست شود.
مبدأ را در مقصد تأیید کنید
مبدأ را آنجا بخوانید که درخواست می‌رسد، نه آنجا که بیرون می‌رود. گزارش برنامه مقصد، یا دستگاه لبه‌ای پیش از آن، نشانی‌ای را ثبت می‌کند که واقعاً دیده است، در حالی که پروکسی فقط می‌تواند بگوید قصدش چه بود. پس از تغییر، یک درخواست تازه از طریق شنونده مورد نظر بفرستید، چون اتصال نهفته در حافظه درباره پیوند جدید چیزی ثابت نمی‌کند. سپس آن نشانی ثبت‌شده را با نشانی‌ای که تنظیم کرده‌اید مقایسه کنید.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl تنها تولیدکننده ترافیک است؛ نشانی‌ای که ارزش بررسی دارد همانی است که طرف دور ثبت کرده، نه همتایی که curl تصادفاً به آن وصل شد. اگر این دو ناسازگار باشند، روشن کنید تفاوت از انتخاب مبدأ می‌آید یا از تبدیل جلوتر در مسیر، چون آن‌ها در جاهای مختلف درست می‌شوند. تغییرهای نشانی و راه‌اندازی دوباره پروکسی را با هم برنامه‌ریزی کنید، چون پیوند دادن نشانی‌ای که تونل دیگر آن را ندارد پس از اتصال دوباره بی‌صدا شکست می‌خورد. رفتار DNS و IPv6 را هم جدا تعریف کنید، چون قطعه IPv4 بالا درباره هیچ‌کدام چیزی ثابت نمی‌کند.