OpenVPN روی VPS: هیچ دستگاه /dev/net/tun برای باز کردن وجود ندارد

اولین اجرا با پیامی دربارهٔ /dev/net/tun یا دستگاه TUN/TAP که باز نمی‌شود شکست می‌خورد. گواهی‌ها هنوز خوانده نشده‌اند، پس هیچ چیز در پروفایل مشکوک نیست. دیمن از هسته شیئی می‌خواهد که این مهمان ندارد.

آن شیء یک دستگاه نویسه‌ای است که ماژول tun از آن پشتیبانی می‌کند. اینکه بتوانید آن را بسازید بستگی دارد به اینکه هسته مالک کیست.

دیمن چه چیزی از هسته می‌خواهد

OpenVPN /dev/net/tun را باز می‌کند و از درایور یک رابط می‌خواهد. درایور همان ماژول tun است و گرهٔ دستگاه همان دستگیره‌ای است که فضای کاربر برای رسیدن به آن به کار می‌برد. اگر ماژول بارگذاری نشده باشد، ممکن است گره نباشد یا باز شدن شکست بخورد. هیچ‌یک از این دو حالت با ویرایش server.conf درست نمی‌شود.

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

ماشین مجازی یا مهمان با هستهٔ مشترک

روی KVM، Xen یا ماشین مجازی کامل دیگر، شما کنترل هسته را در دست دارید. می‌توانید ماژول بارگذاری کنید و گره را بسازید. روی OpenVZ، Virtuozzo یا کانتینری به سبک LXC، مهمان هستهٔ میزبان را شریک می‌شود، پس root درون آن نمی‌تواند ماژولی را بارگذاری کند که میزبان بارگذاری نکرده است.

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

پیش از تصمیم‌گیری دربارهٔ اینکه در کدام حالت هستید، ls -l /dev/net/tun، lsmod | grep tun و ip -brief link show را اجرا کنید.

روی ماشین مجازی، ماژول را هنگام بوت بارگذاری کنید

روی ماشین مجازی، modprobe tun معمولاً گرهٔ دستگاه را می‌سازد. بررسی کنید که ظاهر شود، سپس بارگذاری را از طریق پیکربندی ماژول‌های توزیع دائمی کنید، نه با تکیه بر فرمانی که یک بار تایپ شده است. گره‌ای که پس از راه‌اندازی مجدد ناپدید می‌شود، ماه بعد همان تیکت می‌شود.

همچنین بررسی کنید که هسته‌ای که بوت کرده‌اید اصلاً این ماژول را دارد. هستهٔ کم‌حجم ارائه‌دهنده ممکن است آن را نداشته باشد.

اگر گره وجود دارد اما باز شدن هنوز شکست می‌خورد، مجوزها و اعداد major/minor دستگاه مظنونان بعدی هستند. این‌ها اصلاحات محلی‌اند، نه درخواست از ارائه‌دهنده.

در کانتینر، دستگاه مالک میزبان است

در کانتینر، دستگاه و قابلیت دو نیاز جداگانه‌اند. runtime باید /dev/net/tun را عبور دهد و کانتینر برای ساختن رابط به قابلیت شبکه نیاز دارد. runtime بدون root که هیچ‌یک از این دو را نمی‌دهد، هرچگونه که پروفایل نوشته شود همان خطای باز شدن را تولید می‌کند. بسیاری از میزبان‌های OpenVZ کلید TUN/TAP را در پنل مشتری نشان می‌دهند و فعال کردن آن به‌همراه راه‌اندازی مجدد اغلب تمام راه‌حل است.

دو پرسش دقیق از ارائه‌دهنده بپرسید: آیا ماژول tun روی میزبان بارگذاری شده است، و آیا دستگاه درون این نمونه در دسترس است؟ تیکت مبهم پاسخ مبهم می‌گیرد.

چرا بازسازی ماژول به‌ندرت کمک می‌کند

ساختن ماژول درون مهمان به‌ندرت کمک می‌کند. کامپایل به پیکربندی همان هستهٔ در حال اجرا نیاز دارد و /proc/config.gz اختیاری است و در ایمیج‌های کمینه اغلب وجود ندارد. حتی یک ماژول سالم را نمی‌توان در هسته‌ای که کانتینر مالک آن نیست جای داد.

پس از ظاهر شدن دستگاه، سرویس را دوباره راه‌اندازی کنید و پیش از آزمودن ترافیک رابط را تأیید کنید. دیدن tun0 نشان می‌دهد که دیمن دستگاه را باز کرده است. هنوز چیزی دربارهٔ فورواردینگ، قواعد فایروال یا مسیرهایی که کلاینت‌ها دریافت می‌کنند نمی‌گوید.

این‌ها پرسش‌های جدا با شواهد جدایند. دستگاه غایب یک شکست پیش‌نیاز است؛ تونلی که وجود دارد اما چیزی حمل نمی‌کند یک شکست سیاستی است.