VPN روشن است و localhost از کار می‌افتد: نام، پروکسی یا اتصال؟

سرور توسعه شما یک دقیقه پیش پاسخ داد، و حالا که تونل بالا است درخواست با نام میزبانی که هرگز تایپ نکردید به پایان مهلت می‌رسد. دو سازوکار تقریباً همه موارد را توضیح می‌دهند و از بیرون یکسان به نظر می‌رسند. پسوند جست‌وجو یک نام کوتاه را به نام شرکتی تبدیل می‌کند، در حالی که پروکسی ترافیک loopback را به میزبانی می‌فرستد که نمی‌تواند به آن برسد. جدا کردن این دو یک پرس‌وجو هزینه دارد و قاعده فایروالی را که در آستانه نوشتنش بودید ذخیره می‌کند.

وقتی localhost به منطقه شرکتی حل می‌شود

بررسی کنید که نام در حالی که تونل بالا است به چه چیزی resolve می‌شود، سپس همان پرس‌وجو را با تونل پایین اجرا کنید و دو پاسخ را مقایسه کنید. نشانه، نشانی در محدوده شرکتی است جایی که انتظار 127.0.0.1 را داشتید. رکوردی مانند localhost.mycompany.corp به محض اینکه کلاینت آن پسوند را به فهرست جست‌وجو اضافه کند بر ورودی loopback پیروز می‌شود، و درخواست به میزبان خصوصی‌ای می‌رود که چیزی روی آن پورت گوش نمی‌دهد. فهرست جست‌وجو را بخوانید نه اینکه حدس بزنید، چون کلاینت می‌تواند بیش از یک دامنه اضافه کند و ترتیب تعیین می‌کند کدام نامزد اول امتحان شود:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

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

تنظیمات پروکسی که loopback را می‌گیرند

پروکسی سیستمی که هنگام بالا آمدن تونل اعمال می‌شود درخواستی به 127.0.0.1 را می‌پذیرد و آن را به پروکسی راه دوری می‌فرستد که هیچ ایده‌ای ندارد منظور شما چه بود. فهرست استثنای خالی یک درخواست محلی را به یک درخواست راه دور تبدیل می‌کند، و پیام خطا به‌ندرت این را می‌گوید. نشانی‌های loopback را برای کل نشست و نه برای یک فرمان، به فهرست استثنا اضافه کنید، سپس پیش از نتیجه‌گیری درباره شبکه تأیید کنید که ابزار آن را رعایت می‌کند.

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

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

نشانی اتصال تعیین می‌کند چه کسی می‌تواند وصل شود

سروری که روی 127.0.0.1 شروع می‌شود فقط اتصال‌های همان دستگاه را می‌پذیرد، که معمولاً پیش‌فرض درست برای توسعه است. سرور روی 0.0.0.0 روی هر رابط از جمله آداپتور VPN پاسخ می‌دهد، که بیش از آن چیزی است که بیشتر مردم قصد دارند. وقتی نشانی تحت‌اللفظی loopback شکست می‌خورد، پیش از هر چیز اتصال را بررسی کنید.

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

جایی که ابزار اشکال‌زدایی انتظار LAN دارد

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

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

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

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

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