NEXTUNNEL · WEB APPLICATION PROXY
انتشار هر اپلیکیشن داخلی، نباید به قیمت یک پورت ورودی جدید تمام شود.
قاعدهٔ همیشگی را میشناسید: هر اپلیکیشن داخلی که بخواهید منتشر کنید، یک قاعدهٔ ورودی جدید در فایروال میخواهد؛ یعنی یک جلسهٔ دیگر در کارگروه تغییرات، و یک استثنای دیگر که در ممیزی بعدی باید از آن دفاع کنید. یک صورتمسئلهٔ آشنا را دنبال کنید:
SCENARIO
داشبورد داخلی یک بانک، روی سروری در DMZ و بدون IP عمومی — باید در دسترس ۴۰ کارمند شعبه قرار بگیرد.
روش همیشگی — Bastion سنتی و فرایند فایروال
- 01 درخواست تغییر فایروال ثبت میشود.
- 02 درخواست به کارگروه تغییرات میرود؛ امنیت میپرسد این قاعدهٔ ورودی دیگر چرا؟
- 03 اجرا به پنجرهٔ تغییرات بعدی موکول میشود؛ هفتهها میگذرد.
- 04 فهرست قواعد ورودی سازمان یک خط بلندتر میشود — خطی که در ممیزی بعدی باید کسی از آن دفاع کند.
- 05 و اپلیکیشن بعدی؟ همین چرخه از اول.
هزینه: هفتهها انتظار — و یک استثنای ماندگار در فهرست ممیزی
با NexTunnel
- ✓ کانکتور NexTunnel را روی همان سرور اجرا میکنید؛ خودش از داخل، روی همان پورت HTTPS موجودِ گذرگاه، اتصال را به بیرون برقرار میکند.
- ✓ نه تیکت فایروال، نه قاعدهٔ ورودی جدید، نه چیز تازهای در معرض اینترنت.
- ✓ کارمندان شعبه همان نشانی همیشگی NexGate را باز میکنند و نشستشان درست مثل نشست مستقیم ضبط، سیاستگذاری و ممیزی میشود.
هزینه: اجرای یک سرویس کنار همان بکاند — و دیگر هیچ
۱
مرورگر از همان نشانی همیشگی و روی HTTPS به گذرگاه NexGate میرسد؛ برای کاربر هیچچیز عوض نمیشود.
۲
کانکتور از قبل اتصال را از داخل شبکه به بیرون برقرار کرده است؛ نشست کاربر روی همین تونل سوار میشود و هیچ اتصالی از بیرون به داخل باز نمیشود.
۳
کانکتور ترافیک را به اپلیکیشن داخلی میرساند؛ همان سیاست، ضبط و ممیزیِ نشستهای مستقیم اینجا هم برقرار است.
مسیر ترافیک NexTunnel · هیچ فلشی رو به داخل از فایروال عبور نمیکند
NEXTUNNEL
انتشار بدون هیچ مسیر ورودی
- کانکتور کنار بکاند اجرا میشود — بهصورت Container یا سرویس systemd — و همیشه خودش از داخل به سمت گذرگاه، روی همان پورت HTTPS اصلی، اتصال برقرار میکند.
- ثبت کانکتور با توکن یکبارمصرف انجام میشود و هر تونل تا ۱۶ نشست همزمان کانکتور را برای پایداری میپذیرد.
- نشانی برای کاربر تغییر نمیکند و ترافیک تونل از همان مسیر سیاست، ضبط و ممیزیِ نشستهای مستقیم میگذرد.
- برخلاف سرویسهای ابری ZTNA، نه ترافیک و نه Control Plane به ابرِ سازنده نمیرسد؛ همهچیز در زیرساخت خود سازمان میماند.
WEB APPLICATION PROXY
هویت، ضبط و جداسازی در لایهٔ وب
- ورود یکپارچه با تزریق هدر هویت، یا NexGate خود در نقش Identity Provider استاندارد OIDC — با صفحهٔ Consent و PKCE.
- اتصال mTLS به بکاند با گواهی کلاینتِ اختصاصی هر اپلیکیشن، ذخیرهشده بهصورت رمزنگاریشده.
- ضبط تراکنشهای HTTP پروکسیشده در قالب HAR، در کنار نمایش زندهٔ درخواستهای در جریان.
- جداسازی مبدأ و خروجی: محتوای پروکسیشده از میزبانی جداگانه ارائه میشود تا مسیر هممبدأ به API مدیریتی نداشته باشد، و ترافیک خروجی گذرگاه تماماً از Squid عبور میکند.