چرا پاسخ UDP OpenVPN از نشانی اشتباه خارج می‌شود

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

کلاینت هنگام تغییر مبدأ چه می‌بیند

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

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

گزینه multihome در واقع چه می‌کند

این دستور در فایل پیکربندی به شکل multihome و روی خط فرمان به شکل --multihome نوشته می‌شود و سرور UDP را وادار می‌کند از نشانی‌ای پاسخ دهد که بسته کلاینت به آن رسیده است. هسته هنگام دریافت، نشانی مقصد اصلی را به‌عنوان داده جانبی تحویل می‌دهد و OpenVPN از آن مقدار به‌عنوان مبدأ پاسخ استفاده می‌کند. بنابراین سروری که روی نشانی فراگیر، local 0.0.0.0 برای IPv4 یا معادل IPv6 آن، گوش می‌دهد رفتاری دارد که گویی هر کلاینت به شنونده‌ای اختصاصی رسیده است. کلاینت‌هایی که از نشانی عمومی آمده‌اند پاسخ را از نشانی عمومی می‌گیرند و کلاینت‌های روی نشانی داخلی از همان نشانی. هیچ چیز دیگری در مسیر بسته تکان نمی‌خورد: مسیر، قواعد فیلتر و پیکربندی تونل دقیقاً همان‌طور که بودند می‌مانند.

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

چه هنگام نشانی محلی ثابت پیش‌فرض نادرستی است

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

مرجع OpenVPN گزینه را به سرورهای UDP محدود می‌کند، پردازش اضافی در مسیر بسته را یادآور می‌شود و پلتفرم‌های پشتیبان آن را ثبت می‌کند. پیش از برنامه‌ریزی بر پایه آن، این را روی نسخه نصب‌شده تأیید کنید. جایی که پشتیبانی نمی‌شود، مقید کردن نشانی مشخص یا اصلاح مسیر بازگشت جایگزین است و هر دو تغییراتی باریک‌تر از آن هستند که در نگاه اول به نظر می‌رسند. گوش دادن فراگیر پیامدهایی فراتر از پاسخ‌ها هم دارد: سروری روی همه نشانی‌ها از هر شبکه‌ای که میزبان به آن متصل است در دسترس است و این ممکن است همان مواجهه‌ای نباشد که کسی قصدش را داشت.

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

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

ثبت بسته نشانی مبدأ را در پاسخ نشان می‌دهد و این همان واقعیتی است که کل مقاله بر آن می‌چرخد. فهرست سوکت‌ها نشان می‌دهد سرور واقعاً چه چیزی را مقید کرده است، زیرا شنونده فراگیر و شنونده مشخص در فایل پیکربندی یکسان به نظر می‌رسند و در شبکه متفاوت رفتار می‌کنند. جست‌وجوی مسیر مبدأیی را نشان می‌دهد که هسته برای آن جریان انتخاب می‌کرد و این ثبت را پیش از هر تغییری توضیح می‌دهد. هر سه را برای IPv4 و IPv6 جداگانه تکرار کنید، زیرا شنونده‌های جداگانه و جست‌وجوهای جداگانه‌اند و یک ورودی فراگیر برای یک خانواده درباره دیگری چیزی نمی‌گوید.

مسیریابی، کشف و فیلتر جدا می‌مانند

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

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