اتصال فقط IPv6، سرویس IPv4: بگذارید یک پروکسی SOCKS پل بزند

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

دو سوکت، دو خانواده نشانی

درخواست SOCKS5 مقصد را به یکی از سه شکل نام می‌برد: نشانی v4 تحت‌اللفظی، نشانی v6 تحت‌اللفظی یا نامی که پروکسی آن را تفکیک کند. درخواست توصیف می‌کند پروکسی کجا باید متصل شود، نه اینکه اتصال کارخواه به پروکسی چگونه است.

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

یک نمونه SSH کنترل‌شده

میزبانی SSH را برگزینید که مجاز به استفاده از آن هستید، به IPv6 پاسخ می‌دهد و خودش می‌تواند به سرویس HTTPS که فقط روی v4 وجود دارد برسد. ارسال شفاف پویا در OpenSSH یک شنونده SOCKS محلی روی ماشین شما می‌گذارد، در حالی که نشست ورود از روی v6 جریان دارد.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

میزبان و حساب بالا نمونه‌اند و اتصال loopback شنونده را روی همین رایانه نگه می‌دارد. آن را با اتصال به همه نشانی‌ها جایگزین نکنید تا دفتری پروکسی بدون احراز هویت را به اشتراک بگذارد. ExitOnForwardFailure=yes برای این است که ارسال شفاف ناموفق نشست را پایان دهد، نه اینکه فرمانی خاموش در پس‌زمینه رها شود.

وقتی نشست در حال اجراست، درخواست چنین است:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

اتصال loopback مسیر اینترنت IPv4 نیست. آنچه از ماشین شما بیرون می‌رود نشست ورود از روی v6 است و طرف دور است که سوکت مقصد را باز می‌کند. شکل socks5h تفکیک نام را نیز به همان طرف می‌سپارد، که وقتی کارخواه مسیر تفکیک‌کننده IPv4 خودش را ندارد اهمیت دارد.

آنچه مقصد واقعاً می‌بیند

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

بازپخش‌کننده همچنین جایی است که دو نیمه گفتگو در آن دیده می‌شود، که در عیب‌یابی ویژگی سودمندی است و اگر بازپخش‌کننده بدون سیاست به اشتراک گذاشته شود، یک بار مسئولیت است.

این DNS64 یا NAT64 نیست

DNS64 با رکوردهای ساختگی که جانشین مقصدهای v4 می‌شوند پاسخ می‌دهد، و NAT64 بسته‌ها را در طول مسیری پیکربندی‌شده بازنویسی می‌کند. هیچ‌کدام توصیف نمی‌کند آنچه اینجا رخ می‌دهد را، جایی که یک گفتگوی ترابری پایان می‌یابد و دیگری آغاز می‌شود و هیچ نشانی ساختگی نتیجه را توضیح نمی‌دهد. بنابراین درخواست موفق چیزی درباره اینکه ارائه‌دهنده شما چه سرویس‌های ترجمه‌ای را اداره می‌کند نمی‌گوید، و پروکسی می‌تواند NAT عادی را روی خروجی خود اجرا کند.

هر دو سازوکار می‌توانند در همان شبکه وجود داشته باشند، پس آنچه را واقعاً بررسی کرده‌اید توصیف کنید، نه آنچه نزدیک‌تر به گوش می‌آید.

پیش از وعده دادن، دامنه را بشناسید

ارسال شفاف پویا در OpenSSH اتصال‌های TCP را حمل می‌کند، نه ترافیک دلخواه IP را، بنابراین UDP، ICMP و هر پروتکلی که پروکسی را نادیده می‌گیرد به طراحی پشتیبانی‌شده دیگری نیاز دارند. بازبینی کلید میزبان SSH، محدودیت‌های ارسال شفاف کارساز و اعتبارسنجی گواهی HTTPS را نگه دارید، زیرا پروکسی مشارکت‌کننده مورداعتماد اضافی است، نه دلیلی برای ضعیف کردن بررسی‌های هویت. اگر هدف حمل ترابری بیرونی یک VPN از طریق پروکسی است، بررسی کنید که هر دو سر پشتیبانی از آن ترابری را دارند، نه اینکه فرض کنید هر شنونده SOCKS می‌تواند آن را بازپخش کند.

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