دو سایت، یک زیرشبکه: برای هرکدام یک نمای مستعار بسازید

دو سایت مشتری هر دو 192.168.50.0/24 را اجرا می‌کنند و یک مهندس راه‌دور باید در هرکدام به چاپگری با همان نشانی برسد. هیچ ترفند مسیریابی این ابهام را به‌تنهایی حل نمی‌کند. هر سایت به نمای نشانی متمایز نیاز دارد و دروازه باید پیش از ارسال هر چیزی، سایت را از آن نما انتخاب کند.

این طرح چهار بخش دارد: پیشوندهای مستعار، هر دو جهت ترجمه، سیاست لایه پوششی و نام‌ها. هر بخش باید با بقیه هم‌خوان باشد.

برای هر سایت یک پیشوند مستعار انتخاب کنید

به هر سایت یک پیشوند مستعار کامل بدهید که به هیچ‌کس دیگری در محیط تعلق ندارد. یک طرح دو سایتی می‌تواند 192.168.50.0/24 سایت A را به 172.21.10.0/24 و LAN یکسان سایت B را به 172.21.20.0/24 نگاشت کند. نامزدها را در برابر هر شبکه مشارکت‌کننده بررسی کنید، از جمله VPCهای ابری و سایر استخرهای VPN. فضای نشانی خصوصی میان همه سازمان‌ها مشترک است، پس اینکه یک بازه RFC 1918 باشد هیچ چیزی درباره آزاد بودن آن در اینجا نمی‌گوید.

مستعار را، نه زیرشبکه بومی را، برای کاربران راه‌دور منتشر کنید. بازه بومی یک واقعیت محلی می‌ماند.

در هر دو جهت ترجمه کنید

در هر دو جهت ترجمه کنید. نگاشت مقصد یک نشانی مستعار را در سایت دارنده به نشانی بومی بازنویسی می‌کند. نگاشت مبدأ فراخوان راه‌دور را به مستعاری بازنویسی می‌کند که سایر سایت‌ها بتوانند تشخیص دهند.

نگاشت ایستای یک‌به‌یک قطعی است و این پیاده‌سازی را بی‌حالت نمی‌کند. ترجمه معکوس می‌تواند به وضعیت اتصال وابسته باشد و جابه‌جایی در صورت خطا یا مسیرهای نامتقارن می‌توانند طرحی را که آن را نادیده می‌گیرد بشکنند. مستندات پلتفرم تعیین می‌کند کدام‌یک از این‌ها اعمال می‌شود.

مرحله دقیقی که سیاست، انتخابگرها و مسیرها در آن اعمال می‌شوند میان IPsec مبتنی بر سیاست، تونل‌های مبتنی بر مسیر و محصولات دیگر متفاوت است. برای همانی که اجرا می‌کنید طراحی کنید.

طرح را از میان لایه پوششی ببرید

در یک هاب، هر پیشوند مستعار را به مسیر سایتی که مالک آن است اختصاص دهید و فقط عبوری را مجاز کنید که کار به آن نیاز دارد. در یک مش، هر همتای مرتبط به همان پیشوند و دانش سیاست نیاز دارد. افزودن تونل‌ها نشانی‌دهی مبهم را به‌تنهایی درست نمی‌کند.

انتشار کل زیرشبکه گسترده‌تر از انتشار یک سرویس است. اگر فقط چند ماشین یا درگاه لازم است، قواعد دسترسی را از نگاشت تنگ‌تر نگه دارید.

ترجمه سرآیند محتواهای کاربردی برنامه را بازنویسی نمی‌کند. تغییرمسیرها، نشانی‌های جاسازی‌شده در فایل‌های پیکربندی و مجوزهای مبتنی بر مبدأ همگی هنوز می‌توانند نشانی بومی را حمل کنند. مسیر برنامه را آزمایش کنید، نه فقط ping را. پاسخ ICMP کارکننده اثبات می‌کند که نگاشت وجود دارد و هیچ چیزی درباره اینکه برنامه مستعار را می‌پذیرد نمی‌گوید.

نام‌هایی را که هر فراخوان می‌بیند درست کنید

به نام‌های نگهداری پاسخ‌هایی بدهید که با نمای فراخوان هم‌خوان باشد. اگر مهندس راه‌دور یک نام میزبان را تفکیک کند، باید نشانی مستعار آن سایت را برگرداند، نه بازه بومی مشترک را.

نماهای DNS را برای هر سایت پیش از نخستین پنجره نگهداری بررسی کنید. نامی که به زیرشبکه بومی تفکیک می‌شود فراخوان را به همان ابهامی برمی‌گرداند که قرار بود طرح آن را بردارد.

برای هر سایت ثبت و بررسی کنید

هر سایت را جداگانه از یک فراخوان واقعی بپذیرید و تأیید کنید کدام ماشین پاسخ داد. نشانی بومی، مستعار، دروازه دارنده و سرویس مجاز را با هم ثبت کنید.

همین فهرست است که تمایز را حفظ می‌کند وقتی سایت سومی با همان LAN پیش‌فرض می‌رسد. راهنمای IPsec NAT مبتنی بر سیاست یک مدل ترجمه مشخص را مستند می‌کند؛ این قراردادی برای همه پلتفرم‌ها نیست.