pfSense به‌عنوان سرور و کلاینت VPN: دو مسیر، یک روتر

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

پیش از دست زدن به هر تنظیمی، دو نقش را نام‌گذاری کنید

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

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

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

پاسخ‌های سرور را روی مسیر WAN نگه دارید

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

نگذارید تونل خروجی نقطه پایانی خودش را بخورد

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

انتخاب کنید کدام کاربران خروج را می‌گیرند

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

تصمیم بگیرید وقتی خروج شکست می‌خورد چه می‌شود

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

نمونه کلاینت را غیرفعال کنید، ببینید کاربر متصل هنوز به چه چیزی می‌رسد، سپس دوباره راه‌اندازی کنید. درخواستی که مهلتش تمام می‌شود همان نتیجه مسدودسازی کامل است که خواستید؛ درخواستی که با نشانی WAN پاسخ می‌دهد همان بازگشتی است که مستند نکردید. بررسی را برای IPv6 و DNS تکرار کنید، چون سیاستی که برای IPv4 نوشته شده درباره ترافیک AAAA چیزی نمی‌گوید و resolverی که هر یک از تونل‌ها هلش می‌دهد از همان‌جایی پاسخ می‌دهد که پرس‌وجو واقعاً خارج می‌شود.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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