tun از پیش ساخته‌شده در OpenVPN: مقایسه دو مدل مالکیت

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

نام، اتصال نیست

dev tun1 آن رابط نامدار را از OpenVPN می‌خواهد، و ساخت‌های سنتی فضای کاربر تلاش می‌کنند آن را باز کنند. اگر نام از الگوی معمول tun یا tap پیروی نکند، پروفایل به dev-type متناظر هم نیاز دارد، چون نوع هرگز از یک رشته استنتاج نمی‌شود. دستگاه TAP دستگاهی TUN با برچسب دیگر نیست: اتصال دستگاه اشتباه یا یکسره شکست می‌خورد یا پیوندی می‌سازد که قاب‌هایی را حمل می‌کند که هیچ‌کس انتظارش را ندارد. پیش از هر چیز نوع را بررسی کنید، چون هر بررسی بعدی فرض می‌کند دو طرف در آن توافق دارند. از آنجا به بعد تأیید کنید که فرایند واقعاً می‌تواند دستگاه را باز کند، نه فقط آن را ببیند.

dev tun1
dev-type tun

رابط شبکه و /dev/net/tun دو شیء متفاوت‌اند: یکی پیوندی درون یک فضای نام است، دیگری دستگاه نویسه است که برنامه‌ای در فضای کاربر برای اتصال به کار می‌برد. مستندات Linux TUN/TAP این مسیر اتصال و قواعد مالکیت دستگاه‌های پایا را توضیح می‌دهد. صدف ریشه که می‌تواند ip link را اجرا کند فقط ثابت می‌کند صدف دسترسی دارد، نه اینکه سرویس‌گیر دارد. مالکیت گره دستگاه، مجموعه توانایی‌های سرویس و کاربری که با آن اجرا می‌شود باید همه هم‌تراز شوند تا باز کردن موفق شود.

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

چه کسی پیوند را پیکربندی می‌کند: دو مدل مالکیت

در مدل نخست OpenVPN نشانی‌ها و مسیرها را به‌عنوان بخشی از بالا آوردن اتصال پیکربندی می‌کند. این رفتار پیش‌فرض و آسان‌ترین برای استدلال است، چون یک مؤلفه وضعیت را می‌سازد و دوباره آن را برمی‌دارد. در مدل دوم یک مدیر بیرونی مالک رابط است و ifconfig-noexec جلوی اجرای فرمان‌های پیکربندی نشانی توسط OpenVPN را می‌گیرد و پارامترها را به اسکریپت‌ها می‌سپارد. آن‌گاه مدیر باید خودش پیکربندی درست محلی و همتا را اعمال کند، که کاری بیش از آن است که نام گزینه می‌رساند. انتخاب میان این دو پرسش درباره این است که چه کسی می‌تواند پیوند را در حالت برپا تغییر دهد.

ifconfig-noexec تنها نشانی‌ها را پوشش می‌دهد: جدول مسیریابی دست‌نخورده می‌ماند و پیکربندی مسیرها به‌عهده route-noexec است. دو فرمان را دو کنترل جدا با دو مالک جدا بدانید، چون تنظیم یکی و فرض کردن دیگری منبع رایج پیوندهای نیمه‌پیکربندی‌شده است. برای هر لایه دقیقاً یک مالک برگزینید، نشانی‌ها در یک جا و مسیرها در یک جا. مدیر شبکه و کمک‌کننده VPN که هر دو نشانی می‌نویسند، همان راهی است که قطع اتصال وضعیتی را پاک می‌کند که طرف دیگر هنوز به آن وابسته است.

دستگاه را از فضای نامی که اهمیت دارد بررسی کنید

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

ip -details link show dev tun1
ip tuntap show

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

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

دو گونه مختلف پایداری

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

پشتوانه را هم تأیید کنید، چون رابط از پیش ساخته‌شده هیچ نمی‌گوید که کدام پیاده‌سازی آن را باز خواهد کرد. ساخت‌های جامعه که مسیر مستقیم داده را دارند تلاش می‌کنند از آن استفاده کنند مگر اینکه طراحی چیز دیگری بگوید. جایی که نسخه این کلید را پشتیبانی می‌کند، disable-dco به‌جای آن مسیر فضای کاربر را برمی‌گزیند؛ موتورهای قدیمی‌تر و کارخواه‌های دیگر چنین فرمانی ندارند، پس شرط نسخه را کنار گزینه نگه دارید و فرض نکنید که اعمال می‌شود.

وقتی تنها راه‌اندازی آزمایش شود چه چیزی می‌شکند

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

بازنشانی نرم باید نشست را قابل استفاده و منابع را سالم بگذارد، و همین کار persist-tun است. توقف کامل همان جایی است که مدیر بیرونی خود را نشان می‌دهد: اگر پیوند یا نشانی‌هایش از توقف جان سالم به در ببرند، کسی دیگر مالک آن‌هاست، و این یا همان وضعیتی است که مستند کرده‌اید یا همان اشکالی که تازه یافته‌اید. هر دو مشاهده را کنار پروفایل ثبت کنید تا تغییر بعدی از شواهد شروع شود نه از یک نمودار.