کلاینت‌های VPN به سرور می‌رسند ولی به LAN نه: کدام راه‌حل؟

کلاینت به نشانی تونل سرور OpenVPN ping می‌زند و پاسخ می‌گیرد، سپس میزبان داخل LAN سرور را امتحان می‌کند و چیزی نمی‌گیرد. همین شکاف خطا را بسیار محدود می‌کند: تونل برپاست، ارسال احتمالاً کار می‌کند و پاسخ از دری بیرون می‌رود که بازگشتی ندارد. سه راه‌حل وجود دارد و راه درست بستگی دارد به اینکه چه چیزی را کنترل می‌کنید و از چه چیزی حاضرید بگذرید. به سه پرسش زیر به ترتیب پاسخ دهید تا انتخاب دیگر مسئله سلیقه نباشد.

نخست روشن کنید کدام جهت خراب است

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

پیش از تغییر هر یک، هر دو ماشین را بیازمایید. از سرور بپرسید جدولش از چه راهی به کلاینت می‌رسد؛ از میزبان داخل LAN بپرسید چگونه به همان نشانی می‌رسد. جست‌وجوی اول معمولاً به تونل اشاره می‌کند و دوم به مسیریاب LAN، و همین تفاوت خطا در یک خط است. دو جست‌وجو ارزان‌تر از ممیزی دیوار آتش است و جهت مشکل را روشن می‌کند.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

پرسش یکم: آیا می‌توانید مسیریاب LAN دور را ویرایش کنید؟

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

روزی که کسی استخر را تغییر دهد، بی‌صدا شکست می‌خورد. مقدار را یک بار بنویسید و هر تغییر در یکی از سه جا را تغییر در هر سه بدانید.

NAS یا سوئیچ Layer 3 که سرویس را میزبانی می‌کند به همان مسیر نیاز دارد، مگر آنکه همه چیز را از مسیریابی بفرستد که آن را دارد. دستگاهی را بررسی کنید که زیرشبکه را پایان می‌دهد، نه فقط آن یکی که رو به اینترنت است. شبکه‌های کوچک اغلب سه دستگاه با نظر درباره مسیریابی دارند.

پرسش دوم: آیا LAN می‌تواند نشانی کلاینت‌ها را دیگر نبیند؟

وقتی مسیریاب مال کس دیگری است، ترجمه روی سرور VPN به همکاری نیاز ندارد. میزبان داخل LAN نشانی LAN سرور را می‌بیند، به آن پاسخ می‌دهد و سرور بازترجمه می‌کند. به همین دلیل لوازم و نقش‌های دسترسی دور مبتنی بر NAT این‌گونه رفتار می‌کنند.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

بهای آن انتساب است: نشانی‌های هر کلاینت از گزارش‌های LAN ناپدید می‌شوند. آن‌گاه هر فهرست مجاز روی میزبان داخل LAN باید سرور را به‌جای استخر نام ببرد.

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

پرسش سوم: آیا سرور خودش کلاینت تونل دیگری است؟

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

سپس هر دو جهت و هر دو اندازه را بررسی کنید

پس از تغییر، از کلاینت به یک میزبان در LAN و سپس از میزبان در LAN به کلاینت ping بزنید. جهت دوم همان است که مردم از آن می‌گذرند و همان است که قاعده ترجمه ناقص را آشکار می‌کند. هر دو نتیجه را با مهر زمان ثبت کنید تا پسرفت بعدی قابل مقایسه باشد.

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

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