کاربر دروازه در Access Server: مسیریابی LAN شعبهٔ یک کلاینت

می‌توانید نشانی تونل یک کلاینت OpenVPN را ping کنید و همچنان به هیچ میزبانی روی LAN پشت آن نرسید. Access Server به آن کلاینت نشانی‌ای از استخر VPN می‌دهد و نشانی استخر تنها چیزی است که سرور آن را متعلق به خود می‌داند. پیشوند شعبه واقعیتی جداگانه است که باید اعلام شود، و حتی پس از آن شعبه به یک ارسال‌کننده و دفتر مرکزی به مسیر بازگشت نیاز دارد. مسیری که در جای اشتباه تایپ شود شبیه راه‌حل است و چیزی را تغییر نمی‌دهد.

دو نشانی، دو ادعای مالکیت متفاوت

وقتی کلاینت متصل می‌شود، Access Server نشانی‌ای از استخر VPN پیکربندی‌شده به آن می‌دهد، مثلاً 10.90.0.0/24. این تخصیص اجاره‌ای برای یک میزبان است. هیچ چیز در اتصال نمی‌گوید همان کلاینت جلوی 10.60.0.0/24 هم قرار دارد، و سرور حدس نمی‌زند: پیشوند LAN فقط از طریق کلاینتی مشخص در دسترس است اگر مدیر آن را اعلام کند.

به همین دلیل یک مسیر ایستا روی ماشین دیگر کار نمی‌کند. مسیر می‌گوید 10.60.0.0/24 را به این نشانی بفرست، اما اگر نشانی از کلاینتی باشد که هرگز به‌عنوان دروازه علامت نخورده، سرور دلیلی برای تحویل آن بسته‌ها به آنجا ندارد و پشتهٔ خود کلاینت ممکن است آن‌ها را دور بیندازد. اعلام و مسیر دو نیمه از یک سازوکارند.

تنظیم دروازه در واقع چه چیزی نصب می‌کند

در Admin Web UI اعلام یک ویژگی کاربر است: Configure VPN gateway را روی کاربر اتصال‌دهنده فعال کنید و پیشوند واقعی شعبه را در Network on the VPN client side وارد کنید. این کاربر مانند هر کاربر دیگری احراز هویت می‌شود، پس به سیاست اعتباری مناسب دستگاهی بدون نظارت نیاز دارد و نمایهٔ ورود خودکار آن یک راز است، نه فایل آسایش.

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

یک دستور به سبک Community که در فایل تولیدشده جای‌گذاری شود در این مدل مشارکت نمی‌کند. محصول مالک جدول مسیریابی‌ای است که ارسال می‌کند؛ خطی که دستی ویرایش شود در تولید بعدی بازنویسی یا نادیده گرفته می‌شود.

مسیرهای بازگشت هر دو شبکه را کامل کنید

یک طرح مشخص: دفتر مرکزی 10.40.0.0/24، شعبه 10.60.0.0/24، استخر VPN 10.90.0.0/24، و Access Server در نشانی خصوصی در سمت دفتر مرکزی. روتر دفتر مرکزی به مسیرهایی برای پیشوند شعبه و برای استخر نیاز دارد، هر دو به سمت Access Server. بدون آن‌ها تونل درخواست را می‌برد و پاسخ از دروازهٔ پیش‌فرض خارج می‌شود، که همان اتصال نیمه‌باز کلاسیک را می‌سازد.

در شعبه اتصال‌دهنده باید بسته‌هایی را که به خودش نشانی نشده‌اند ارسال کند: ارسال IP در سیستم‌عامل آن به‌همراه اجازهٔ ارسال محدود به رابط‌های تونل و LAN؛ در Linux همان net.ipv4.ip_forward=1 همراه با قواعد زنجیرهٔ forward است، در Windows همان routing and remote access. سپس میزبان‌های شعبه به مسیر بازگشت نیاز دارند: یا اتصال‌دهنده دروازهٔ پیش‌فرض آن‌هاست، یا دروازهٔ موجود مسیرهای مشخص برای پیشوندهای دفتر مرکزی و استخر را حمل می‌کند.

جدول مسیریابی خود اتصال‌دهنده هر میزبان روی LAN شعبه را بازپیکربندی نمی‌کند. اگر میزبان‌ها به روتر دیگری اشاره کنند، مسیرهای بازگشت همان‌جا هستند و آن روتر باید بپذیرد که نشانی مبدأیی که می‌بیند همسایهٔ زیرشبکهٔ محلی نیست.

شکست را به‌عنوان مسیر بخوانید، نه اجازه

به ترتیبی ثابت آزمایش کنید. نخست یک سرویس مجاز از Access Server به میزبان شعبه، سپس همان سرویس از میزبان عادی دفتر مرکزی، سپس جهت معکوس اگر سیاست اجازه دهد. اگر اولی بگذرد و دومی شکست بخورد، مسیرهای ارسال‌شده یا قواعد دسترسی مشکل‌اند. اگر هر دو بگذرند اما پاسخی نرسد، ارسال در شعبه و مسیر بازگشت در دفتر مرکزی را بررسی کنید.

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

دو طرح بیش از این الگو می‌خواهند. پیشوندهای هم‌پوشان میان سایت‌ها مقصد را مبهم می‌کنند و به شماره‌گذاری مجدد یا ترجمه نیاز دارند، و Access Server خوشه‌ای لازم است هر گره مسیری کارا به اتصال‌دهندهٔ شعبه داشته باشد، نه یک گره که مسیر را نگه دارد. تغییرات را از مسیر معمول ذخیره و به‌روزرسانی اعمال کنید، اتصال‌دهنده را دوباره وصل کنید و از هر دو سر بررسی کنید؛ راه‌اندازی مجدد کامل همهٔ ماشین‌ها بخشی از این روش نیست.

آموزش site-to-site در Access Server همان تنظیمات را به ترتیب محصول فهرست می‌کند؛ ارزش دارد یک بار آن را پیش از سازگار کردن طرح با پیشوندهای خودتان دنبال کنید.