آن نشانی L2TP همان IPCP است، نه اجاره DHCP در LAN

اتصال برقرار می‌شود و آداپتور نشانی در محدوده دفتر نشان می‌دهد، پس نتیجه طبیعی این است که VPN به شما نشانی LAN داده و در نتیجه شما را در LAN قرار داده است. هیچ‌یک از این دو نیمه کاملاً درست نیست. L2TP یک نشست PPP حمل می‌کند و PPP نشانی درونی IPv4 را با IPCP مذاکره می‌کند. آن نشانی پارامتر نشستی است که بین دو همتا توافق می‌شود، نه اجاره‌ای که سرور DHCP دفتر صادر می‌کند، و داشتن آن شما را همسایه روی سیم دفتر نمی‌کند.

دو نشانی در یک اتصال

در یک اتصال L2TP دو مذاکره مستقل وجود دارد. مذاکره بیرونی مسیری محافظت‌شده بین دستگاه شما و نقطه پایانی VPN روی هر شبکه‌ای که از قبل دارید برقرار می‌کند. مذاکره درونی همان نشست PPP است و نشانی نشست شما و نشانی طرف مقابل در آن توافق می‌شود. ترافیک اینترنت ممکن است کاملاً زیر نشانی سومی خارج شود، نشانی عمومی نقطه پایانی، و به همین دلیل صفحه بررسی VPN و نشانی آداپتور به‌ندرت با هم می‌خوانند.

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

IPCP دقیقاً چه می‌کند

IPCP پروتکل کنترل IPv4 برای PPP است. هر طرف پیام‌های Configure-Request می‌فرستد که گزینه‌های مورد نظرش را توصیف می‌کند و گزینه نشانی یکی از آن‌هاست. کلاینتی که هنوز نشانی ندارد معمولاً با 0.0.0.0 درخواست می‌کند و سرور با Configure-Nak پاسخ می‌دهد که نشانی مورد نظر خود برای کلاینت را حمل می‌کند. سپس کلاینت همان نشانی را درخواست می‌کند و نشست با یک نشانی محلی و یک نشانی دور برقرار می‌شود.

این تبادل در مشخصات PPP و IPCP مستند شده است و جزئیاتی را توضیح می‌دهد که شبیه باگ به نظر می‌رسد: نشانی را سرور بر اساس سیاست خودش انتخاب می‌کند که می‌تواند یک استخر، تنظیمی برای هر کاربر یا نشانی وابسته به هویت احرازشده باشد. وقتی استخر تمام شود یا سیاست با درخواست تعارض پیدا کند، احراز هویت می‌تواند موفق شود در حالی که مذاکره نشانی شکست می‌خورد و کلاینت اتصالی را گزارش می‌دهد که هرگز به آرامش نمی‌رسد.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

چرا LAN نمی‌تواند به شما پاسخ دهد

نشانی از محدوده طرف دور انتظاری ایجاد می‌کند که میزبان‌های آن LAN بتوانند به شما برسند، و بیشتر اوقات نمی‌توانند مگر اینکه سرور نشانی نشست شما را به تونل برگرداند. بودن درون یک استخر اظهارنظری درباره تخصیص است، نه درباره توپولوژی. سرور فایل دفتر هیچ مسیری به نشانی نشست شما ندارد مگر اینکه سرور VPN آن را هدایت کند، و حتی اگر هدایت کند ممکن است مجاز نباشد.

به همین دلیل است که محدوده‌های همپوشان مشکلاتی نامتناسب با اندازه ظاهری‌شان ایجاد می‌کنند. اگر استخر با LANی که کلاینت از قبل استفاده می‌کند همپوشانی داشته باشد، جدول مسیریابی کلاینت اکنون دو ادعا روی یک پیشوند دارد و اغلب ادعای نادرست به دلایلی که هیچ ربطی به تونل ندارد برنده می‌شود.

ابتدا نشست را بررسی کنید، سپس مسیر را

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

سه مرحله را از هم جدا نگه دارید

احراز هویت، مذاکره نشانی و هدایت بسته‌ها به شکل‌های متفاوتی شکست می‌خورند، و هر یک مسئول متفاوتی دارد. اعتبارنامه‌ها مسئله هویت است، تمام شدن IPCP مسئله سیاست سرور است و نبود مسیر بازگشت مسئله طراحی شبکه است. گزارش هر سه به‌عنوان “VPN خراب است” اصلاحی کند را تضمین می‌کند.

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