چرا یک VPN فعال باز هم در پاسخ به پایان مهلت می‌رسد
رسیدن درخواست به یک سرور خصوصی تنها نیمی از تبادل است. پاسخ آن باید کلاینت تونل را از طریق دروازه، مسیر یا ترجمهٔ مورد نظر پیدا کند.
درخواست می‌رسد، سرور آن را ثبت می‌کند و کلاینت همچنان از پایان مهلت خبر می‌دهد. این ترکیب یعنی پاسخ راه بازگشت خود را پیدا نکرده است، و این یکی از معدود خرابی‌هایی است که می‌توانید هم‌زمان از دو سر تأیید کنید. بررسی‌ها را به ترتیب انجام دهید و هر جا یکی شکست خورد بایستید.
از جایی شروع کنید که درخواست رسیده است
پیش از بررسی هر چیز دیگری تأیید کنید که بسته به سرویس رسیده است. یک رکورد در گزارش سرور، یک شمارندهٔ اتصال یا یک ضبط مجاز در سر دور، همه به یک پرسش پاسخ می‌دهند، و نبودشان شما را به تونل برمی‌گرداند نه به سمت پاسخ. این همان بررسی است که مشکل ارسال را از مشکل مسیر بازگشت جدا می‌کند.
اگر درخواست هرگز نرسیده است، همین‌جا بایستید. تونل، مسیریابی به پیشوند خصوصی یا قاعدهٔ دسترسی موضوع است و مسیر پاسخ هنوز مرتبط نیست. نشانی مبدأیی را هم که سرور دیده است یادداشت کنید. این یا نشانی استخر است که به کلاینت داده شده یا نشانی ترجمه‌شده، و همین تفاوت تعیین می‌کند کدام یک از بررسی‌های بعدی اعمال می‌شود.
پاسخ به مسیری به سمت استخر نیاز دارد
کلاینت دسترسی از راه دور معمولاً نشانی‌ای از یک استخر می‌گیرد و شبکهٔ خصوصی به مسیری بازگشتی به آن استخر نیاز دارد. سروری که مسیر پیش‌فرضش به دروازهٔ خودش اشاره می‌کند بسته را به همان دروازه می‌دهد، که هیچ تصوری از محل استخر ندارد، پس پاسخ همان‌جا می‌میرد. کلاینت پایان مهلت می‌بیند چون چیزی برنگشته است، و این از درخواستی که هرگز خارج نشده قابل تشخیص نیست.
مسیری را بررسی کنید که سرور برای نشانی کلاینت انتخاب می‌کند، نه مسیری که برای زیرشبکهٔ خودش به کار می‌برد. این دو جست‌وجو می‌توانند پاسخ‌های متفاوتی بدهند و دومی همان است که اینجا اهمیت دارد. ترجمه طرح جایگزین است و آنچه سرور می‌بیند را تغییر می‌دهد. می‌تواند مسیر بازگشت را ساده کند و همچنین نشانی اصلی کلاینت را از گزارش‌های سرور حذف می‌کند، که بر هر قاعده یا گزارشی ساخته‌شده بر آن فیلد اثر می‌گذارد.
ضبط سرور را با ضبط دروازه مقایسه کنید
آنچه از سرور خارج می‌شود را با آنچه به دروازه می‌رسد مقایسه کنید. ضبط روی رابط خروجی سرور و ضبط روی دروازهٔ تونل به دو نیمهٔ متفاوت پرسش پاسخ می‌دهند و شکاف میان آن‌ها محل افت را مشخص می‌کند.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
درخواستی که خود دروازه تولید می‌کند جانشین ضعیفی برای آزمون کلاینت است، چون از نشانی دیگری سرچشمه می‌گیرد و به قواعد دیگری برمی‌خورد. به همین دلیل ping موفق از دروازه و درخواست ناموفق از کلاینت می‌توانند هم‌زمان درست باشند.
وقتی چند مسیریاب روی مسیر قرار دارند، هر کدام را که به مسیری به سمت استخر نیاز دارد بررسی کنید. طراحی سایت به سایت اغلب می‌خواهد پیشوند دور در بیش از یک دستگاه شناخته شود، و خود دروازه باید میان تونل و شبکهٔ محلی ارسال کند؛ یادداشت‌های strongSwan دربارهٔ ارسال جنبهٔ sysctl و دیوار آتش آن را پوشش می‌دهند.
استخر، پیشوند و مالک را ثبت کنید
چهار واقعیت به یادداشت تعلق دارد: استخری که کلاینت گرفت، پیشوند خصوصی که لازم داشت، مسیریابی که مسئول پاسخ است، و قاعدهٔ ترجمه اگر وجود دارد. با این‌ها، تغییر بعدی دروازه یک مقایسه است نه یک بررسی.
سپس با یک کلاینت معمولی و حساب واقعی برنامه دوباره آزمون کنید. گستردن اختیارات برنامه نمی‌تواند مسیر بازگشت بسته را ترمیم کند، و تغییر حساب در طول این عیب‌یابی مقایسهٔ بعدی را گیج می‌کند. اگر طرح به ترجمه تکیه دارد، آن را همان‌جا مستند کنید که گزارش‌های سرور خوانده می‌شوند. کسی که نشانی مبدأ ناآشنایی را در رد حسابرسی می‌بیند نباید نگاشت را از یک تیکت از نو کشف کند.