یک فایل .ovpn واقعاً چه چیزی دارد، و چه کاری نمی‌تواند بکند

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

فایل را فهرستی از درخواست‌های خطاب به کلاینت خود بخوانید و بیشتر خطوطش روشن می‌شوند.

فایل کلاینت شما را توصیف می‌کند، نه سرور را

یک پروفایل نقطه پایانی remote، یک انتقال، یک نوع رابط، مواد هویت و هر رفتار سمت کلاینت را که اپراتور بخواهد کنار هم می‌گذارد. هر خط در زمان راه‌اندازی توسط کلاینت اجرا می‌شود. هیچ‌کدام به‌عنوان تغییر پیکربندی به سرور نمی‌رسد و هیچ‌کدام نمی‌تواند شنونده‌ای بسازد که از قبل اجرا نمی‌شود. پروفایلی که TCP 443 را در برابر سروری نام می‌برد که فقط روی UDP 1194 گوش می‌دهد در نخستین بسته شکست می‌خورد.

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

خطوط انتقال باید با شنونده‌ای که از قبل وجود دارد بخواند

proto و remote باید با آنچه سرور واقعاً مقید می‌کند هم‌خوان باشند. UDP انتخاب معمول است چون داده‌گرام گم‌شده تونل را متوقف نمی‌کند، در حالی که TCP می‌تواند در شبکه‌های محدود به بهای مسدودشدن سر صف درون تونل دوام بیاورد. تغییر پروفایل از UDP به TCP باعث نمی‌شود سرور TCP را بپذیرد؛ فقط باعث می‌شود کلاینت به پورتی بفرستد که کسی آن را نمی‌خواند.

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

کلیدهای جاسازی‌شده نحوه برخورد شما با فایل را تغییر می‌دهند

گواهی‌ها و کلیدها می‌توانند به‌صورت درون‌خطی میان برچسب‌های <ca>، <cert> و <key> قرار بگیرند، یا به‌صورت فایل‌های جداگانه ارجاع داده شوند. مواد درون‌خطی پروفایل را خودبسنده می‌کند و آن را به یک راز هم تبدیل می‌کند، چون کلید خصوصی کلاینت درون آن سفر می‌کند. گواهی CA مواد اعتماد عمومی است و اشتراکش بی‌خطر است؛ کلید خصوصی چنین نیست، حتی وقتی مثل یک بلوک متن ناخوانا به نظر می‌رسد.

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

مسیرها و DNS ممکن است اصلاً از فایل نیایند

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

DNS همان الگو را دنبال می‌کند: یک dhcp-option DNS هل داده‌شده ممکن است توسط کلاینت اعمال شود، نادیده گرفته شود یا توسط مدیر حل‌کننده محلی بازنویسی شود. پس از اتصال وضعیت حل‌کننده را بررسی کنید نه اینکه پروفایل را دوباره بخوانید.

گزینه‌های پشتیبانی‌نشده مسئله نسخه کلاینت است

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

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

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