رلهٔ stream در Nginx برای UDP در OpenVPN: چه چیزی را تغییر می‌دهد

کلاینت شما روی UDP تنظیم شده است، سرور Nginx یک بلوک location دارد که به پورت VPN اشاره می‌کند و هیچ چیزی نمی‌رسد. این انتظار می‌رود: یک location در HTTP نمی‌تواند یک دیتاگرام UDP را حمل کند، هر نامی که به فرانت‌اند بدهید. Nginx برای این کار به یک شنوندهٔ stream نیاز دارد و پس از انتقال پیکربندی به آنجا، دستهٔ دومی از جزئیات تعیین می‌کند که نشست زنده می‌ماند یا نه.

لایهٔ پراکسی پیش از نشانی می‌آید

ماژول stream در Nginx بدون تجزیهٔ HTTP، TCP و UDP را پراکسی می‌کند. ماژول HTTP آن انتظار خط درخواست، سرآیندها و پاسخ را دارد و هیچ‌یک از اینها در یک دیتاگرام OpenVPN بومی وجود ندارد. بنابراین انتخاب لایه نخستین تصمیم است و به این بستگی ندارد که شنونده IPv4 باشد یا IPv6.

پیکربندی‌ای که به نظر می‌رسد با OpenVPN روی TCP کار می‌کند، دربارهٔ حالت UDP هیچ نمی‌گوید. اینجا انتقال بخشی از پروتکل است، نه جزئیاتی از استقرار.

شنونده و بک‌اند

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

پیش از هر ویرایشی تأیید کنید که build ماژول stream را دارد؛ بستهٔ توزیع ممکن است آن را به ماژولی جدا تقسیم کند و ماژول ناموجود به‌جای تونل، خطای پیکربندی می‌دهد. بلوک را در بافت پیکربندی اصلی بگذارید، نه داخل http، و نشانی مستندات را با بک‌اند واقعی جایگزین کنید.

هم هر دو مسیر و هم هر دو دیوار آتش باید دیتاگرام‌ها را مجاز کنند: مسیر تا شنونده و مسیر از پراکسی تا بک‌اند. شنوندهٔ IPv6 نیز مسیر IPv4 ایجاد نمی‌کند، پس اگر برخی کلاینت‌ها هنوز IPv4 دارند، آن شنونده ورودی جداگانه‌ای با آزمون خودش است. دیوار آتش خود بک‌اند را از نشانی پراکسی بررسی کنید، نه از لپ‌تاپتان.

مهلت نشست، مهلت درخواست نیست

پراکسی stream برای نشست UDP حالت نگه می‌دارد و آن را بر اساس مهلت و تنظیمات پاسخ دور می‌اندازد. مهلت کوتاهی که از یک رلهٔ DNS کپی شده برای VPNی که انتظار تبادل دیتاگرام برای ساعت‌ها دارد مناسب نیست و خرابی به‌صورت اتصالی که بی‌صدا می‌میرد ظاهر می‌شود، نه اتصالی که از شروع امتناع می‌کند.

مقدار مؤثر proxy_timeout استقرار و هر تنظیم شمارش پاسخ را بخوانید، سپس آن‌ها را با رفتار keepalive که VPN واقعاً استفاده می‌کند مقایسه کنید. دو عدد که افراد مختلف در فایل‌های مختلف نوشته‌اند حالت عادی یک سامانهٔ کارآمد است. دو عدد که هرگز مقایسه نشده‌اند حالت عادی یک سامانهٔ متناوب است. هر دو را در سوابق سرویس بنویسید تا مقایسه یک بار، در روشنایی روز، انجام شود.

رله چه چیزی را تغییر می‌دهد و چه چیزی را نه

پراکسی stream کانال کنترل TLS در OpenVPN را پایان نمی‌دهد و آن را به HTTPS تبدیل نمی‌کند. بک‌اند همان سرویس VPN می‌ماند و رابطهٔ گواهی بین کلاینت و همان سرویس باقی می‌ماند. حفظ هویت موردنظر بک‌اند همچنان وظیفهٔ کلاینت و سرور است.

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

از کلاینت بررسی کنید، نه از پورت

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

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