معماری – الگوهای معماری برای چندپروتکل TCP و مسیریابی UDP بدون اتصال در پشت NAT یک IP دقیق

متن و بیان مسئله

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

میزبان چندین ماشین مجازی ایزوله (VM) را اجرا می کند که نقاط پایانی مختلفی را ارائه می دهند: وب، ذخیره سازی سازگار با S3، SSH، RDP، جریان های VNC، اتصالات مستقیم پایگاه داده (مانند PostgreSQL/MySQL)، و سرورهای بازی UDP سفارشی.

چالش اصلی معماری مسیریابی ترافیک چند پروتکل پیچیده TCP روی یک پورت باز واحد و ترافیک UDP حساس به تاخیر است. در حالی که تعداد کل پورت های باز خارجی را به حداقل مطلق نگه دارید. علاوه بر این، ماشین‌های مجازی داخلی باید برای زیرساخت‌های پروکسی/مسیریابی کاملاً ناشناخته باقی بمانند، و مشتریان عمومی نمی‌توانند نرم‌افزار سفارشی (مانند VPN یا شبکه همپوشانی) را نصب کنند.

محدودیت ها

معماری باید شرایط زیر را برآورده کند:

1. مسیریابی TCP (تک پورت تنگنا):

• فقط بندر 443 به صورت ایستا از WAN به میزبان اصلی ارسال می شود.
• من باید HTTPS (نیاز به مسیریابی SNI به ماشین های مجازی وب مختلف و نقاط پایانی S3) را به همراه SSH، RDP، VNC و پایگاه های داده روی همین پورت ارائه دهم.

2. مسیریابی UDP (بدون اتصال، پویا و به حداقل رساندن پورت):

• ماشین های مجازی میزبان سرورهای بازی هستند که به شدت به UDP متکی هستند.
• برخلاف HTTP، این پروتکل‌های بازی یک شناسه استاندارد دست دادن یا سطح بار (مانند SNI) برای نشان دادن میزبان هدف ندارند.
• سرورها به صورت پویا می چرخند. روتر لبه دارای یک API REST برای باز کردن پورت‌های WAN به صورت برنامه‌ریزی شده است، اما من به روشی سیستماتیک برای نگاشت این پورت‌های WAN به صورت پویا به آدرس‌ها/پورت‌های IP داخلی VM صحیح نیاز دارم.

مطالعات و تلاش برای راه حل

من به طور کامل پارادایم های مسیریابی استاندارد را بررسی کرده ام، اما به نظر می رسد که هر یک از محدودیت های من کوتاهی دارند:

• راه حل های چندپلکس TCP: من به پراکسی های معکوس استاندارد نگاه کردم (Nginx stream ماژول، HAProxy). اگرچه آنها مسیریابی L7 SNI را برای Web/S3 کاملاً مدیریت می کنند، اما ترافیک غیر TLS (SSH، RDP، VNC، DBs) را مالتی پلکس می کنند. همان پورت به یک مالتی پلکسر لایه 4 نیاز دارد که اولین بایت های بار (امضای پروتکل) را قبل از مسیریابی بررسی می کند.
  • چرا کاملاً نیازهای من را برآورده نمی کند: زنجیر کردن بایت بازرس L4 به پروکسی معکوس L7 و سپس به ماشین های مجازی، نگرانی های معماری را در مورد حفظ IP مشتری اصلی ایجاد می کند. PROXY پشتیبانی از پروتکل در همه سرویس هایی که DB یا RDP بومی پشتیبانی نمی کنند) و وضعیت سوکت/اتصال بالقوه خسته کننده است.
• راه حل های مسیریابی UDP: من دو رویکرد اصلی برای مسیریابی بدون اتصال پویا را بررسی کردم.
  • هسته NAT (iptables/nftables): داشتن یک سرویس Backend به صورت برنامه نویسی قوانین را تزریق می کند. عیب: مدیریت وضعیت توزیع شده بین لایه برنامه و فایروال هسته شکننده و مستعد قوانین یتیم است.
  • پاس فضای کاربری: نوشتن یک جریان بسته فضای کاربری سفارشی که مقصد را از یک حافظه پنهان (مثلا Redis) می خواند. عیب: من نگران تغییر زمینه و تأخیر بسته های بازی با فرکانس بالا در مقایسه با مسیریابی هسته بومی هستم.
• شبکه های همپوشانی: من شبکه‌های همپوشانی (Wireguard/Tailscale) را در نظر گرفتم، اما این شرایط را نقض می‌کند که کاربران عمومی (مانند بازدیدکنندگان وب استاندارد یا پخش‌کننده‌های عمومی بازی) نمی‌توانند مجبور به نصب نرم‌افزار مشتری شوند.

سوالات مهندسی خاص من

با توجه به این محدودیت ها، من به دنبال یک نمای کلی از معماری خاصی هستم که در نظر دارم:

1. برای جریان TCP: آیا رویکرد پیشنهادی من برای استفاده از یک پروکسی L4 سفارشی برای “SNI Peeking” (TLS passthrough) از نظر معماری برای دملتپلکس کردن TLS، SSH و ترافیک پایگاه داده در یک پورت مناسب است؟ از آنجایی که پروتکل‌های بومی (SSH/DB) SNI را ارسال نمی‌کنند، این امر مستلزم مجبور کردن کلاینت‌ها به بستن اتصالات خود در TLS (مثلاً از طریق) است. stunnel). آیا این الزام برای بسته بندی سمت مشتری یک ضدالگوی اصلی معماری برای خدمات عمومی در نظر گرفته می شود؟
2. برای جریان UDP: برای مدیریت سرورهای بازی پویا بدون شناسه بار، آیا مسیریابی بسته‌ها از طریق یک رله فضای کاربر سفارشی (جستجوی Redis برای مقصد) یک الگوی جدی ضد تأخیر است؟ آیا جریمه عملکرد برای ترافیک بدون اتصال فرکانس بالا به اندازه کافی شدید است که دستکاری NAT هسته برنامه‌ریزی شده (به عنوان مثال iptables) تنها انتخاب مهندسی قابل قبول در اینجا است؟

اگر مدارهای L4/L7 فعلی و مفاهیم پراکسی UDP فضای کاربر من به عنوان ضدالگو برای این محیط خاص در نظر گرفته شوند، من کاملاً به پارادایم های معماری جایگزین باز هستم.