دو نشانی سرویس روی یک کلاینت OpenVPN: iroute و lo

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

نام مستعار محلی است، مالکیت از راه دور

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

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

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

نشانی را به‌طور پایدار روی کلاینت اضافه کنید

نشانی سرویس را با پیشوند میزبان روی loopback بگذارید تا میزبان آن را ورودی محلی بداند نه زیرشبکه‌ای برای رسیدن. ip address add 10.66.0.10/32 dev lo این کار را برای یک نشانی انجام می‌دهد، و تکرار فرمان برای نشانی دوم دو سرویس را مدل می‌کند.

آن را به‌عنوان آزمون یک‌باره اجرا کنید، سپس به چیزی که پیکربندی شبکه میزبان را در اختیار دارد منتقل کنید، زیرا افزودن زمان اجرا با راه‌اندازی مجدد از بین می‌رود و تکراری‌ها در اتصال‌های مجدد انباشته می‌شوند. یک واحد systemd که پس از شبکه مرتب شده باشد یک گزینه است و مدیر شبکه توزیع گزینه دیگر. هرکدام را انتخاب کنید، نشانی باید پیش از اتصال برنامه وجود داشته باشد، وگرنه سرویس روی سوکت اشتباه بالا می‌آید. پس از راه‌اندازی مجدد، نه پس از فرمان دستی، با ip address show dev lo بررسی کنید.

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

آن را در فایل CCD که هاب واقعاً می‌خواند مطالبه کنید

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

دو جزئیات این را بی‌صدا می‌شکنند. نام فایل باید با نامی که سرور واقعاً استفاده می‌کند مطابقت داشته باشد، که وقتی username-as-common-name در کار است فرق می‌کند. و iroute فقط در حالت TUN با پوشه پیکربندی کلاینت تنظیم‌شده اثر می‌کند، پس همان خط در استقرار پل‌زده هیچ کاری نمی‌کند. خط‌ها را به فایل موجود اضافه کنید نه اینکه آن را جایگزین کنید، چون ممکن است از قبل نشانی ثابت یا گزینه‌های push داشته باشد. مرجع OpenVPN 2.6 هم پوشه و هم دستور مالکیت را مستند می‌کند.

هسته خود هاب هم به مسیری به آن مقاصد نیاز دارد تا ترافیک تولیدشده محلی وارد فرایند تونل شود. route 10.66.0.10 255.255.255.255 در پیکربندی سرور ترافیکی را پوشش می‌دهد که سرور خودش ایجاد می‌کند، در حالی که کلاینت‌های دیگر به push "route 10.66.0.10 255.255.255.255" نیاز دارند تا مقصد را خودشان یاد بگیرند.

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

سیاست ورودی و مسیر پاسخ را بررسی کنید

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

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

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

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

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

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