چرا یک نمایهٔ OpenVPN در SoftEther وارد نمی‌شود

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

دو پرونده، دو قرارداد

نمایهٔ OpenVPN یک پیکربندی کارخواه است: یک نقطهٔ پایانی راه دور، یک حامل، مواد TLS و دستورهایی برای مسیریابی و مذاکرهٔ مجدد. اتصال SoftEther یک نشست کارخواه بومی در برابر یک هاب مجازی است، با یک آداپتور مجازی که به آن متصل شده است.

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

پسوند پرونده تقریباً هیچ چیزی به شما نمی‌گوید، به همین دلیل پاسخ اپراتور از نام پرونده مهم‌تر است.

پیش از دست زدن به بلوک گواهی، سرور را بخوانید

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

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

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

درگاه UDP که در فهرست شنونده‌ها نیست نشانهٔ ویژگی غیرفعال است، نه مشکل دیوار آتش.

آنچه کارخواه بومی نیاز دارد و نمایه نمی‌تواند به آن بدهد

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

احراز هویت بومی در برابر یک هاب مجازی اجرا می‌شود، با یک شیء کاربر که مدیر هاب ساخته است. بلوک‌های گواهی که از نمایهٔ OpenVPN کپی شده‌اند به کاربران هاب تبدیل نمی‌شوند، و کاربر هاب به گواهی کارخواه تبدیل نمی‌شود. دو سامانه چیزهای متفاوتی ذخیره می‌کنند و نمایه جایی برای گذاشتن رکورد کاربر هاب ندارد. این یک تفاوت ساختاری است نه مشکل نحوی.

کلید خصوصی را از هر سرویس تبدیل دور نگه دارید، زیرا کلیدی که دستگاه را ترک می‌کند باید افشاشده تلقی شود.

شنوندهٔ سازگار با OpenVPN چه چیزی را می‌پذیرد

شنوندهٔ سازگاری از دید کارخواه یک سرور واقعی OpenVPN است: کارخواه OpenVPN و دستورهایی را که آن کارخواه پشتیبانی می‌کند انتظار دارد. بلوک‌های گواهی درون‌خطی ویژگی OpenVPN هستند و به آن سمت حصار تعلق دارند.

کاری که انجام نخواهد داد پذیرفتن نمایهٔ بومی SoftEther است، زیرا آن نمایه پیکربندی OpenVPN نیست. شنونده همچنین کارخواه بومی را به کارخواه OpenVPN تبدیل نمی‌کند. اگر اپراتور فقط سرویس بومی را ارائه دهد، پاسخ کارخواه بومی است؛ اگر شنوندهٔ سازگاری را ارائه دهد، پاسخ OpenVPN و مواد خودش است.

برون‌بر پشتیبانی‌شدهٔ اپراتور را بخواهید به جای اینکه یکی را از قطعه‌ها سرهم کنید، زیرا برون‌بر جزئیاتی را حمل می‌کند که پروندهٔ دست‌ساز معمولاً از دست می‌دهد.

پیش از ویرایش دستورها، مسیر را اثبات کنید

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

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

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