چرا زیرشبکه پشت یک کلاینت OpenVPN قابل دسترسی نیست؟

پینگ به آدرس تونل سرور موفق می‌شود، جدول مسیر خود کلاینت درست به نظر می‌رسد، و LAN پشت آن کلاینت هنوز در دسترس نیست. جدول مسیریابی کلاینت درست به نظر می‌رسد، سرور مسیری به سمت تونل دارد، و بسته‌ها همچنان ناپدید می‌شوند. این نشانه کلاسیک یک تونل layer-3 است که نمی‌داند یکی از کلاینت‌هایش خودش یک دروازه است.

یک رابط tun هیچ گام بعدی به‌ازای هر کلاینت ندارد. هسته یک رابط با همتاهای زیاد می‌بیند، بنابراین تصمیم درباره اینکه کدام کلاینت باید بسته‌ای برای یک LAN راه‌دور دریافت کند باید درون فرایند OpenVPN گرفته شود. آن تصمیم با iroute پیکربندی می‌شود و بدون آن بسته جایی برای رفتن ندارد.

سرور بر اساس کلاینت مسیریابی می‌کند، نه بر اساس رابط

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

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

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

نوشتن ورودی iroute که کلاینت را نام می‌برد

iroute در فایل پیکربندی مخصوص کلاینت زندگی می‌کند، نه در پیکربندی اصلی سرور. سرور را با گزینه client-config-dir به یک پوشه اشاره دهید، سپس فایلی بسازید که نامش نام مشترک گواهی کلاینت است و پیشوند را درون آن بگذارید.

برای شاخه‌ای که LAN آن 10.20.0.0/24 است و نام مشترک گواهی‌اش branch-router است، فایل در آن مسیر خطی مانند iroute 10.20.0.0 255.255.255.0 دارد. پیکربندی اصلی فقط به گزینه پوشه نیاز دارد؛ پیشوند نزد کلاینت زندگی می‌کند.

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

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

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

رساندن بسته‌ها به LAN راه‌دور نیمی از کار است. کلاینت باید ترافیک آن LAN را نیز به تونل بفرستد، که معمولاً با هل دادن یک مسیر به کلاینت انجام می‌شود: خطی مانند push "route 10.8.0.0 255.255.255.0" به هر کلاینت می‌گوید چگونه به شبکه سمت سرور برسد. برای شاخه، مسیر معادل به تونل اشاره می‌کند برای هر چیزی که باید در سمت سرور به آن برسد.

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

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

بررسی دسترسی با کاوشگرهای درست

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

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

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