کلاینت بومی SoftEther یا پروفایل OpenVPN: پورت درست را انتخاب کنید

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

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

دو شنونده، دو قالب پیکربندی

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

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

گام 1: پیدا کنید اپراتور کدام شنونده را فعال کرده است

فهرست شنونده‌ها را بخواهید، نه اینکه از روی شماره پورت حدس بزنید. سروری که روی 443 با TLS پاسخ می‌دهد لزوماً نقطه پایانی OpenVPN نیست، زیرا پروتکل بومی می‌تواند از همان پورت استفاده کند. بخش راهنما درباره توابع سازگار سرور توضیح می‌دهد کدام کلون‌ها وجود دارند و چگونه فعال می‌شوند.

اگر می‌توانید به میزبان برسید، پورتی را که به شما داده شده آزمایش کنید، نه پورت یک آموزش: openssl s_client -connect vpn.example.com:443 -brief دست‌کم به شما می‌گوید آیا TLS وجود دارد.

گام 2: از کلاینت و پروفایل متناظر استفاده کنید

برای دسترسی بومی، کلاینت SoftEther را نصب کنید، با جزئیات اپراتور یک اتصال بسازید و آداپتور مجازی را متصل کنید. برای شنونده سازگار، پروفایل OpenVPN را که اپراتور از سرور صادر کرده وارد کنید، زیرا مواد CA و کلاینت را که آن شنونده انتظار دارد همراه دارد. پروفایل را دستی از یک نمونه عمومی سرهم نکنید و تعریف اتصال بومی را در پیکربندی OpenVPN نچسبانید.

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

گام 3: مقایسه را صادقانه نگه دارید

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

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

گام 4: مسیر را پس از اتصال بررسی کنید

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

ثبت کنید کدام شنونده و کدام نسخه کلاینت نتیجه کارآمد را تولید کرده‌اند. در غیر این صورت نفر بعدی کشف را از شماره پورت به بالا تکرار می‌کرد.