حالت پل همان عبور VPN نیست: هر کدام چه چیزی را تغییر می‌دهد
حالت پل نقش ارسال روتر را تغییر می دهد؛ عبور فقط اجازه می دهد VPN یک کلاینت از آن بگذرد. هیچ کدام تونل نمی سازند، پس جایگزین یکدیگر نیستند.
حالت پل و عبور VPN در یک رشته عیب یابی نام برده می شوند، چون هر دو به عنوان راه حلی برای VPNی که متصل نمی شود پیشنهاد می شوند. این دو کارکردهای متفاوت روتر را توصیف می کنند و هیچ کدام به تنهایی تونل VPN نمی سازند. پل سازی تغییر می دهد که دستگاه چگونه به بخش های شبکه می پیوندد یا چه کسی مسیریابی را انجام می دهد؛ عبور تعیین می کند که آیا ترافیک VPN کلاینت می تواند از یک درگاه بگذرد. انتخاب گزینه نادرست یک مشکل کوچک را به یک بعدازظهر کامل تخصیص دوباره نشانی تبدیل می کند.
دو برچسب، دو کارکرد متفاوت
آزمون ساده است: می خواهید شکل شبکه را تغییر دهید یا بگذارید ترافیکی که از قبل وجود دارد از آن عبور کند؟ این دو درخواست متفاوت با پیامدهای متفاوت هستند.
مقایسه در یک جدول:
| Setting | What it actually does |
|---|---|
| Bridge mode | Changes the device's forwarding role: a modem bridge hands routing and NAT downstream, a software bridge joins selected interfaces |
| VPN pass-through | Lets a client's VPN traffic cross the router; the credentials and encryption stay with the client |
| Router VPN client | Terminates the tunnel on the router, so the router becomes the endpoint |
| Router VPN server | Accepts inbound tunnels, which needs an upstream path that can reach it |
فقط دو مورد آخر تونلی روی روتر می سازند. پل سازی و عبور هر دو نقطه پایانی را جای دیگری می گذارند، به همین دلیل هیچ کدام نمی توانند مشکلی را که کلاینت غایب یا سرور دسترس ناپذیر ایجاد کرده برطرف کنند. این تمایز به راحتی از دست می رود، چون تنظیمات در یک رابط کنار هم قرار دارند. پیش از باز کردن آن صفحه بنویسید کدام نقطه پایانی مالک تونل است.
کادر عبور نیز توصیف کاملی از پشتیبانی پروتکل نیست. عبور مدرن از NAT در IPsec از کپسوله سازی استاندارد UDP استفاده می کند، در حالی که ویژگی های کمکی قدیمی تر رفتار وابسته به پیاده سازی دارند.
برچسب بازاریابی که می گوید VPN پشتیبانی می شود نمی گوید کدام یک از این چهار نقش منظور است.
حالت پل چه چیزی را روی دستگاه شما تغییر می دهد
روی مودم یا روتر، گزینه پل معمولاً مسئولیت مسیریابی و NAT را به درگاه دیگری در پایین دست منتقل می کند. روی دستگاه نرم افزاری می تواند به معنای پیوند دادن رابط های محلی انتخاب شده در یک دامنه پخش باشد. دامنه دقیق به محصول بستگی دارد، پس مستندات مدل را بخوانید نه مستندات واژه را. هر دو تفسیر تخصیص نشانی، مرزهای دیوار آتش و شیوه رسیدن به مدیریت را تغییر می دهند.
همین بخش آخر دلیل آن است که پل سازی پاسخ اولیه بدی برای خرابی VPN است. ممکن است مسیر مدیریت را از دست بدهید در حالی که مشکل اصلی هنوز حل نشده است.
پیش از تغییر نقش شبکه از پیکربندی نسخه پشتیبان بگیرید، چون نشانی دهی می تواند با آن جابه جا شود.
پیش از تنظیم، نقش را انتخاب کنید
برای فرستادن ترافیک خانه از یک خروجی بیرونی، به یک کلاینت VPN سازگار روی روتر نیاز دارید، نه به یک پل. برای اتصال به خانه از جای دیگر، به نقش سرور و مسیری در بالادست نیاز دارید که بتواند به آن برسد. این دو نیاز جز واژه VPN تقریباً هیچ وجه اشتراکی ندارند. پیش از نگاه کردن به منو تصمیم بگیرید کدام را می سازید.
یک دستگاه می تواند هر دو نقش را پشتیبانی کند و باز هم نقش مورد نیاز شما را با سرعتی که انتظار دارید پشتیبانی نکند.
نقش یک تصمیم طراحی است؛ تنظیم پیامد آن است.
اگر فقط یک پروتکل شکست بخورد
وقتی یک پروتکل پشت روتری که در بقیه موارد کار می کند شکست می خورد، ابتدا انتقال و مسیر NAT همان پروتکل را بررسی کنید. تغییر کل حالت درگاه برای درست کردن یک کلاینت مانند سیم کشی دوباره یک خانه به خاطر سوختن یک لامپ است. بررسی کنید که آیا ترافیک در UDP کپسوله شده، آیا ویژگی کمکی روتر به آن پروتکل مربوط است و آیا خرابی متقارن است. سپس تصمیم بگیرید که آیا تغییر نقش واقعاً موجه است.
RFC 3948 کپسوله سازی UDP را توصیف می کند که به IPsec اجازه می دهد از NAT جان سالم به در ببرد، و همان استانداردی است که باید پیش از اعتماد به کادر عبور بررسی شود.
ثبت کنید چه چیزی را و چرا تغییر دادید، چون نفر بعد دستگاه را در حالت پل پیدا می کند و گمان می کند عمدی بوده است. نتیجه درست شبکه ای است که شکل آن را خودتان انتخاب کرده اید، نه شبکه ای که از یک جلسه عیب یابی به ارث برده اید.