آنچه route-nopull در OpenVPN واقعاً جلوی ارسالش را توسط سرور می‌گیرد
route-nopull مسیرها و گزینه‌های DHCP ارسال‌شده را دور می‌ریزد، نه دست‌دادن را. میان آن، pull-filter یا هیچ‌کدام انتخاب کنید، سپس مسیرها را خودتان اضافه کنید.
شما route-nopull را در نمایهٔ یک کلاینت گذاشتید تا تونل مسیر پیش‌فرض شما را نبلعد، و اکنون زیرشبکهٔ دفتر دست‌نیافتنی است در حالی که کلاینت هنوز می‌گوید متصل است. هر دو مشاهده درست‌اند و هیچ چیز شکست نخورده است. این پرچم به کلاینت می‌گوید مسیرها و ورودی‌های DHCP را که سرور ارسال می‌کند نادیده بگیرد، که دستوری باریک‌تر از چیزی است که بیشتر مردم هنگام افزودن آن انتظار دارند. آنچه می‌ماند تونلی کارآمد است که هیچ نظری دربارهٔ این ندارد کدام مقصدها باید از آن استفاده کنند.
همین شکاف تمام تصمیمی است که این مقاله دربارهٔ آن است. یا سرور شبکه را توصیف می‌کند، یا کلاینت این کار را می‌کند، و پرچم آن کار را به کلاینت می‌سپارد بدون اینکه هیچ بخشی از آن را برای شما انجام دهد.
پرچم در زمان اتصال چه چیزی را خاموش می‌کند
کلاینت OpenVPN که می‌کشد معمولاً پس از احراز هویت بسته‌ای از سرور می‌گیرد: مسیرها، تغییر مسیر دروازهٔ پیش‌فرض، سرورهای DNS و چند دستور تنظیم. وقتی route-nopull در کار است، کلاینت هنوز نشست را می‌پذیرد، هنوز گواهی‌ها را بررسی می‌کند، هنوز دربارهٔ رمزها و keepalive مذاکره می‌کند، و هنوز رابط را بالا می‌آورد. آنچه کنار می‌گذارد اعمال خطوط route ارسال‌شده و خطوط dhcp-option ارسال‌شده است، از جمله DNS.
سردرگمی از یک نشانگر سبز در کنار برنامه‌ای مرده می‌آید. تونل وجود دارد؛ نگاشت مقصدها به آن تونل وجود ندارد. هیچ چیز در پنل وضعیت کلاینت میان «متصل و مسیریابی‌کننده» و «متصل و بی‌اثر» فرق نمی‌گذارد، چون از دید تونل هر دو یک حالت‌اند.
چرا یک تونل زنده هنوز می‌تواند هیچ چیز را مسیریابی نکند
رابط با نشانی خودش ظاهر می‌شود و در یک پیوند نقطه‌به‌نقطه اغلب چیزی مشخص‌تر از یک مسیر میزبان به همتا ندارد. یک زیرشبکهٔ خصوصی تنها زمانی دست‌یافتنی می‌شود که مسیری با پیشوند درست به آن رابط اشاره کند، و با خاموش بودن ارسال آن مسیر هرگز نمی‌رسد. نمایهٔ دانلودشده هم معمولاً نمی‌تواند کمک کند، چون با این فرض نوشته شده که سرور دقیقاً همین اطلاعات را تأمین می‌کند. به همین دلیل رابط می‌تواند سالم به نظر برسد در حالی که زیرشبکه تاریک می‌ماند.
پس خواندن نمایه چیز بسیار کمی را اثبات می‌کند. در عوض وضعیت در حال اجرا را روی ماشین متصل بخوانید:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10نشانی بدون مسیر زیرشبکه در فرمان دوم امضای این مشکل است. فرمان سوم سپس به پرسشی پاسخ می‌دهد که واقعاً برای کاربران مهم است، چون رابطی را گزارش می‌کند که هسته برای یک مقصد مشخص انتخاب می‌کند، نه فهرستی را که امید داشتید استفاده کند. اگر از طریق پیوند فیزیکی شما پاسخ دهد، تونل اصلاً در مسیر نیست.
حل نام به دلیلی مرتبط شکست می‌خورد، نه دلیلی جدا. ورودی‌های dhcp-option DNS ارسال‌شده با همان پرچم نادیده گرفته می‌شوند، پس پرس‌وجوها برای میزبان‌های داخلی به هر حل‌کننده‌ای می‌روند که شبکهٔ محلی فراهم کرده است. آن حل‌کننده هیچ ناحیه‌ای برای دفتر ندارد، پس پرس‌وجو شکست می‌خورد یا پاسخ عمومی برمی‌گرداند، و خرابی مانند مشکل سرور به نظر می‌رسد در حالی که مشکل پیکربندی کلاینت است. آزمایش نشانی پیش از نام همان چیزی است که این دو را جدا می‌کند.
انتخاب میان پرچم و یک فیلتر پیشوند
این دو گزینه شکل‌های متفاوتی از یک شکایت را حل می‌کنند، و انتخاب بد همان چیزی است که حالت متصل-اما-بی‌فایده را می‌سازد. یکی سیاست ارسال‌شده را یکجا جایگزین می‌کند، در حالی که دیگری آن را بر پایهٔ پیشوند ویرایش می‌کند. جدول نسخهٔ کوتاه را می‌دهد، و بند پس از آن بخشی را پوشش می‌دهد که مردم را غافلگیر می‌کند.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter یک تطبیق‌دهندهٔ پیشوند با سه فعل است، پس می‌تواند خانواده‌ای از خطوط را بپذیرد، آن‌ها را بی‌صدا نادیده بگیرد، یا وقتی پیشوندی ظاهر می‌شود اتصال را کاملاً رد کند. همین رفتار آخر ارزش دانستن دارد: یک قاعدهٔ رد، اختلاف سیاست را به دست‌دادن ناموفق تبدیل می‌کند نه به یک حذف آرام. راهنمای OpenVPN 2.6 پیشوندهای پذیرفته‌شده و معنای دقیق هر فعل را فهرست می‌کند.
یک راه میانهٔ رایج این است که فقط redirect-gateway را رد کنید و بگذارید مسیرهای دفتر و DNS همان‌گونه که مقصود است برسند. این کار ارسال را برای بخش‌هایی که سرور بهتر از شما می‌فهمد کارآمد نگه می‌دارد و در همان حال مانع آن یک خطی می‌شود که مسیر پیش‌فرض شما را تصاحب می‌کرد.
افزودن مسیرها و یک حل‌کننده به‌صورت دستی
اگر پرچم را نگه دارید، نمایه باید همان چیزی را بگوید که سرور می‌گفت. دستورهای route در سمت کلاینت پس از برقراری اتصال اعمال می‌شوند، پس در کنار پرچم کار می‌کنند نه اینکه توسط آن مسدود شوند. آن‌ها را در نمایه بگذارید، نه در یک خط فرمان تعاملی، وگرنه اتصال دوبارهٔ بعدی حالت کارآمد را بازتولید نمی‌کند.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53خط DNS در موقعیت ناخوشایندی است: یک دستور سمت کلاینت است، اما برخی کلاینت‌ها آن را فقط از طریق یکپارچه‌سازی DNS سکو اعمال می‌کنند، که ممکن است وقتی پیوند تغییر می‌کند روی آن بنویسد. روی میزبان systemd، تنظیم حل‌کننده مستقیماً روی رابط تونل قابل پیش‌بینی‌تر از امیدواری به برنده شدن کلاینت در رقابت اولویت است:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comدامنهٔ مسیریابی به اندازهٔ نشانی مهم است. بدون آن، پرس‌وجوهای نام‌های عمومی هم ممکن است به حل‌کنندهٔ داخلی فرستاده شوند، و هر حل‌کنندهٔ داخلی که بازگشت را رد کند مرور را می‌شکند در حالی که ناحیهٔ خصوصی کار می‌کند. با آن، فقط نام‌های زیر آن پسوند به حل‌کنندهٔ تونل مسیریابی می‌شوند و بقیهٔ چیزها از پیوند فیزیکی پیروی می‌کنند.
بررسی نتیجه: نشانی، نام و مسیر بیرونی
سه آزمون شکست‌های ممکن را جدا می‌کنند. نشانی خصوصی را با IP بگیرید، سپس همان میزبان را با نام، سپس یک سایت عمومی معمولی. IP کارآمد با نام ناموفق به حل‌کننده اشاره دارد؛ IP ناموفق با نام کارآمد به مسیریابی اشاره دارد؛ شکست هر دو معمولاً یعنی تونل در مسیر نیست.
سپس به بیرون نگاه کنید نه به درون. مسیر خود نقطهٔ پایانی تونل باید از تغییر جان سالم به در ببرد، و هر شکست مسدودکننده باید به تونل محدود شود بدون اینکه نقطهٔ پایانی را بگیرد. کلاینتی که پس از افتادن تونل به مرور ادامه می‌دهد یک مشکل سیاست است نه مسیریابی، و در هیچ‌یک از سه آزمون بالا ظاهر نمی‌شود.
فهرست نهایی را در مستندات نمایه بنویسید: مسیرها، حل‌کننده، دامنه‌ها و دلیلی که هر یک وجود دارد. اتصال دوباره‌ای که همان جدول را بازتولید کند تنها شاهد کامل بودن سیاست محلی است. اگر برنامه‌ها با تونل بالا و گذراندن هر سه آزمون همچنان شکست می‌خورند، جای بعدی برای نگاه کردن دستهٔ مشکلات متصل-اما-آفلاین است، نه گواهی‌هایی که پیش‌تر بررسی شده‌اند.