پروکسی HTTP، تونل SSH یا VPN: لایه درست را انتخاب کنید
پروکسی، تونل SSH و VPN ترافیک متفاوتی حمل می‌کنند. لایه را با پروتکل‌ها و حل نامی که کار شما لازم دارد هماهنگ کنید و سپس مسیر را بررسی کنید.
از سه مهندس بپرسید چطور به یک سرویس داخلی می‌رسند و سه طرح می‌گیرید: یک پروکسی وب، یک تونل SSH یا یک VPN کامل. هر سه می‌توانند سرویس دور را در دسترس بگذارند و هر سه می‌توانند ترافیک را طوری نشان دهند که از جای دیگری می‌آید. تفاوت‌ها بعدا آشکار می‌شوند، وقتی پروتکل در استفاده همان نیست که ابزار انتخاب‌شده فرض می‌کند. طرحی که یک بررسی سریع مرورگر را می‌گذراند، معمولا در برنامه‌ای که درخواست را برانگیخت شکست می‌خورد.
از دو واقعیت تصمیم بگیرید: کدام پروتکل‌ها باید عبور کنند و چه کسی می‌تواند نام‌های دخیل را حل کند. بقیه چیزها ترجیح است.
پروکسی فقط آنچه را می‌فهمد جابه‌جا می‌کند
پروکسی وب پروتکلی را تجزیه می‌کند که برایش ساخته شده است. کلاینت درخواستی به آن می‌دهد و آن درخواست را جلوتر می‌فرستد، پس برنامه‌ای که تنظیم پروکسی ندارد اصلا شرکت نمی‌کند. برای HTTPS کلاینت به کانالی مات نیاز دارد که پروکسی آن را از طریق CONNECT فراهم می‌کند، نه با خواندن درخواست.
ارسال دینامیک SSH یک پورت محلی باز می‌کند که SOCKS حرف می‌زند، و آن پورت جریان TCP را به هر مقصدی که کلاینت نام ببرد می‌فرستد. پروتکل‌های مبتنی بر TCP معمولا از آن کار می‌کنند. UDP نه، مگر اینکه ابزاری پشتیبانی را صریحا اضافه کند. ارسال محلی باز هم تنگ‌تر است: یک پورت محلی نگاشت‌شده به یک میزبان و پورت ثابت، که به یک سرویس شناخته‌شده خدمت می‌کند و نه بیشتر.
ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastionVPN بسته‌ها را جابه‌جا می‌کند. هر چیزی که کلاینت به تونل مسیر می‌دهد از آن می‌گذرد، از جمله UDP و ICMP، به همین دلیل برای یک نیاز شبکه مناسب است نه یک اتصال واحد.
یک نفر باید نام را حل کند
وقتی نام مقصد فقط در DNS شبکه دور وجود دارد، ماشینی که جستجو را انجام می‌دهد باید آن ناحیه را ببیند. پروکسی وب خودش جستجو را انجام می‌دهد، پس نام داخلی از طریق آن کار می‌کند حتی وقتی لپ‌تاپ اصلا نمی‌تواند نام را حل کند. SOCKS هم می‌تواند همین رفتار را داشته باشد، اما فقط اگر کلاینت نام را جلو بفرستد، نه اینکه به نشانی که قبلا حل کرده وصل شود. این انتخاب در کلاینت است، نه در سرور.
curl شکاف را روشن نشان می‌دهد: یک پرچم نام میزبان را به پروکسی می‌سپارد، دیگری آن را اول به‌صورت محلی حل می‌کند. با حل محلی، نامی که فقط داخلی است پیش از لمس هر تونلی شکست می‌خورد و خطا پروکسی را برای چیزی سرزنش می‌کند که در واقع تصمیم DNS بود.
VPN راه سوم را می‌رود: حل‌کننده خصوصی و دامنه جستجو را کنار مسیرها نصب می‌کند. این راحت است و توهمی آشنا می‌سازد: مسیری که با حل‌کننده‌ای که پاسخ نمی‌دهد وجود دارد دقیقا مثل تونل مرده به نظر می‌رسد، هرچند بسته‌ها به آن سو می‌رسند.
وقتی شبکه فقط یک خروجی را مجاز می‌کند
بسیاری از شبکه‌های شرکتی اتصال‌های خروجی را فقط از طریق یک پروکسی وب احراز هویت‌شده مجاز می‌کنند. OpenVPN و SSH هر دو می‌توانند آنجا کار کنند، اولی با تونل کردن انتقال خودش از پروکسی و دومی با فرمان پروکسی که یک کمک‌کننده کوچک CONNECT اجرا می‌کند.
تونل‌های مبتنی بر TCP از این محدودیت جان سالم به در می‌برند و VPN مبتنی بر UDP نه، که بسیاری از پیکربندی‌هایی را توضیح می‌دهد که در خانه کار می‌کنند و در دفتر شکست می‌خورند. هزینه دومی به‌راحتی از چشم می‌افتد: تونل TCP که درون یک اتصال TCP پروکسی‌شده حمل می‌شود اکنون دو لایه بازفرست دارد و زیر افت، این جفت به شکلی متوقف می‌شود که هیچ لایه‌ای به‌تنهایی تولید نمی‌کند.
زنجیره کردن واسطه‌ها پرسشی متفاوت از انتخاب لایه است. افزودن پروکسی دوم یا Tor تغییر می‌دهد چه کسی چه چیزی را مشاهده می‌کند و جایگاه در زنجیره تعیین می‌کند کدام گام متن رمزشده را می‌بیند.
ترتیب از تعداد گام‌ها مهم‌تر است. گام بیرونی جریان رمزشده را می‌بیند در حالی که گام درونی متن روشنی را که حمل می‌کند می‌بیند، پس زنجیره تنها به اندازه بی‌توجه‌ترین حلقه‌اش خصوصی است. آمیختن پروتکل‌ها در گام‌ها این را خودکار بهتر نمی‌کند. بیشتر حالت‌های خرابی را سخت‌تر برای استدلال می‌کند.
نشانی جعلی یکی از گزینه‌ها نیست
ساختن بسته‌ها با نشانی مبدا شخص دیگری هیچ سودمندی ندارد: پاسخ‌ها به صاحب واقعی می‌روند و بیشتر شبکه‌ها ترافیک را کلا دور می‌ریزند. واسطه دقیقا لازم است چون مبدا را نمی‌توان از خود درآورد، و این توجیه صادقانه هر سه طرح است.
همچنین محدود می‌کند که هر یک چه ادعایی می‌تواند داشته باشد. به نظر رسیدن اینکه از نشانی خاصی می‌آید پرسشی است درباره اینکه آن نشانی به‌طور قانونی کجا تخصیص یافته و چه کسی می‌تواند آن را مسیریابی کند، نه درباره اینکه کدام ابزار می‌تواند سرصفحه را جعل کند. اگر طرحی خلاف این را فرض کند، فرض در اولین ارائه‌دهنده‌ای که آن را فیلتر می‌کند شکست می‌خورد. فرض را بنویسید تا خرابی هنگام رسیدن قابل تشخیص باشد.
بر اساس پروتکل‌ها و نام‌ها تصمیم بگیرید
وقتی یک کلاینت وب به یک سرویس وب نیاز دارد و تنظیم پروکسی دارد، پروکسی را انتخاب کنید. وقتی چند سرویس TCP شناخته‌شده کافی است و دسترسی SSH از قبل وجود دارد، تونل SSH را انتخاب کنید. وقتی چند برنامه، ترافیک غیر TCP، DNS خصوصی یا مسیری قابل استفاده مجدد بخشی از نیاز است، VPN را انتخاب کنید.
سپس با کلاینت واقعی و نام واقعی بررسی کنید. بارگذاری صفحه از طریق پروکسی چیزی درباره UDP به شما نمی‌آموزد و کار انداختن یک ابزار روی SOCKS چیزی درباره حل‌کننده سیستم نمی‌آموزد. بخوانید فرایند به کدام نشانی محلی بسته شد و کدام حل‌کننده پاسخ داد. این تفاوت میان مسیری است که کار می‌کند و مسیری که یک بار تصادفی کار کرد.