curl socks5h در برابر socks5: چه کسی نام میزبان را حل می‌کند

مردم socks5h را socks5 با املای دوستانه‌تری یکسان می‌دانند و انتظار دارند هر دو همان درخواست را به همان مقصد بفرستند. اما حرف اضافه جست‌وجوی DNS را جابه‌جا می‌کند. روی ماشینی که حل‌کننده و پروکسی آن در شبکه‌های متفاوت قرار دارند، این تفاوت میان درخواستی است که کار می‌کند و درخواستی که شکست می‌خورد.

یک حرف، دو حل‌کننده

طرحواره تعیین می‌کند نام مقصد کجا به نشانی تبدیل می‌شود. حل محلی از حل‌کننده‌ای استفاده می‌کند که روی ماشین شما پیکربندی شده است. حل راه‌دور نام میزبان را داخل درخواست SOCKS می‌گذارد و پروکسی آن را با حل‌کننده خود و نگاه خود به شبکه جست‌وجو می‌کند. هر دو شکل همچنان به همان نشانی پروکسی روی همان درگاه وصل می‌شوند، پس تفاوت در بدنه درخواست است، نه در مسیر.

هیچ چیز در طرحواره رمزنگاری یا احراز هویت را تغییر نمی‌دهد؛ فقط مسیر DNS جابه‌جا می‌شود. به همین دلیل نادیده گرفتن حرف آسان و اشتباه کردن در آن گران است.

همان پروکسی، درخواست متفاوت

دو فراخوانی تنها در یک نویسه تفاوت دارند. همه چیز دیگر یکسان است:

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The مرجع پروکسی curl این طرحواره‌ها را جداگانه مستند می‌کند و همین دلیل معتبری است که آن‌ها را هم‌معنا نگیریم. هر دو را در برابر یک نقطه پایانی بی‌خطر که مجاز به استفاده از آن هستید اجرا کنید و تفاوت را بخوانید. یک جست‌وجوی راه‌دور موفق درباره برنامه‌های دیگر چیزی نمی‌گوید، زیرا مرورگرها، مدیران بسته و محیط‌های اجرای زبان‌ها هر یک خودشان انتخاب می‌کنند.

نام خود پروکسی به‌صورت محلی حل می‌شود

در آن فرمان، proxy.example باید پیش از هر چیز دیگری به نشانی تبدیل شود و آن جست‌وجو همیشه محلی است. انتقال حل service.example به پروکسی هیچ کاری برای نام خود پروکسی نمی‌کند، که هنوز به حل‌کننده‌ای نیاز دارد که ماشین شما به آن دسترسی داشته باشد. اینجاست که VPN تصویر را تغییر می‌دهد.

اگر نام پروکسی فقط داخل تونل حل شود، اتصال به این بستگی دارد که تونل پیش از شروع curl برپا باشد. اینکه کدام طرحواره برنده شود به این بستگی دارد که کدام طرف می‌تواند پاسخ دهد. وقتی ماشین شما نمی‌تواند مقصد را حل کند اما پروکسی می‌تواند، socks5 شکست می‌خورد و socks5h موفق می‌شود. وقتی ماشین شما آن را از طریق تونل حل می‌کند و پروکسی نمی‌تواند، socks5 کار می‌کند و socks5h شکست می‌خورد.

طرحواره اتصال به پروکسی را داخل یا بیرون VPN قرار نمی‌دهد؛ جدول مسیریابی این کار را می‌کند و طرحواره هرگز آن را نمی‌بیند. به همین دلیل یک تونل می‌تواند یک طرحواره را درست و دیگری را روی همان ماشین خراب کند. حرف فقط تعیین می‌کند چه کسی پرسش را می‌پرسد.

هر طرف چه چیزی را می‌تواند حل کند

یک پروکسی عمومی نمی‌تواند نامی را که فقط درون شرکت وجود دارد حل کند، پس فرستادن نام میزبان به آن در پروکسی شکست می‌خورد و به‌جای خطای DNS محلی به‌صورت خطای پروکسی ظاهر می‌شود. پروکسی داخل همان شبکه خصوصی معمولاً می‌تواند آن نام‌ها را حل کند و همین‌جاست که socks5h ارزش خود را ثابت می‌کند. محل حل‌کننده را بر اساس سیاستی که واقعاً نیاز دارید انتخاب کنید، چون DNS راه‌دور به‌طور خودکار توانمندتر نیست و نام را واقعاً به شخص ثالث می‌سپارد. برای مقصد عمومی هر دو شکل کار می‌کند، پس آن را ترجیح دهید که ابزارهای دیگرتان از قبل استفاده می‌کنند.

آن انتخاب را در runbook بنویسید نه در یک توضیح، و اعتبارنامه‌ها را از تاریخچه مشترک و خروجی تشخیصی بیرون نگه دارید. سپس هر بار یک متغیر را تغییر دهید: همان مقصد، همان باینری، همان حل‌کننده، یک حرف.

کدام باینری پاسخ داد

دو باینری curl روی یک ماشین می‌توانند در نسخه و ویژگی‌های ساخت متفاوت باشند. در پوسته‌ای شبیه Unix، type -a curl هر تطابق در مسیر را فهرست می‌کند و curl --version ویژگی‌های آن یکی را که اجرا می‌شود نشان می‌دهد. یک اسکریپت پوششی یا یک نام مستعار در ابتدای مسیر دلیل رایجی است که نتایج با باینری‌ای که فکر می‌کنید آزمایش می‌کنید مطابقت ندارد.

طرحواره پشتیبانی‌نشده، پروکسی‌ای که نمی‌تواند نام را حل کند و مقصدی که در دسترس نیست سه خطای متفاوت‌اند، پس پیش از تغییر حرف پیام را بخوانید. ساخت بدون نحو socks5h رشته پروکسی را پشتیبانی‌نشده گزارش می‌کند و این با نامی که حل نشد یکی نیست. یک گزارش قدیمی درباره curl سیستم را به قاعده‌ای دائمی برای همه سکوها تبدیل نکنید.