کپی‌کردن /32 تونل، زیرشبکهٔ دفتر را مسیریابی نمی‌کند
نشانی‌ای که VPN به آداپتر شما می‌دهد پیوند را توصیف می‌کند، نه مقصد را. پیشوند منبع را به پروفایل اضافه کنید و مسیر پیش‌فرض را دست‌نخورده بگذارید.
VPN متصل می‌شود، رابط نشانی‌ای با ماسک سی‌ودو بیتی نشان می‌دهد، و سرور دفتر دست‌نیافتنی می‌ماند. گام بعدی اغلب استفادهٔ دوباره از همان ماسک در یک مسیر است، به این تصور که رابط توصیف می‌کند تونل به کجا می‌رسد. چنین نیست. آن نشانی انتهای محلی یک پیوند نقطه‌به‌نقطه را توصیف می‌کند، و مقصدی که برایتان مهم است در پیشوندی دیگر در آن سوی آن قرار دارد.
دو چیز متفاوت با هم اشتباه گرفته می‌شوند: نشانی‌ای که تونل به شما داد، و شبکه‌ای که می‌خواهید از طریق آن برسید.
دو نشانی، دو کار
در تونل نقطه‌به‌نقطه، نشانی کارخواه غالباً یک نشانی میزبان واحد است چون دقیقاً یک همتا در انتهای دیگر پیوند وجود دارد. پارگان مشترک و ARP وجود ندارد، پس ماسکی که روی Ethernet بی‌معنی به نظر می‌رسید اینجا کاملاً عادی است.
پیشوند مقصد واقعیتی دربارهٔ شبکهٔ دفتر است، نه دربارهٔ تونل. اگر یک سرور لازم دارید، مسیر یک مسیر میزبان برای همان سرور است. اگر کل زیرشبکهٔ دفتر را لازم دارید، مسیر همان زیرشبکه است. هیچ‌یک از این دو پاسخ از رابط خوانده نمی‌شود، و انتخاب یکی چون کنار نشانی تونل ظاهر شده بود، همین است که یک پیکربندی کارآمد را خراب می‌کند.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
همان ردیف سوم جایی است که خوش‌بینی به قطعی تبدیل می‌شود. مسیریابی یک بازهٔ خصوصی کامل به تونلی که تنها به یک سایت خدمت می‌کند، ترافیک بی‌ربط را به راهی می‌راند که نمی‌تواند آن را برساند، و خرابی‌های حاصل شبیه VPN خراب به نظر می‌رسند نه مسیر بیش از حد گسترده.
پیشوند را از الزام انتخاب کنید
پیش از دست زدن به پروفایل، الزام را در یک جمله بنویسید: کدام میزبان‌ها باید در دسترس باشند، و تنگ‌ترین پیشوندی که آن‌ها را می‌پوشاند کدام است؟ یک سرور یعنی مسیر میزبان. یک زیرشبکه یعنی مسیر زیرشبکه. یک بازه از زیرشبکه‌ها یعنی خلاصه، و خلاصه یعنی این وعده که هر نشانی درونش در دسترس است، که به‌ندرت درست است.
سپس عدد را با آنچه دفتر واقعاً استفاده می‌کند بسنجید. کپی‌کردن پیشوند از یک پیام چت بدون تأیید آن با طرح نشانی‌ابی سایت، همین است که مسیری را به زیرشبکه‌ای می‌رساند که مالک ندارد.
همچنین به یاد داشته باشید که مسیر یک راه است، نه یک اجازه. دروازه هنوز تصمیم می‌گیرد که آیا کارخواه شما می‌تواند از مقصد استفاده کند، و یک سرویس هنوز می‌تواند شما را رد کند. نصب درست مسیر بسته را به آنجا می‌رساند و هیچ پاسخی دربارهٔ مجوزدهی نمی‌دهد.
به پروفایل بیفزایید، هرگز جایگزینش نکنید
مسیرها در پروفایل NetworkManager ویژگی چندمقداری‌اند، و تفاوت میان تنظیم‌کردن و افزودن یک نویسه است. از شکل به‌علاوه استفاده کنید تا یک ورودی بیفزایید و هر چیزی را که پیش‌تر ذخیره شده نگه دارید.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"بدون به‌علاوه، انتساب کل فهرست را جایگزین می‌کند. در پروفایلی که پیش‌تر چند پیشوند دارد، این کار بی‌صدا آن‌هایی را که کار می‌کردند حذف می‌کند، و نشانه بعداً به شکل سرویسی می‌آید که پیش‌تر از این لپ‌تاپ در دسترس بود.
به‌جای نام از UUID استفاده کنید. نام‌ها پس از بازیابی تکراری می‌شوند، و اتصالی که ویرایش می‌کنید ممکن است همانی نباشد که ترافیک شما را می‌برد. نخست بررسی کنید که ورودی یکسانی از قبل وجود دارد یا نه، چون افزودن تکراری حتی وقتی بی‌ضرر است، نابسامان است.
این مرجع ویژگی‌های مسیر مقصد، گام بعدی اختیاری، معیار و نحو ویژگی‌ها را برای نسخهٔ نصب‌شده مستند می‌کند. پیش از افزودن گام بعدی آن را بخوانید، چون نیاز بودنش به یکپارچه‌سازی و توپولوژی بستگی دارد، و حدس‌زدنش از نخستین نشانی در فهرست رابط‌ها روش نیست.
مسیر پیش‌فرض و DNS تصمیم‌های جدایی هستند
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
مسیرهای خودکار چیز دیگری هستند که نباید سرسری به هم زد. سرکوب آن‌ها برای حل یک ورودی گمشده می‌تواند چند مسیر کارآمد را بردارد، و کسی که این را پیشنهاد داد معمولاً پروفایل دیگری با pushهای متفاوت را نگاه می‌کرد.
DNS راه خودش و خرابی‌های خودش را دارد. نامی که از طریق resolver اشتباه به نشانی درست تحویل داده می‌شود، یا resolverی که برای ناحیهٔ خصوصی نمی‌تواند پاسخ دهد، شبیه مشکل مسیریابی به نظر می‌رسد در حالی که مسیر بی‌نقص است. نشانی و نام را جداگانه بیازمایید، سپس تصمیم بگیرید کدام لایه واقعاً شکست خورده است.
بررسی کنید چه چیزی اعمال شده است
تغییر ذخیره‌شده تغییر اعمال‌شده نیست. از طریق چرخهٔ عمر پشتیبانی‌شدهٔ مدیر دوباره متصل شوید، سپس مسیر واقعی مقصد موردنظر و قواعد سیاستی را که تعیین می‌کنند کدام جدول بررسی شود نگاه کنید.
اگر پیشوند آنجاست و اتصال هنوز شکست می‌خورد، به مشکل دیگری رفته‌اید: انتخاب نشانی مبدأ، مسیر بازگشت در انتهای دور، یا سرویسی که کارخواه شما را رد می‌کند. هر یک از این‌ها جای بهتری برای نگاه‌کردن از پروفایلی است که پیش‌تر اصلاحش کرده‌اید.