چرا route-nopull به‌تنهایی سرور فایل را دست‌نیافتنی می‌گذارد
نادیده گرفتن مسیرهای فشرده‌شده تنها نیمی از یک تونل تقسیم‌شده است. مالک مسیر را انتخاب کنید، پیشوند دفتر را دستی اضافه کنید و پیش از آنکه آن را حل‌شده بنامید سه جریان را آزمایش کنید.
سرور فایل خوب باز می‌شود و تماس ویدیویی در پنجره کناری شروع به لرزیدن می‌کند. هیچ‌چیز کند نیست و هیچ MTU اشتباه نیست: کلاینت شما فهرست مسیرهایی را که سرور به آن داد پذیرفت، پس هر بسته اکنون از فایروال دفتر خارج می‌شود. راه‌حل یک پرچم تنظیم دیگر نیست بلکه تصمیمی است درباره اینکه جدول مسیر کلاینت از آنِ کیست. آن تصمیم به یک جا تعلق دارد، و حالت‌های شکست زیر به شما می‌گویند کدام جا را واقعاً انتخاب کرده‌اید.
تصمیم بگیرید جدول مسیر از آنِ کیست
سه مالک ممکن است. سرور می‌تواند مسیرها و دروازه پیش‌فرض را فشار دهد، که در آن صورت کلاینت هر چه به آن گفته شود نصب می‌کند و تونل کامل می‌شود. پروفایل کلاینت می‌تواند با کنار گذاشتن فشارها و حمل خطوط مسیر خودش مالکیت را بردارد. مدیر اتصال دسکتاپ هم می‌تواند از طریق ویژگی‌های مسیر و مسیر پیش‌فرض خود مالک تصمیم باشد.
هر انتخاب به شکلی متفاوت شکست می‌خورد، و به همین دلیل ارزش دارد پیش از ویرایش پروفایل جدول را بخوانید. سطری که با نشانه شما می‌خواند همان مالکی است که واقعاً دارید.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
یکی را انتخاب کنید و بنویسیدش. مخلوط کردن دو، میزبانی را باقی می‌گذارد که مسیر پیش‌فرضش با مستندات خودش تناقض دارد، و مهندس بعدی نمی‌تواند بفهمد کدام لایه برنده شد. بازنده را صریحاً حذف کنید.
route-nopull فشارها را فیلتر می‌کند، مسیر اضافه نمی‌کند
route-nopull به پروفایل کلاینت تعلق دارد و ترتیبش در آن فایل بی‌ربط است چون فقط مقادیری را کنار می‌گذارد که از سرور می‌آیند. مسیرهای فشرده‌شده را کنار می‌گذارد، از جمله مسیر پیش‌فرض فشرده‌شده، در حالی که تونل همچنان به‌طور عادی بالا می‌آید.
نتیجه‌ای که مردم از دست می‌دهند این است که گزینه‌های DHCP فشرده‌شده با آن‌ها می‌روند. تنظیمات DNS ارسال‌شده از سرور هم کنار گذاشته می‌شود، پس نام‌های داخلی دیگر حل نمی‌شوند حتی اگر تونل سالم و سرور از طریق نشانی دست‌یافتنی باشد.
این تونلی بدون مسیر به پیشوند دفتر باقی می‌گذارد مگر اینکه خودتان یکی اضافه کنید: route-nopull و پس از آن route 10.30.0.0 255.255.0.0 در همان پروفایل. آن خط نشانی و ماسک حمل می‌کند؛ پرش بعدی را نام نمی‌برد.
شکلی جایگزین یک نشانه دروازه اضافه می‌کند، route 10.30.0.0 255.255.0.0 vpn_gateway، که ورودی را با نام به تونل اشاره می‌دهد. واردکننده‌ها در اینکه این گونه را ترجمه می‌کنند یا نه متفاوت‌اند، پس اگر ورودی در جدول هسته نیست اتصال ذخیره‌شده را بررسی کنید.
با جست‌وجوی مسیر بررسی کنید، نه با ping
ping به شما می‌گوید چیزی پاسخ داد. جست‌وجوی مسیر می‌گوید هسته کدام رابط را انتخاب می‌کند، و همان پرسشی است که واقعاً پرسیدید. چهار فرمان کوتاه مسیر گم‌شده را از مسیری که به دستگاه اشتباه اشاره می‌کند جدا می‌کنند.
با ip route show dev tun0 بخوانید تونل چه نصب کرده است. نبود کامل خروجی یعنی صفر مسیر، که تونل تقسیم‌شده کارآمد نیست، و نتیجه معمول افزودن فیلتر بدون خط صریح است.
سپس یک نشانی دفتر را با ip route get 10.30.5.7 و یک نشانی معمولی اینترنت را با ip route get 1.1.1.1 بررسی کنید. دومی باید رابط فیزیکی را نام ببرد؛ اگر تونل را نام می‌برد، فشار اصلاً فیلتر نشده است.
در پایان ip rule را بخوانید، چون قاعده‌ای سیاسی که تلاشی پیشین جا گذاشته می‌تواند جدولی را که همین حالا اصلاح کردید زیر پا بگذارد. پروفایل درست با قاعده‌ای کهنه در بالای آن دقیقاً شبیه پروفایل خراب به نظر می‌رسد. پیش از افزودن قاعده دیگر، قاعده‌ای را که بار قبل اضافه کردید حذف کنید.
زیرشبکه‌های هم‌پوشان شبیه تونل خراب به نظر می‌رسند
دو محدوده خصوصی می‌توانند از دید کلاینت یکسان باشند، و همان‌جاست که تونل تقسیم‌شده برای چیزی که ایجاد نکرده سرزنش می‌شود. اگر دفتر همان پیشوندی را بدهد که روتر خانه شما استفاده می‌کند، مسیر تونل روتر را می‌پوشاند و شبکه خانه طوری به نظر می‌رسد که ناپدید شده است.
نشانی روی رابط خودتان را با مسیری که پروفایل نصب می‌کند مقایسه کنید و پیش از تغییر هر چیزی از یک فهرست ساده نشانی استفاده کنید. هم‌پوشانی واقعی است و هیچ گزینه‌ای از پروفایل آن را حل نمی‌کند. چیزی که می‌توانید درست کنید نام‌گذاری است، تا نفر بعد دو محدوده ببیند نه یکی.
اصلاح‌های صادقانه شماره‌گذاری دوباره یک طرف یا ترجمه نشانی‌ها در دفتر است. سنجاق کردن یک مسیر میزبان به روتر تا وقتی نشانی روتر تغییر کند کار می‌کند، و بعد راز دومی روی اولی می‌شود.
کاری کنید تصمیم از اتصال دوباره جان سالم به در ببرد
ورودی‌های تایپ‌شده با دست از اتصال دوباره جان سالم به در نمی‌برند، و مدیر اتصال هر بار که پروفایل شروع می‌شود جدول را از نو می‌سازد. تصمیم را جایی بگذارید که اتصال ساخته می‌شود، چه پروفایل باشد چه تنظیمات ذخیره‌شده مدیر. سپس یک بار عمداً اتصال را دوباره راه‌اندازی کنید به‌جای آنکه رفتار را هنگام یک تماس کشف کنید. پروفایلی که فقط تا اتصال دوباره بعدی کار می‌کند تمام نشده است.
سه مسیر را هم‌زمان بیازمایید: میزبان دفتر با نشانی تحت‌اللفظی، همان میزبان با نام، و یک سایت عمومی معمولی. وسطی به سرویس نامی بستگی دارد که پس از کنار گذاشتن گزینه‌های DNS فشرده‌شده پیکربندی کردید، و همان است که بی‌صدا شکست می‌خورد.