openfortivpn مدام DNS را بازنویسی می‌کند؟ مالک واقعی را پیدا کنید

پیوند را از لحظه‌ای که بالا می‌آید دنبال کنید: کلاینت احراز هویت می‌کند، pppd مذاکره می‌کند و سپس چیزی تنظیمات DNS را در سیستم‌عامل می‌نویسد. اگر تنها می‌دانید که VPN حل‌کننده شما را تغییر داد، هنوز نمی‌دانید کدام یک از این مراحل این کار را کرد. دو تا از آن‌ها می‌توانند، و روی کلاینتی که از یکپارچه‌سازی مستند pppd استفاده می‌کند آن‌قدر نزدیک به هم اجرا می‌شوند که مانند یک کنشگر واحد به نظر برسند. نام بردن نویسنده گام اول است؛ انتخاب جانشین آن گام دوم است، و این تصمیمی جدا با حالت‌های شکست خودش است.

توالی زیر کلاینت را به سمت بیرون دنبال می‌کند: پیوند چه چیزی را تغییر داد، کدام کلید کدام نویسنده را ساکت می‌کند، چه کسی باید کار را به دست بگیرد و چگونه تأیید کنید که نتیجه از اتصال دوباره جان سالم به در می‌برد. هر مرحله ردپای متفاوتی باقی می‌گذارد، و این ردپا همان چیزی است که می‌گوید تحویل واقعاً رخ داده است یا نه.

با آنچه پیوند واقعاً تغییر داد شروع کنید

یک بار با فراخوانی معمول خود وصل شوید و تفکیک را قبل و بعد مقایسه کنید. روی میزبان Linux که systemd-resolved اجرا می‌کند، resolvectl status سرورهای DNS و دامنه‌های جست‌وجو را برای هر پیوند چاپ می‌کند، و پیوند tun یا ppp تازه‌ای که سرورهای خودش را حمل می‌کند اثر انگشت به‌روزرسانی از سمت کلاینت است. در macOS، scutil --dns پیکربندی حل‌کننده را به همان ترتیبی نشان می‌دهد که برنامه‌ها آن را مشورت می‌کنند.

آن را با فایلی مقایسه کنید که انتظار داشتید تغییر کند. یک ورودی وابسته به پیوند در نمای هر پیوند و یک /etc/resolv.conf بازنویسی‌شده دو نتیجه متفاوت‌اند، و دومی می‌تواند پیوند نمادینی باشد که چیز دیگری کاملاً مدیریتش می‌کند. آدرس حل‌کننده، دامنه‌های جست‌وجو و نام واسط را در همان لحظه ثبت کنید؛ تغییر در هر یک از آن‌ها به نویسنده دیگری اشاره می‌کند. بدون این خط پایه، هر اصلاح بعدی حدسی است درباره اینکه کدام یک از سه جزء جابه‌جا شد.

دو کلید و نویسنده‌ای که هر یک ساکت می‌کند

openfortivpn قطعه‌ای از گزینه‌ها را مستند می‌کند که هر دو نویسنده‌ای را که می‌تواند کنترل کند خاموش می‌کند، و هر کلید معادل کاملاً نوشته‌شده‌ای دارد که راهنما آن را همان تنظیم می‌داند.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns کلاینت را از اعمال سرورهای DNS که از دروازه آموخته بازمی‌دارد، در حالی که --pppd-no-peerdns pppd را از هل دادن DNS همتا به سیستم بازمی‌دارد. راهنمای upstream هشدار می‌دهد که به‌روزرسانی‌های DNS از طریق PPP می‌توانند با به‌روزرسانی‌های DNS خود کلاینت مسابقه دهند، و به همین دلیل هر دو کلید باید در قطعه باشند، نه اینکه هر یک از آن‌ها کافی دانسته شود.

هیچ کلیدی حل‌کننده جانشین را نام نمی‌برد، و هیچ‌کدام مدیر شبکه، کلاینت DHCP یا یکپارچه‌سازی جداگانه VPN را از نوشتن تفکیک پس از آن بازنمی‌دارد. ساکت کردن دو نویسنده میدان را باز رها می‌کند، نه مالکیت‌شده. اگر جزء سومی از قبل DNS را مدیریت می‌کند، قطعه هیچ چیز قابل مشاهده‌ای را تغییر نمی‌دهد؛ اگر هیچ چیز آن را مدیریت نمی‌کند، همین حالا تنها منبع تفکیک نام‌های خصوصی را حذف کرده‌اید. این ترتیبی معتبر است تنها وقتی مالک جانشین ابتدا انتخاب و به‌تنهایی آزمایش شده باشد.

پیش از غیرفعال کردن هر چیزی مالک را انتخاب کنید

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

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

تفکیک را برای هر پیوند بررسی کنید، نه برای هر فایل

یک /etc/resolv.conf تنها فهرستی از آنچه برنامه‌ها واقعاً روی میزبانی با تفکیک محدود یا هر دامنه استفاده می‌کنند نیست، پس وضعیت حل‌کننده را همان‌گونه که سکو آشکار می‌کند بخوانید.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

دوباره وصل شوید و وضعیت قطع‌شده را تأیید کنید

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

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

اگر با سیاستی که نوشتید مطابقت داشته باشند، تحویل کامل است و کلاینت VPN دیگر یکی از نویسندگان نیست. اگر مقداری چند ثانیه پس از بالا آمدن پیوند به عقب برگردد، چیز دیگری هنوز پیکربندی را اعمال می‌کند، و گام بعدی شناسایی آن جزء است نه افزودن پرچم دیگر. وضعیت نهایی که می‌خواهید بی‌رویداد است: یک مالک، یک سیاست مستند، و میزبانی قطع‌شده که دقیقاً همان‌گونه تفکیک می‌کند که پیش از وجود تونل می‌کرد.