دسترسی به ایستگاه کاری پشت NAT بدون فوروارد پورت
ایستگاه کاری بدون پورت ورودی هنوز از طریق هاب، رله یا کارگزار برنامه قابل دسترسی است. پیش از انتخاب یکی، تضمین‌های هر طراحی را مقایسه کنید.
دو نقطه انتهایی پشت NAT اپراتور و یک روتر اداری قفل‌شده هیچ پورت ورودی برای فوروارد باقی نمی‌گذارند، و واکنش غریزی این است که باز هم یکی درخواست شود. پرسش بهتر این است که کدام سمت می‌تواند بیرون را شماره‌گیری کند و کدام سرویس قابل دسترس مجاز است ترافیک را حمل کند. چهار طراحی به این پرسش پاسخ متفاوت می‌دهند و وقتی مسیری مسدود شود به شکل‌های متفاوت شکست می‌خورند. انتخاب میان آن‌ها مقایسه تضمین‌ها است، نه نام پروتکل‌ها.
چهار طراحی، چهار وعده متفاوت
جدول زیر نسخه کوتاه است. ستون میانی را وعده‌ای بخوانید که می‌توانید آزمایش کنید و ستون راست را وعده‌ای که هیچ‌کس نداده است.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
اینکه کدام سطر اعمال می‌شود به وظیفه بستگی دارد نه به ترجیح. یک نشست میزکار از راه دور، یک پوسته مدیریتی و دسترسی به یک زیرشبکه خصوصی کامل سه نیازمندی هستند که به نقطه ورود یکسانی نیاز ندارند، حتی وقتی تصادفاً به همان ماشین مربوط می‌شوند.
هاب تغییر می‌دهد چه کسی بیرون را شماره‌گیری می‌کند، نه اینکه چه چیزی مجاز است
در طراحی هاب مسیریابی‌شده، لپ‌تاپ از راه دور و ایستگاه کاری، یا دروازه سایت پیش از آن، هر یک تونلی خروجی به سرویسی باز می‌کنند که هر دو می‌توانند به آن برسند. هیچ چیز در روتر ایستگاه کاری اتصال ناخواسته نمی‌پذیرد، و دقیقاً به همین دلیل این طراحی از NAT جان سالم به در می‌برد و وقتی سایت نشانی ثابت ندارد هم کار می‌کند. سپس هاب ترافیک را میان دو نشانی درونی بر پایه سیاست خود مسیریابی می‌کند.
هزینه این است که هاب باید وجود داشته باشد، از هر دو سو قابل دسترس باشد و کسی آن را اداره کند. فیلتر خروجی باید انتقال را مجاز کند، و شبکه‌ای که آن را مسدود کند طراحی را شکست می‌دهد حتی اگر به فوروارد پورت نیازی نبوده باشد.
نکته ظریف این است که دسترس‌پذیری و مجوزدهی دو تصمیم جداگانه‌اند که در جاهای متفاوت گرفته می‌شوند. مسیر به یک پیشوند هیچ چیزی درباره اینکه هویت می‌تواند از کدام سرویس روی ایستگاه کاری استفاده کند نمی‌گوید، و قاعده دیوار آتشی که تونل را مجاز می‌کند هیچ چیزی درباره اینکه حساب می‌تواند وارد شود نمی‌گوید. هر دو را پیکربندی کنید، هر دو را آزمایش کنید، و تصمیم مجوز را نزد سیستمی نگه دارید که مالک منبع است، نه نزد جدول مسیریابی.
عبور تنها زمانی کار می‌کند که هر دو پشته آن را پیاده کنند
عبور میان همتاها توانایی یک سیستم مشخص است، نه تنظیمی که یک VPN را بهتر می‌کند. Interactive Connectivity Establishment چند نشانی نامزد جمع می‌کند و جفت‌ها را تا کارکردن یکی آزمایش می‌کند: نامزدهای میزبان روی واسط‌های محلی، نامزدهای بازتابی سرور که از آنچه NAT آشکار می‌کند ساخته می‌شوند، و نامزدهای رله‌شده که روی یک رله تخصیص می‌یابند. یک نشانی خصوصی به‌تنهایی مسیر نیست، چون طرف دیگر نمی‌تواند به آن مسیریابی کند.
ارزش دارد مورد رله‌شده را پیش از کنار گذاشتن آن بفهمیم. RFC 8656 TURN را به‌عنوان پروتکلی توصیف می‌کند که در آن کلاینت از سرور نشانی انتقال رله‌شده می‌خواهد و سرور ترافیک را میان آن کلاینت و همتاهایش هدایت می‌کند. پس رله داده را حمل می‌کند، که اساساً با فهرستی که تنها به دیدن هم کمک می‌کند متفاوت است. تبادل نشانی رله با همتا گامی هماهنگی است که برنامه باید انجام دهد.
چیزی که نمی‌توانید وعده دهید مسیر مستقیم است. NAT متقارن و برخی دیوارهای آتش سازمانی سوراخ‌کردن را شکست می‌دهند، و وقتی چنین کنند سیستم یا به رله بازمی‌گردد یا شکست می‌خورد. همچنین نمی‌توانید نتیجه بگیرید که دو نقطه انتهایی ترجمه‌شده هرگز نمی‌توانند صحبت کنند؛ پشته‌ای پشتیبانی‌شده با پشتوانه رله دقیقاً به این دلیل وجود دارد که اغلب می‌توانند. تصمیم بگیرید دسترس‌پذیری مهم‌تر است یا مستقیم بودن، سپس بررسی کنید استقرار واقعاً کدام مسیر را انتخاب کرده است، به‌جای فرض کردن حالت مطلوب.
کارگزار از یک شبکه باریک‌تر است
وقتی نیازمندی یک برنامه است، یک کارگزار برنامه یا اتصال معکوسی که ایستگاه کاری آغاز می‌کند می‌تواند کوچک‌ترین پاسخ باشد. ایستگاه کاری بیرون را به کارگزار شماره‌گیری می‌کند، کارگزار کاربر راه دور را احراز هویت می‌کند، و تنها همان نشست برنامه حمل می‌شود. هیچ مسیری به زیرشبکه ایستگاه کاری ساخته نمی‌شود، پس به خطر افتادن نشست راه دور مسیری به هر دستگاه کناری را به ارث نمی‌برد.
این باریکی بهایی دارد: هر برنامه اضافی به یکپارچه‌سازی خودش نیاز دارد، و هر چیزی که برنامه درباره یک شبکه محلی فرض می‌کند، مانند اشتراک فایلی که روی سروری نزدیک باز می‌کند، ممکن است قابل دسترس نباشد. کارگزارها همچنین سیاست و ثبت رویداد را در یک جا متمرکز می‌کنند، که تا زمانی که آن جا خودش به قطعی تبدیل شود سودمند است.
مرزهای اعتماد را مقایسه کنید، سپس مسیر را آزمایش کنید
هابی که تونل‌ها را پایان می‌دهد می‌تواند ترافیکی را که مسیریابی می‌کند بخواند. رله می‌تواند تبادلی مستقل محافظت‌شده را حمل کند وقتی برنامه سرتاسر رمزنگاری می‌کند، و کارگزار معمولاً نشستی را که ارائه می‌دهد پایان می‌دهد. پیش از آنکه تصمیم بگیرید دو طراحی هم‌ارزند چون هر دو رمزنگاری شده‌اند، مشخص کنید حفاظت واقعاً کجا پایان می‌یابد.
سپس بررسی کنید ایستگاه کاری واقعاً به چه چیزی در خروج دسترسی دارد، چون هر طراحی بالا به آن وابسته است. این را روی ایستگاه کاری اجرا کنید و نام میزبانی را که قصد استفاده از آن را دارید جایگزین کنید.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comطراحی را تنها زمانی بپذیرید که عملیات راه دور موردنظر زیر هویت مجاز موفق شود، هویت تأییدنشده رد شود، و رفتار زمانی که مسیر مستقیم یا رله‌شده در دسترس نیست شناخته‌شده و مستند باشد. اتصال دوباره و زمینه راه‌اندازی عادی ایستگاه کاری را هم بگنجانید، چون نشستی که در دفتر از طریق LAN آغاز شده هیچ چیزی را که دسترسی راه دور به آن وابسته است آزمایش نمی‌کند.