سرور VPN خانگی در دسترس نیست: زنجیره NAT را گامبهگام طی کنید
روتر، مترجم ارائهدهنده و شنونده سرور سه مرز جداگانهاند. پیش از بازنویسی همان قاعده ارسال، از صفحه مدیریت به سمت بیرون حرکت کنید.
سرور در LAN پاسخ میدهد، قاعده ارسال پورت درست به نظر میرسد و با این حال یک کلاینت بیرونی نمیتواند متصل شود. عبور یکبهیک از مرزها به سمت بیرون از ویرایش چهارم همان قاعده سریعتر است، چون هر مرز شاهد خودش را بر جای میگذارد: صفحه WAN روتر، ترجمه ارائهدهنده و شنونده روی میزبان. از صفحه مدیریتی که همین حالا باز است شروع کنید و با آزمونی از شبکهای که آن را کنترل نمیکنید تمام کنید. هر نتیجه را همانجا بنویسید، چون توالی همان تشخیص است و عددی که به یاد مانده شاهد نیست. اگر فقط یک تونل خروجی میخواهید، ترجمه مشکل شما نیست: تنها ترافیک ورودی ناخواسته مسدود میشود.
از صفحه WAN روتر شروع کنید
به روتر وارد شوید و صفحه وضعیت را بخوانید، نه فهرست ارسال پورت. نشانی WAN، واسطی که به آن تعلق دارد و اینکه نوع اتصال DHCP، PPPoE یا چیزی است که ارائهدهنده تأمین میکند را یادداشت کنید. سپس آن نشانی را با آنچه یک سرویس بیرونی گزارش میکند مقایسه کنید و از تلفنی با داده همراه استفاده کنید تا مشاهده از همان روتر بازنگردد. این دو عدد به پرسشهای متفاوتی پاسخ میدهند و مقایسه آنها تمام هدف این گام است.
نشانی WAN که با نشانی عمومی مشاهدهشده تفاوت دارد یعنی دستکم یک مترجم بالای روتر قرار دارد. این هنوز نقص نیست، چون بسیاری از ارائهدهندگان بهطور طراحیشده ترجمه میکنند و سرویس همچنان کار میکند. اگر این دو یکسان باشند، احتمالاً نشانی از آنِ روتر است و مشکل به داخل شبکه شما منتقل شده است. در هر حال جفت را با تاریخ بنویسید، چون ارائهدهندگان نشانیها را دوباره تخصیص میدهند و مقایسه با یادداشتهای ماه گذشته بیارزش است.
یک گام به بالا بروید
traceroute را از خود روتر اجرا کنید و چند گام نخست را بخوانید. نشانیهای عمومی تکراری، گامی نخست که با نشانی خصوصی پاسخ میدهد یا نشانیای در محدوده مشترک 100.64.0.0/10 همه به مترجمی در بالادست اشاره میکنند. RFC 6598 همان محدوده را دقیقاً برای چنین استقراری تعریف میکند و به همین دلیل دیدن آن در فیلد WAN نشانهای قوی است نه کنجکاوی. دو مترجم در مسیر رد را کموضوحتر میکند، پس الگو را بخوانید نه یک خط تنها.
برخی ارائهدهندگان نشانی تخصیصیافته را فقط در درگاه مشتری نشان میدهند، پس پیش از آنکه نتیجه بگیرید روتر دروغ میگوید، آنجا را ببینید. نشانی درگاه که با مشاهده بیرونی شما میخواند در حالی که روتر چیز دیگری گزارش میکند روشنترین شاهد وجود مترجم بالادست است. هر دو صفحه را در سابقه تغییرات نگه دارید، چون بحث بر سر اینکه کدام مرز از آنِ کیست با دو تصویر تاریخدار بسیار سریعتر پیش میرود.
شنونده و قاعده ارسال را تأیید کنید
آزمون در LAN ثابت میکند سرویس بهصورت محلی کار میکند و درباره دسترسی از بیرون چیزی ثابت نمیکند. بسیاری از روترها به قاعده ارسال خودشان از درون پاسخ میدهند، بنابراین آزمون حلقه موفق میشود در حالی که مسیر بیرونی هنوز بسته است. تأیید کنید که سرویس به همان نشانی و پورتی که گمان میکنید بسته شده است و سپس از بیرون آزمون کنید. همه موارد زیر فقط خواندنی است.
ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1
اگر آزمون بیرونی نشان دهد هیچ بستهای به روتر نمیرسد، حذف در بالادست رخ داده و هیچ قاعده محلی آن را درست نمیکند. اگر بستهها میرسند و چیزی پاسخ نمیدهد، مرز بعدی شنونده یا فایروال میزبان است. گرفتن بسته روی میزبان روشن میکند کدامیک از این دو را میبینید و از دور دیگری حدس زدن قاعده کمتر وقت میگیرد. هنگام مقایسه شنونده و لایه انتقالش را بدون تغییر نگه دارید، وگرنه آزمون بعدی به پرسش دیگری پاسخ میدهد.
توپولوژی را عوض کنید، نه همان قاعده را
وقتی مترجم از آنِ ارائهدهنده است، راهحل مسیری دیگر است نه یک ارسال دیگر. یک VPS کوچک با نشانی عمومی که از سمت خانه با تونل خروجی وصل میشود، نقطه پایانی در دسترس را جلوی سرویس میگذارد. نشانی عمومی که ارائهدهنده میدهد در جایی که وجود دارد سادهتر و معمولاً ارزانتر از نگهداری یک ماشین است. IPv6 ترجمه را کاملاً حذف میکند، به شرط آنکه شبکه کلاینت، رکوردهای DNS و سیاست فایروال همه از آن پشتیبانی کنند.
DNS پویا فقط یک نام را بهروز میکند؛ دسترسپذیری نمیسازد و اشاره آن به نشانی مشترک کلاینتها را به درگاه ارائهدهندهای میفرستد که مشترکان دیگر هم از آن استفاده میکنند. آن شکست دقیقاً مانند سرور مرده به نظر میرسد و به همین دلیل سابقه گامهای پیشین مهم است. بنویسید نام هنگام شکست آزمون به کدام نشانی تبدیل شد و پاسخ را همراه نتیجه آزمون نگه دارید.
طرح را حول مرزی که کنترل میکنید بازنویسی کنید: شنونده، تونل و مسیرها. قاعده ارسال قدیمی را فقط تا زمانی نگه دارید که هنوز چیزی درست را توصیف میکند، چون قاعدهای که دیگر با توپولوژی نمیخواند بدتر از نبودن قاعده است. بنویسید کدام لایه واقعاً مسدود میکرد و چه شاهدی آن را نشان داد. وگرنه نفر بعدی که صفحه مدیریت را باز میکند هر گام این مسیر را از ابتدا تکرار خواهد کرد.