pfSense OpenVPN: رسیدن به شبکه‌ای پشت یک روتر دیگر

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

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

یک بسته، سه تصمیم مسیریابی

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

خرابی هر یک از آن‌ها همان گزارش کاربر را تولید می‌کند. به همین دلیل ترتیب عیب‌یابی از ابزارها مهم‌تر است.

به کلاینت یک پیشوند بدهید، نه یک حدس

روی یک سرور pfSense SSL/TLS با شبکه تونل IPv4 بزرگ‌تر از /30، فیلد IPv4 Local network(s) هنگام اتصال، مسیرها را به کلاینت‌ها توزیع می‌کند. پیشوند پایین دست را همان‌جا اضافه کنید، به‌جای اینکه به کلاینت تکیه کنید تا یکی از خودش بسازد. سپس پس از اتصال، جدول واقعی کلاینت را بخوانید، چون پروفایلی با route-nopull یا یک فیلتر مسیر می‌تواند آنچه سرور فرستاده را نادیده بگیرد. سرور می‌تواند کاملاً درست باشد، در حالی که کلاینت هیچ‌چیز نصب نمی‌کند.

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

pfSense را به روتر داخلی نشانه بگیرید

یک مسیر ایستا در pfSense به درگاهی تعریف‌شده و قابل‌دسترس نیاز دارد، و رابطی که برای آن درگاه انتخاب می‌شود باید همانی باشد که واقعاً به آن می‌رسد، همان‌طور که راهنمای مسیرهای ایستا در Netgate شرح می‌دهد. در یک چیدمان نمونه، لینک ترانزیت 192.168.77.1 روی فایروال و 192.168.77.2 روی روتر داخلی است، و شبکه سرویس 172.16.30.0/25 پشت آن قرار دارد. آن‌گاه مسیر، پیشوند و پرش بعدی را نام می‌برد، نه آدرس سرویس را. استفاده از آدرسی از شبکه دور به‌عنوان درگاه، روش رایجی برای ساختن مسیری است که درست به نظر می‌رسد و هیچ‌جا ارسال نمی‌کند.

دادن یک نام به رابط، شبکه‌های پشت آن را توصیف نمی‌کند. مسیر ایستا همان توصیف است.

طرف دور باید استخر را بشناسد

روتر پایین دست به یک مسیر بازگشت برای استخر نیاز دارد، در این مثال 10.55.0.0/24 از طریق 192.168.77.1، مگر اینکه یک مسیر پیش‌فرض یا یک پروتکل پویا از قبل یکی فراهم کند. درگاه خود میزبان سرویس باید به سمت آن روتر برود، که معمولاً درست است وقتی روتر درگاه پیش‌فرض آن است و نادرست وقتی میزبان به‌صورت دستی پیکربندی شده. مسیریابی سیاستی روی فایروال هم می‌تواند جدول را برای ترافیک مشخص نادیده بگیرد، پس پیش از نتیجه‌گیری که مسیر اشتباه است بررسی کنید آیا قاعده‌ای درگاه دیگری انتخاب می‌کند.

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

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

طرح سه مالک را همراه با برنامه مجاز ذخیره کنید، تا مدیر بعدی بتواند مسیر را بازسازی کند، نه اینکه دوباره آن را کشف کند.