اجرای توزیعشده، سیاست مرکزی، failover و failback خودکار.
همان موتوری که در حالت مستقل روی یک جعبه اجرا میشود در حالت SASE روی هابهای شما اجرا میشود. اسپوکها از طریق پوشش رمزگذاریشده وصل میشوند. سیاست در ورود اجرا میشود. هویت با کاربر سفر میکند. failover خودکار است: کنسول آستانه سکوت قابل تنظیمی را صبر میکند، با بررسی سلامت تأیید میکند، سپس هر اسپوک را در یک عملیات جابهجا میکند.
چهار شکل، یک پوشش. شبکه تصمیم میگیرد کدام.
پروتکل جدیدی برای یادگیری نیست: همان موتور Zedmos که میشناسید، پیچیده در پوششی مدیریتشده که شعبهها، نقاط خروجی ابری و افراد راه دور را به یک سطح سیاست مشترک متصل میکند. اینکه چه شکلی بگیرد انتخابی روی بوم است — یک هاب، جفت هاب، تونلهای مستقیم بین اسپوکهایی که به آن نیاز دارند، یا هر سایت به هر سایت. جایی که هر دو سر یک جفت پشت NAT بازنویسکننده پورت هستند، رلهای در پشته خود کنسول بستهها را بدون نگه داشتن هیچ کلیدی حمل میکند.
هاب و اسپوک
همهچیز به یک جا میرسد. مگر دلیلی داشته باشید، از اینجا شروع کنید.
ترافیک بین دو سایت مسیر طولانی را میرود — و در راه بازرسی میشود.
هاب دوگانه
قطعی در سایت هاب نباید سایتهای دیگر را با خود ببرد.
یک هاب شنونده دوم برای اداره کردن. تا وقتی نیاز نشود فقط مسیرهای میزبان را نگه میدارد.
میانبر اسپوک
دو سایت آنقدر با هم حرف میزنند که دور زدن زمان واقعی میگیرد.
ترافیک آن جفت دیگر از هاب نمیگذرد، پس آنجا بازرسی هم نمیشود.
مش کامل
هر جفت با هر جفت دیگر حرف میزند. محدود به هشت سایت.
هر سایت یک همتا برای هر سایت دیگر حمل میکند، و یک گره همچنان واسطه جفتهاست.
وقتی هاب اصلی پاسخ نمیدهد، کنسول سایتها را جابهجا میکند — و برمیگرداند.
مانیتور کنسول پیوند عامل هر هاب اصلی را تماشا میکند. پس از آستانه سکوت توپولوژی هر اسپوک را در یک عملیات به هاب پشتیبان منتقل میکند، و پس از آنکه هاب اصلی برای پنجرهای پایدار سالم بود آنها را برمیگرداند. میتوانید تعویض را خودتان هم آغاز کنید، با پیشنمایشی از دقیقاً آنچه تغییر خواهد کرد.
چهار پرسش درباره هر اتصال، نه یک پرسش.
یک کلید یک دستگاه را اثبات میکند، و نه بیشتر. دسترسی راه دور در اینجا به جای آن به چهار چیز پاسخ میدهد: شخص کیست، به چه چیزی میتواند برسد، آیا امروز هنوز درست است، و ماشین در چه وضعیتی است. اینها چهار مورد از پنج ادعایی هستند که صنعت زیر ZTNA 2.0 ثبت میکند — پنجمی، یک سیاست داده که تا داخل مستأجرهای SaaS میرسد، را ما نمیکنیم: بازرسی درونخط است، پس آنچه از هاب میگذرد بازرسی میشود و آنچه از قبل در یک مستأجر SaaS نشسته نه.
شخص کیست
ثبتنام میتواند پیش از تولید هر کلید، ورود در ارائهدهنده خودتان را الزامی کند، با درخواست چندعاملی از طریق ادعای amr توکن. دستگاه پس از آن این هویت را حمل میکند، و هاب میتواند شخص پشت یک بسته را نام ببرد.
به چه چیزی میتوانند برسند
یک گروه دسترسی برنامههای نامبرده را میدهد — یک نشانی و پورتهایی که پاسخ میدهد — نه شبکهای که سرویس روی آن نشسته است. هاب برای هر برنامه به ازای هر شخص یک قاعده مینویسد و بقیه را رد میکند، و به کلاینت گفته میشود فقط آنچه میتواند به آن برسد را مسیریابی کند.
آیا هنوز درست است
یک مهلت دستگاه را به احراز هویت مجدد میبرد، یادآوریای فرستاده میشود، و وقتی مهلت گذشت دستگاه در هاب خاموش میشود تا شخص دوباره وارد شود. دایرکتوریای که حساب را غیرفعال گزارش میکند همین کار را میکند، بدون انتظار برای مهلت.
روی چه ماشینی هستند
وضعیت دستگاه از سیستم مدیریتی که همین حالا اداره میکنید خوانده میشود — Microsoft Intune یا CrowdStrike Falcon — و هرگز از عاملی از ما. ماشینی که غیرمنطبق گزارش شده خاموش میشود و وقتی سالم شد خودش برمیگردد؛ ماشینی که هیچکس نمیتواند برایش حرف بزند دسترسیاش را نگه میدارد مگر آنکه خوانش سختگیرانه را بخواهید.
این چه چیزی نیست: پروکسی معکوس و دسترسی فقط-مرورگر وجود ندارد، پس هر شخص با کلاینت استاندارد WireGuard متصل میشود و اعطاها به ازای هر برنامهاند نه هر URL. هیچچیز رفتار را امتیازدهی نمیکند. ترافیک مجاز همچنان در هاب بازرسی میشود — پیشگیری از نفوذ، فیلترینگ URL، بازرسی TLS، پیشگیری از نشت داده — همان بخشی که بیشتر کارگزاران دسترسی جا میاندازند.
پنج گام تا یک پوشش SASE زنده
هماهنگسازی مقاومسازیشده توپولوژی، توزیع سیاست، نگاشت هویت و failover را مدیریت میکند. برای استقرارهای کوچکتر روی یک گره یا برای تولید به صورت جفت افزونه اجرا میشود.
- مدل توپولوژی آماده چندمستأجری
- انبار داده مقاومسازیشده با دسترسی مبتنی بر نقش
- منبع مرکزی حقیقت برای سیاست و هویت
گرههای هاب موتور Zedmos را در وضعیت مسیریابیشده با رابط رمزگذاریشده اختصاصی میزبانی میکنند. هر جریان اسپوک در هاب از DPI، سیاست، بازرسی TLS و لاگگیری میگذرد.
- همان موتور Console — یک باینری، یک رفتار
- DPI درونخط و اجرای سیاست در ورود
- هابهای اصلی و پشتیبان به صورت جفت فعال-آماده عرضه میشوند
اسپوک میتواند دستگاه OPNsense یا pfSense در یک شعبه، گیتوی لینوکسی فشرده، یا کاربر راه دور با کلاینت استاندارد WireGuard باشد. دستگاهها با توکن ثبت میشوند؛ کاربران راه دور با پیوند یکبارمصرف ثبتنام میکنند.
- ثبت مبتنی بر توکن برای دستگاههای شعبه
- کلاینتهای استاندارد WireGuard برای کاربران راه دور
- اتصال مجدد و تعویض کلید خودکار
سرویسهای دایرکتوری کاربران، گروهها و دستگاههای شناختهشده را به هاب میرسانند. هر جریان در زمان بازرسی برچسب میخورد، پس سیاست میتواند بین افراد تمایز بگذارد، نه فقط نشانیها. یک اتصال جداگانه شخص راه دور را در ثبتنام پیوند میدهد: ارائهدهنده OpenID Connect خودتان، با ادعای چندعاملی که پیش از وجود کلید الزامی است.
- Active Directory از طریق عامل کنترلر دامنه
- Entra / Azure AD از طریق Microsoft Graph
- یکپارچهسازی SCIM با Okta و IDPهای سازگار
- ارائهدهنده OpenID Connect خودتان برای ثبتنام، MFA الزامی
- سلامت دستگاه از Microsoft Intune یا CrowdStrike Falcon
به ازای هر توپولوژی انتخاب کنید: کنسول پیوند عامل هاب اصلی را تماشا میکند و پس از آستانه سکوت و بررسی سلامت، هر اسپوک را به هاب پشتیبان منتقل میکند. failback پس از پایدار شدن هاب اصلی خودکار است.
- آستانه سکوت و زمان خنکشدن به ازای هر توپولوژی
- پیشنمایش پیش از تعویض دستی
- failback خودکار به هاب ترجیحی