همان زیرشبکه در دو طرف: LAN راه دور را به یک محدوده آزاد نگاشت کنید
نگاشت نشانی در سمت مشتری میتواند یک LAN راه دور همپوشان را زیر یک محدوده آزاد نشان دهد، اما فقط برخی مشتریها آن را اعمال میکنند و مسیر بازگشت به هر حال باید وجود داشته باشد.
خانه و دفتر هر دو 192.168.1.0/24 را اجرا میکنند، بنابراین درخواست به 192.168.1.1 دو پاسخ ممکن دارد و مشتری بدون پرسیدن یکی را انتخاب میکند. تغییر شماره یک شبکه اداری فعال بهندرت محبوب است و نشانیهای روتر اغلب در چاپگرها، دوربینها و مستندات جا افتادهاند. نگاشت نشانی در سمت مشتری میتواند شبکه راه دور را بهجای آن زیر یک محدوده آزاد نشان دهد و بخش میزبان میتواند یکسان بماند تا 192.168.1.20 بهصورت 10.203.41.20 دیده شود. نکته گیر این است که فقط برخی مشتریها آن را پیادهسازی میکنند و برای مسیر بازگشت کاری نمیکند.
دو دید از همان میزبان
نگاشت بخش میزبان را نگه میدارد و فقط بخش شبکه را تغییر میدهد. سپس همان ماشین بسته به جایی که میایستید در دو نشانی پاسخ میدهد. نوشتن هر دو ستون پیش از پیکربندی هر چیزی از خوانش نادرست بعدی گزارشها و قواعد دیوار آتش جلوگیری میکند.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
دستگاههای محلی در خانه نشانیهای 192.168.1.x خود را نگه میدارند و هدف تمرین همین است. چاپگر در اتاق کناری در دسترس میماند در حالی که دفتر زیر محدودهای که تداخل ندارد دیده میشود.
ترتیب آرگومانها تمام ترفند است
این گزینه یک جهت، یک شبکه و ماسک و یک نام مستعار میگیرد: شبکه اول همان چیزی است که مشتری میبیند و نام مستعار همان چیزی است که سرور میبیند. برای منابعی که پشت دروازه راه دور هستند، جهت همان شکل مقصد است. جابهجا کردن دو شبکه چون آرگومان آخر نام مستعار خوانده میشود همان خطایی است که تونلی میسازد که وصل میشود و هیچ چیزی را نگاشت نمیکند.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"
مسیر همان چیزی است که بستههای مشتری برای محدوده جدید را به تونل میفرستد؛ ترجمه مقصد را در مسیر بازنویسی میکند. پاسخ از 192.168.1.20 به 10.203.41.20 بازنویسی میشود تا سوکت روی مشتری سازگار بماند. یک میزبان تنها با ماسک تمامطول به همین شکل کار میکند، تا زمانی که مسیر و نگاشت همان نشانی را توصیف کنند.
این نگاشت نشانی است، نه نگاشت پورت. دو سرویس روی یک میزبان با آن جدا نمیشوند و پروتکلی که نشانیهای IP را درون بار خود جای میدهد همچنان نشانیهای واقعی را میبیند.
نگاشت مسیر بازگشت ایجاد نمیکند
ترجمه در مشتری رخ میدهد، بنابراین سرور همچنان باید پاسخها را به تونل مسیریابی کند و دیوار آتش آن همچنان باید اجازه دهد. اگر دروازه راه دور نداند چگونه به زیرشبکه تونل برسد، درخواست میرسد و پاسخ از در اشتباه خارج میشود؛ نگاشت فقط شکست را شبیه مشکل مشتری نشان میدهد.
قواعد سمت سرور باید نشانیهایی را توصیف کنند که پس از ترجمه روی سرور وجود دارند، نه محدوده قابل مشاهده برای مشتری. کپی کردن نام مستعار در یک قاعده اجازه یک بعدازظهر را هدر میدهد، زیرا هیچ بستهای در آن سمت آن را حمل نمیکند.
محدوده نام مستعاری انتخاب کنید که با هیچ چیز دیگری که مشتری مسیریابی میکند تداخل نداشته باشد: یک VPN دیگر، یک شبکه کانتینر، یک دفتر دوم. تداخل در اینجا ابهام اصلی را زیر شمارهای متفاوت بازمیگرداند و دیدنش سختتر است چون نشانیها ناآشنا به نظر میرسند.
نامها و بارها از ترجمه جان سالم به در میبرند
نام میزبانی که به 192.168.1.20 واقعی تفکیک میشود مرورگر را به دستگاه محلی میفرستد نه راه دور، مهم نیست جدول مسیریابی چه میگوید. پاسخ DNS خصوصی باید به محدوده قابل مشاهده برای مشتری اشاره کند، در حالی که گواهی TLS همچنان نامی را دارد که برنامه انتظار دارد. با نام آزمایش کنید نه با نشانی، زیرا نشانی میتواند کار کند در حالی که نام بیصدا در جهت اشتباه تفکیک میشود. وقتی دروازه راه دور آن ناحیه را نیز سرویس میدهد، رکوردهای خودش هم به محدوده قابل مشاهده برای مشتری نیاز دارند.
تغییر مسیرها، URLهای جاسازیشده و برنامههایی که نشانی خود را در یک بار میدهند میتوانند به گونهای بشکنند که هیچ نگاشت بستهای آن را تعمیر نکند. با آنها مانند یک مشکل برنامه رفتار کنید و تلاش را بر همان اساس بسنجید پیش از آنکه قول دهید تغییر شماره لازم نیست.
سه بررسی پیش از تعهد
نخست، پیادهسازی مشتری را تأیید کنید. Community OpenVPN این گزینه را پشتیبانی میکند؛ پایگاه کد OpenVPN 3 آن را در میان ویژگیهای پشتیبانینشده فهرست میکند، بنابراین پروفایلی که به مشتری به سبک Connect فرستاده میشود ممکن است بهسادگی آن را نادیده بگیرد. دستوری که پذیرفته و هرگز اعمال نمیشود از خطا بدتر است، چون تونل سالم به نظر میرسد.
دوم، مسیر و ترجمه را جداگانه با یک پنجره تشخیصی کوتاه در سطح جزئیات بالا بررسی کنید و سپس سرویس واقعی را بهجای ping آزمایش کنید. سوم، تأیید کنید که روتر محلی و منبع راه دور از دید مشتری قابل تشخیص میمانند، چون هدف اصلی همان بود.
اگر مشتری نمیتواند ترجمه را انجام دهد، از سمت دروازه کمک بخواهید یا تغییر شماره را بپذیرید. افزودن مسیرهای بیشتر برای همان نشانی یک طراحی نیست.