چه زمانی NAT درون VPN سایت به سایت جای خود را پیدا میکند
ترجمه میتواند یک پیشوند همپوشان یا مسیر بازگشت یکطرفه را نجات دهد، اما نشانیهایی را که هر سیاست میبیند تغییر میدهد. نگاشت را صریح طراحی کنید.
دو سایت هر دو از یک محدوده خصوصی استفاده میکنند و تونل بالا میآید در حالی که چیز مفیدی از آن عبور نمیکند. ترجمه پاسخ معمول است و پاسخی واقعی است: ارائه یک محدوده متفاوت به سمت دور میتواند یک همپوشانی یا مسیر بازگشتی را حل کند که شبکه دیگر نمیتواند مسیریابی کند. بخشی که نادیده گرفته میشود این است که ترجمه نشانیهایی را تغییر میدهد که هر تصمیم بعدی میبیند. با آن به عنوان یک تصمیم طراحی مستند با نگاشت نوشتهشده برخورد کنید، نه به عنوان قاعدهای که تا موفقیت یک ping اضافه میشود.
تصمیم بگیرید کدام نشانی بازنویسی میشود
ترجمه مبدأ آنچه را سرویس دور و گزارشهایش به عنوان مشتری میبینند تغییر میدهد، بنابراین یک میزبان شعبه هنگام ورود به نشانی دروازه تبدیل میشود. ترجمه مقصد یا پیشوند در عوض نشانی جایگزینی برای یک منبع دور ارائه میدهد. برخی استقرارها به ترجمه هماهنگ در هر دو طرف نیاز دارند تا دو شبکه در غیر این صورت یکسان را جدا کنند، و ترکیب همان جایی است که بیشتر سردرگمی شروع میشود.
مبدأ را پیش از ترجمه بنویسید، مقصد را آنگونه که برنامه نامش میگذارد، و جفت نشانیای که هر دروازه با آن تطبیق میدهد. سه ستون کافی است، و ستون سوم همان است که مردم جا میاندازند.
ترتیب انتخابگرها هم مهم است. انتخاب و ترجمه سیاست IPsec در مراحل تعریفشده رخ میدهد، بنابراین انتخابگری که برای نشانیهای پیش از ترجمه نوشته شده ممکن است هرگز با بسته در مرحلهای که فرض کردهاید تطبیق پیدا نکند. سیاستی را که نصب شده بررسی کنید، نه سیاستی را که قصد نصبش را داشتید، زیرا این دو دقیقاً وقتی واگرا میشوند که یک قاعده را یک مؤلفه میپذیرد و مؤلفه دیگر نادیده میگیرد:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
محموله و مسیر بازگشت را دنبال کنید
سروری که مبدأ ترجمهشده را به جای میزبان جداگانه شعبه ثبت میکند، هر قاعده یا گزارشی را که به نشانی اصلی گره خورده است میشکند. پیش از تغییر نگاشت، دریابید آیا چیزی در پاییندست بر اساس آن فیلد تصمیم میگیرد: فهرستهای دسترسی، گزارشهای حسابرسی، محدودیتهای نرخ، بررسیهای مجوز. هر یک از اینها جایی است که ترجمه بعداً به عنوان یک شکست توضیحناپذیر ظاهر میشود.
پروتکلهایی که نشانیها را درون محموله خود حمل میکنند به برنامهریزی جداگانه نیاز دارند، زیرا بازنویسی سرآیند بیرونی به ارجاع درونی دست نمیزند. FTP فعال، SIP و برخی محصولات دسترسی از راه دور موارد کلاسیک هستند، و طراحیای که آنها را نادیده بگیرد برای ترافیک وب کار میکند و برای برنامه مهم شکست میخورد.
ترافیک بازگشت به نگاشتهای حالتدار وابسته است. انتقال دروازه میتواند آن حالت را از دست بدهد، مسیریابی نامتقارن میتواند از آن دور بزند، و یک راهاندازی مجدد میتواند آن را پاک کند در حالی که نشستها در سمت دور باز میمانند. به همین دلیل درخواستی که به مقصد میرسد و نشستی که کامل میشود دو نتیجه پذیرش متفاوت هستند.
آن را با شمارهگذاری مجدد یک سایت بسنجید
شمارهگذاری مجدد یک سایت متضاد نگاشت را کاملاً حذف میکند و طرح نشانیای باقی میگذارد که بدون جدولهای ترجمه خوانده میشود. از نظر عملیاتی گران است: رکوردهای DNS، تخصیصهای ایستا، قواعد فایروال و هر نشانی مستند باید با هم تغییر کنند. هزینه یک بار، در یک بازه برنامهریزیشده، با وضعیت پایانی روشن پرداخت میشود. آنچه میخرید توانایی خواندن یک ضبط بسته سالها بعد بدون جدول جستجو است.
ترجمه از بیشتر تغییرات محلی دوری میکند و نگاشتی میسازد که باید برای همیشه در DNS، مستندات و عیبیابی نگهداری شود. هزینه به طور مداوم پرداخت میشود، به شکل هر مهندس آیندهای که باید بیاموزد یک پیشوند درون تونل معنای دیگری دارد.
برای یک اتصال موقت یا شبکه شریکی که کنترلش نمیکنید، هزینه مداوم معمولاً ارزش پرداخت را دارد. برای دو سایتی که مالک آنها هستید و سالها خواهید بود، شمارهگذاری مجدد اغلب تصمیم ارزانتری است وقتی مهاجرت صادقانه حساب شود.
هر دو جهت را با یک نشست واقعی اثبات کنید
یک نشست برنامه را آزمایش کنید نه یک کاوشگر واحد. یک درخواست پژواک موفق اثبات میکند یک جهت از یک پروتکل کار میکند، و کاملاً با مسیر بازگشتی سازگار است که برای هر چیز حالتدار شکست میخورد. از سرویسی که طراحی را برانگیخت استفاده کنید، و گزارش آن را در انتهای دور بخوانید تا ببینید کدام نشانی مبدأ را ثبت کرده است.
tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20
سپس تأیید کنید که فقط سرویسهای مورد نظر از طریق نگاشت قابل دسترسی هستند. ترجمه نشانیدهی را تغییر میدهد و برای مجوزدهی هیچ کاری نمیکند، بنابراین سیاست فایروال همچنان تصمیم میگیرد چه چیزی مجاز است. طراحیای که به یک پیشوند ترجمهشده مبهم به عنوان کنترل دسترسی خود تکیه میکند اصلاً کنترل دسترسی ندارد.
نگاشت، نشست آزمایششده و نشانیهایی را که هر طرف مشاهده کرده ثبت کنید. نفر بعدی که این تونل را اشکالزدایی میکند به آن سه واقعیت بیشتر از فایل پیکربندی نیاز دارد.