چگونه یک سرور توسعه webpack را روی یک نشانی VPN سرویس دهیم

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

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

با سوکت شروع کنید، نه با فایل پیکربندی

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

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

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

نشانی اتصال را بر اساس اینکه چه کسی باید به آن برسد انتخاب کنید

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

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

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

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

نشانی در آن قطعه نمونه است و نماینده نشانی VPN است که میزبان مالک آن است. اگر پروژه سرور را با new WebpackDevServer(options, compiler) می‌سازد، گزینه‌ها را به‌جای آن از طریق آرگومان سازنده منتقل کنید، زیرا ویژگی جداگانه devServer در پیکربندی webpack در آن مسیر بررسی نمی‌شود. این تفاوت میان فایل پیکربندی و Node API کسانی را می‌گیرد که قطعه‌ای را در پروژه‌ای کپی می‌کنند که هرگز آن را نمی‌خواند. مستندات dev-server دو سبک راه‌اندازی را جدا می‌کند و مرجعی است که نسخه در حال استفاده باید با آن بررسی شود.

بررسی نام میزبان را با نام‌هایی که تأیید می‌کنید هماهنگ کنید

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

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

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

صفحه و سوکت بارگذاری مجدد زنده را با هم بررسی کنید

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

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

نشانی شنونده، نام پذیرفته‌شده، منبع مجاز و هر دو نتیجه را در یادداشت‌های پروژه ثبت کنید. آن ثبت برای نفر بعدی می‌ماند که فضای کاری را راه‌اندازی می‌کند و شگفت‌زده می‌شود چرا صفحه بار می‌شود اما هرگز تازه نمی‌شود.