چرا کلاینت‌های OpenVPN انتخاب‌گرهای IPsec دروازه را از دست می‌دهند
یک ping از دروازه جریان دیگری را اثبات می‌کند. استخر کلاینت را از مسیر pushشده، انتخاب‌گرهای IPsec، زنجیره ارسال و مسیر پاسخ دنبال کنید.
از دروازه به میزبانی پشت تونل IPsec دورافتاده ping بفرستید و تمیز پاسخ می‌دهد، پس تونل سالم به نظر می‌رسد و تیکت جلو می‌رود. سپس کلاینت متصل همان میزبان را امتحان می‌کند و چیزی برنمی‌گردد. آن ping هرگز شاهدی برای جریان کلاینت نبود، چون با نشانی مبدأ خود دروازه خارج شد و با انتخاب‌گر دیگری در IPsec مطابقت کرد. درک این‌که چرا این دو حالت از هم جدا می‌شوند بیشترین بخش رفع است.
Ping از دروازه جریانی را می‌آزماید که کلاینت شما هرگز از آن استفاده نمی‌کند
نشانی مبدأ تعیین می‌کند که کدام سیاست اعمال شود. بسته‌ای که روی دروازه تولید می‌شود با نشانی از LAN محلی آن یا از نقطه پایانی تونل بیرون می‌رود، و سیاستی که با آن مطابقت دارد دقیقاً برای همان حالت نوشته شده است. بسته کلاینت با نشانی از استخر کلاینت به رابط OpenVPN می‌رسد، که انتخاب‌گری کاملاً متفاوت است.
به همین دلیل خرابی مانند یک مشکل مسیریابی به نظر می‌رسد، در حالی که در واقع مشکل دامنه سیاست است. دسترسی از دروازه اثبات می‌کند که همتا فعال است و پیشنهادها مذاکره شده‌اند، و هیچ چیز دربارهٔ محافظت‌شده بودن استخر اثبات نمی‌کند.
پیشوند دورافتاده‌ای را که برنامه واقعاً لازم دارد push کنید
جفت نمونه 10.8.0.0/24 برای کلاینت‌های متصل و 172.30.239.0/25 برای شبکه دورافتاده محافظت‌شده را در نظر بگیرید. آنچه کلاینت لازم دارد مسیری به آن پیشوند دوم است، نه به LAN دروازه و نه به نشانی تونل دیگری. مسیری که به استخر push می‌شود همان چیزی است که کلاینت را وامی‌دارد این ترافیک را به دروازه بسپارد. بدون آن بسته هرگز به تصمیم سیاستی که اشکال‌زدایی می‌کنید نمی‌رسد.
در سرور Community که مسیرهای pushشده را می‌پذیرد، دستور ماسک واقعی را می‌گیرد: push "route 172.30.239.0 255.255.255.128". Access Server همان مقصد را از طریق تنظیمات شبکه خصوصی یا قواعد دسترسی نسخه نصب‌شده تنظیم می‌کند، و حالت مسیریابی یا ترجمه آگاهانه انتخاب می‌شود. ویرایش زنجیره‌های فایروال تولیدشده به جای پیکربندی مالک، همان راهی است که یک نصب کارآمد را غیرقابل بازتولید می‌کند.
پس از اتصال، جدول مسیریابی کلاینت را بخوانید نه قصد سرور را. مسیری که فقط استخر را پوشش می‌دهد یعنی push نرسیده است، و مسیر پیش‌فرض از تونل از این نیاز گسترده‌تر است و بعداً غافلگیرتان می‌کند. ماسک و همچنین پیشوند را بررسی کنید، چون /25 که به‌صورت /24 push شود ترافیک نشانی‌های همسایه را به مسیری می‌فرستد که نمی‌تواند آن را حمل کند. سپس تأیید کنید که کلاینت رابط تونل را برای آن مقصد انتخاب کرده است.
کاری کنید که انتخاب‌گرها استخر کلاینت را شامل شوند
برای دسترسی مسیریابی‌شده‌ای که نشانی کلاینت را حفظ می‌کند، سیاست IPsec باید ترافیک بین استخر و پیشوند دورافتاده را محافظت کند. انتخاب‌گرهایی که برای LAN خود دروازه نوشته شده‌اند ping را می‌پذیرند و درخواست کلاینت را رها می‌کنند، و این دقیقاً همان عدم تقارنی است که این بررسی را آغاز کرد.
سیاست مذاکره‌شده و همچنین پیشنهادهای پیکربندی‌شده را بررسی کنید، برای نمونه با ipsec statusall در strongSwan یا فرمان وضعیت معادل برای پیاده‌سازی شما. در IPsec مبتنی بر سیاست، مسیر معمولی می‌تواند به یک رابط فیزیکی اشاره کند در حالی که ترافیک منطبق هنوز رمزنگاری می‌شود، پس نبودِ دستگاه تونل چیزی را اثبات نمی‌کند. جفت‌های انتخاب‌گر را با استخر و پیشوندی که یادداشت کرده‌اید مقایسه کنید.
NAT مبدأ عمومی روی دروازه هم می‌تواند تطابق را بشکند. اگر قاعدهٔ masquerade پیش از بررسی سیاست، مبدأ کلاینت را بازنویسی کند، بسته دیگر شبیه انتخاب‌گری که نوشته‌اید نیست. این یکی از دلایلی است که قاعدهٔ masquerade گسترده رفع بدی برای VPN دوم است: تغییر می‌دهد کدام سیاست اعمال شود و کدام نشانی در طرف دورافتاده ثبت شود. ترافیکی را که می‌خواهید مسیریابی کنید مستثنا کنید، یا آگاهانه آن را ترجمه کنید و انتخاب‌گرها را به‌روز کنید.
آگاهانه مسیریابی یا ترجمه را انتخاب کنید
مسیریابی نشانی کلاینت را برای طرف دورافتاده قابل مشاهده نگه می‌دارد، پس گزارش‌های دورافتاده و قواعد هر مبدأ معنادار می‌مانند، و نیاز دارد که دروازه دورافتاده مسیر بازگشت به استخر را بداند. ترجمه استخر را پشت یک نشانی پنهان می‌کند، که مشکل مسیر بازگشت را برمی‌دارد و هویت هر کلاینت را از بین می‌برد.
یک طراحی را انتخاب و آن را بنویسید، چون دو طراحی به انتخاب‌گرهای متفاوت و ترتیب فایروال متفاوت نیاز دارند. masquerade نیمه‌اعمال‌شده میان آن دو می‌افتد و هیچ‌کدام را برآورده نمی‌کند. انتخاب نوشته‌شده همان چیزی است که به مهندس بعدی اجازه می‌دهد باگ را از تصمیم آگاهانه تشخیص دهد.
حلقه را روی ارسال و پاسخ ببندید
دروازه باید پروتکل و مقصدی را که منظورتان است ارسال کند، یعنی ارسال IP فعال باشد و زنجیرهٔ ارسال آن جفت را مجاز کند. سپس طرف دورافتاده باید پاسخ‌ها را از مسیر IPsec برگرداند، و این تصمیمی مسیریابی روی دروازهٔ آن‌هاست نه شما. هر دو نیمه پیکربندی معمولی‌اند و هر دو آسان نیمه‌کاره می‌مانند. آن‌ها را جداگانه بیازمایید تا قاعدهٔ ارسال مفقود با تونل خراب اشتباه نشود.
با یک درخواست واقعی از کلاینت به برنامه تأیید کنید و ببینید که از رابط OpenVPN، تصمیم IPsec و میزبان دورافتاده می‌گذرد. پاسخ را مشاهده‌ای جداگانه بررسی کنید، چون درخواستی که می‌رسد و پاسخی که هرگز برنمی‌گردد از جای کلاینت یکسان به نظر می‌رسند. یک درخواست ردیابی‌شده از هر تعداد ping از دروازه ارزشمندتر است.
در حین آزمایش مجوز مقصد را باریک نگه دارید و تأیید کنید که کلاینتی بدون قاعده نمی‌تواند به سرویس برسد. مسیر نصب‌شده به‌همراه انجمن برقرارشده همان دسترسی اعطاشده نیست.