چرا نشانی تونل VPN شما پورت ورودی باز نمیکند
نشانی تونل مشتری شما را به همتایانی که میتوانند به آن مسیریابی کنند معرفی میکند و هرگز شنونده نمیسازد. اتصال، مسیر بازگشت و سپس سیاست را بررسی کنید.
به VPN اداره وصل شوید، سرویس کوچکی روی پورت 8443 اجرا کنید، نشانی تونل را برای همکاری بفرستید و ببینید که اتصال شکست میخورد در حالی که مشتری همچنان متصل بودن را گزارش میکند. هیچ چیزی در تونل خراب نیست: نشانی تخصیص یافته، نشست برقرار است و بستههایی که پاسخ را حمل میکردند هرگز پذیرفته نمیشوند. سه بررسی زیر را به ترتیب انجام دهید و روی همانی که شکست میخورد بایستید، چون هرکدام راهحل متفاوتی دارند و تنها یکی از آنها مربوط به VPN است.
از جایی شروع کنید که سوکت واقعاً به آن متصل است
پیش از آنکه چیزی مسیریابی شود، چیزی باید روی نشانی گوش دهد که فراخواننده بتواند به آن برسد. سرورهای توسعه معمولاً مقصرند، چون بسیاری از آنها بهطور پیشفرض به loopback متصل میشوند و تنها اتصالهایی را میپذیرند که از همان ماشین میآیند. نشانی تونل این اتصال را تغییر نمیدهد و سیستمعامل خیلی پیش از آنکه VPN دخیل شود اتصال را رد میکند.
ss -ltnp | grep 8443
netstat -ano | findstr 8443ستون نشانی محلی را بخوانید نه وضعیت را. 127.0.0.1:8443 یعنی تنها loopback، و راهحل اتصال به 0.0.0.0 یا به خود نشانی تونل است. 0.0.0.0:8443 روی همه رابطها میپذیرد، که گستردهتر از آن است که بیشتر مردم در نظر دارند وقتی ماشین نشانی عمومی هم دارد؛ 10.64.7.15:8443 نسخه باریکی است که تنها جایی گوش میدهد که همکار میتواند برسد. نام فرایند را هم در همان خروجی ببینید، چون نمونهای سرگردان از یک آزمون پیشین دلیل رایجی است که پورت باز به نظر میرسد و با محتوای اشتباه پاسخ میدهد.
سپس بپرسید آیا چیزی میتواند به آن نشانی مسیریابی کند
نشانی تونل تنها برای همتایانی معنا دارد که برای فرستادن آن پیشوند به داخل تونل پیکربندی شدهاند. ماشین همکار جدول خودش را دارد و اگر مسیری برای زیرشبکه تونل نداشته باشد، بسته به دروازه پیشفرض میرود و در جایی میمیرد که هیچ اطلاعی از وجود نشانی ندارد. این پرسشی از جنس مسیریابی در سمت فراخواننده است، نه اجازهای در سمت شما.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
سرور میان دو مشتری هم به همان اندازه مهم است. در طراحی رایج دسترسی از راه دور، هر مشتری اتصال خروجی به دروازه باز میکند و دروازه وضعیت آن جریانها را نگه میدارد، بنابراین پاسخها از مسیری برمیگردند که از پیش میشناسد. اتصال از یک مشتری به مشتری دیگر جریان تازهای است که دروازه باید بپذیرد و هدایت کند، و بسیاری از استقرارها آن را آگاهانه غیرفعال میکنند تا مشتریها از یکدیگر جدا بمانند. سرویسهای VPN مصرفی معمولاً بهطور پیشفرض جداسازی میکنند؛ دروازههای سازمانی گاهی آن را برای هر گروه مجاز میکنند.
پیش از تغییر چیزی روی میزبان، جهت را بررسی کنید. اگر نشانی تونل از خود دروازه پاسخ میدهد اما از یک همتا نه، تفاوت در تنظیم مشتری-به-مشتری دروازه است و هیچ ویرایشی در دیوار آتش محلی جای آن را نمیگیرد.
در پایان، سیاستی را پیدا کنید که جریان را مجاز میکند
سه لایه سیاست میان بسته مسیریابیشده و سرویسی که پاسخ میدهد قرار دارد: تصمیم هدایت سرور VPN، دیوار آتش میزبان و هر گروه امنیتی ابری پیش از نمونه. هر سه باید هماهنگ باشند و هرکدام به شکلی متفاوت شکست میخورند، به همین دلیل نشانه موجود در جدول بالا از پیام خطای مرورگر سودمندتر است.
دیوار آتش میزبان همان لایهای است که مردم پس از یک اتصال موفق فراموش میکنند، چون قاعدهای که پورت را روی رابط LAN مجاز میکند بهطور خودکار آن را روی رابط تونل مجاز نمیکند. قواعد محدود به رابط طراحی درستی هستند و در عین حال دلیل رایج سرویسی هستند که از اداره کار میکند و از خانه نه. دامنه قاعده را بخوانید نه شماره پورت آن را.
فیلتر کردن مبتنی بر وضعیت حالت عکس را توضیح میدهد. اتصال خروجی از لپتاپ شما وضعیت میسازد و پاسخهای آن بدون قاعده ورودی پذیرفته میشوند. اتصال همکار جریانی کاملاً تازه است که وضعیتی پشت آن نیست، پس به اجازه صریح نیاز دارد. همین ناهمسانی تمام دلیل آن است که یک نشست مرورگر سالم روی ماشین خودتان هیچ چیزی درباره دسترسپذیری سرویس از بیرون نمیگوید.
وقتی یک بررسی شکست میخورد، طراحی را تغییر دهید نه تونل را
اگر خواسته این است که همکاری سرویس محلی شما را باز کند، پاسخ صادقانه معمولاً سازوکاری است که برای دسترسی ورودی ساخته شده است. یک تونل SSH معکوس کوچکترین آنهاست: ماشین شما بهصورت خروجی به میزبانی وصل میشود که همکار از پیش میتواند به آن برسد و شنونده روی همان میزبان وجود دارد.
ssh -N -R 8443:127.0.0.1:8443 [email protected]رله به GatewayPorts clientspecified در پیکربندی سرور SSH خود نیاز دارد، وگرنه شنونده هدایتشده روی رله به loopback متصل میشود و همکار با همان رد شدن پیشین روبهرو میشود. برای هر چیزی که بیش از یک بعدازظهر دوام بیاورد، متعادلکننده بار یا ingress با بررسی سلامت و گواهی برای نام منتشرشده ابزار بهتری است، و تونل سایت-به-سایت با مسیرهایی برای هر دو زیرشبکه پاسخ درست است وقتی دو شبکه واقعاً باید با هم صحبت کنند.
هر یک از این طراحیها مواجهه را صریح میکند و نکته همین است. VPN بستهها را میان شبکههایی جابهجا میکند که از پیش مجاز به استفاده از آنها بودید؛ سرویسی منتشر نمیکند و لپتاپ را به میزبانی رو به اینترنت تبدیل نمیکند. تصمیم درباره اینکه کدام یک از سه لایه را تغییر دهید کار اصلی است و تونل بهندرت یکی از آنهاست.