وقتی openfortivpn وصل می‌شود چه کسی باید مالک مسیرها و DNS باشد؟

چهار مرحله در یک نشست سالم openfortivpn روی هم سوار می‌شوند. کلاینت در دروازه احراز هویت می‌کند و یک اتصال TLS آغاز می‌کند، سپس PPP را درون آن اتصال اجرا می‌کند، سپس آدرس و اطلاعات DNS می‌گیرد، و در پایان مسیرهای میزبان و تنظیمات resolver را اعمال می‌کند. هر مرحله می‌تواند زنده باشد در حالی که مرحله بعدی نیست، و به همین دلیل «متصل» در رشته‌های پشتیبانی واژه‌ای چنین لغزان است.

تصمیمی که بیشتر سردرگمی را برمی‌دارد این است که مالک مرحله آخر کیست. یا کلاینت VPN خودش تغییرات میزبان را اعمال می‌کند، یا مؤلفه دیگری این کار را می‌کند، و مخلوط کردن این دو در نیمه راه همان چیزی است که باعث می‌شود مسیرها و فایل‌های resolver در نهایت نشست‌های متفاوتی را توصیف کنند.

چهار مرحله که شبیه یک اتصال به نظر می‌رسند

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

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

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

چه کسی جدول مسیریابی را ویرایش می‌کند

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

انتقال را تنها زمانی انتخاب کنید که چیز دیگری واقعاً مالک مسیریابی باشد. یکپارچه‌سازی مدیر شبکه، فضای نام شبکه کانتینر یا عاملی برای مسیریابی کل سایت ممکن است از قبل بداند چگونه همان پیشوندها را نصب و پاک کند. در آن صورت، دادن گزینه no-routes مانع می‌شود دو نویسنده بر سر یک جدول بجنگند، که مسابقه‌ای است و خود را به شکل از دست رفتن متناوب یک زیرشبکه نشان می‌دهد نه یک خرابی تمیز.

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

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

چه کسی مالک DNS و فایل resolver است

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

روی یک میزبان مدرن Linux ممکن است resolver توسط یک stub محلی مدیریت شود، و بازنویسی فایل resolver پشت سر آن stub پیکربندی‌ای می‌سازد که درست به نظر می‌رسد و ناسازگار رفتار می‌کند. اگر میزبان از قبل مدیر resolver را اجرا می‌کند، بگذارید مالک DNS باشد و سرورهای تونل را از طریق رابط پشتیبانی‌شده‌اش به آن بدهید. گزینه no-dns کلاینت در آنجا انتخاب درست است، نه یک راه‌حل موقت.

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

امتیاز، آمادگی و واگذاری

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

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

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