چگونه سرور یک پروفایل OpenVPN را پیش از درون‌ریزی بررسی کنیم

کسی پروفایلی برایتان می‌فرستد، آن را درون‌ریزی می‌کنید و سی ثانیه بعد کلاینتی به مقصدی شماره می‌گیرد که هیچ‌کس آن را بررسی نکرده است. نخست فایل را در ویرایشگر متن بخوانید، چون همه آنچه اهمیت دارد در چند دستور می‌گنجد: remote، proto، port، ca، cert، tls-crypt و verify-x509-name. باقی همه پیش‌فرض است و پیش‌فرض‌ها همان جایی هستند که شگفتی‌ها رخ می‌دهند.

همه نقطه‌های پایانی را که فایل می‌تواند به کار ببرد فهرست کنید

با نقطه‌های پایانی شروع کنید، چون یک پروفایل می‌تواند چند تا داشته باشد. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn هر نامزد را به ترتیب فایل چاپ می‌کند، از جمله آن‌هایی که درون بلوک‌های <connection> درون‌خطی جا گرفته‌اند.

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

به املای proto هم توجه کنید. tcp معادل tcp-client در سمت کلاینت پذیرفته می‌شود، اما tcp-server در پروفایل کلاینت خطای پیکربندی است که بیشتر به جای شکست تمیز، باعث معلق ماندن می‌شود.

نخست نام را تأیید کنید، سپس پورت را

dig +short vpn.example.com می‌گوید نام وجود دارد یا نه و کدام نشانی‌ها را برمی‌گرداند، و یک نقطه پایانی چند‌نشانی یا پشت پروکسی ممکن است به‌طور مشروع چند نشانی برگرداند. تجزیه نام پیش‌شرط است، نه مدرک مالکیت؛ هر کسی می‌تواند نامی را به نشانی‌ای اشاره دهد، و یک نشانی می‌تواند پاسخگوی نام‌های بسیاری باشد.

سپس شنونده را روی پورتی که یافتید بررسی کنید، هم‌راستا با لایه انتقال. روی TCP، openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com زنجیره‌ای را که سرور ارائه می‌دهد چاپ می‌کند. روی UDP به DTLS نیاز دارید: openssl s_client -dtls1_2 -connect vpn.example.com:1194 همان دست‌دادن را روی داده‌نگارها اجرا می‌کند. دست‌دادن کامل ثابت می‌کند چیزی گوش می‌دهد و گواهی دارد، که بیش از آن است که ping نشان می‌دهد و کمتر از آنکه تنظیمات اعتماد خود پروفایل می‌طلبد.

وقتی دست‌دادن شکست می‌خورد و میزبان به ping پاسخ می‌دهد، پورت احتمالاً اشتباه یا فیلتر شده است. آن را دلیلی برای درخواست پورت درست بدانید، نه دعوتی برای جارو کردن پورت‌های نزدیک. nc -vzu هم روی برخی پشته‌ها بدون آنکه چیزی گوش بدهد موفقیت گزارش می‌کند، پس کاوش ساده UDP بدون دست‌دادن پشت آن هیچ معنایی ندارد.

پین‌های اعتماد را جدا از نشانی بخوانید

نشانی تعیین می‌کند کلاینت کجا می‌رود؛ بلوک اعتماد تعیین می‌کند پس از رسیدن به چه کسی باور کند. verify-x509-name "vpn.example.com" name نام عمومی موضوع را پین می‌کند، و remote-cert-tls server کاربرد کلید گسترده برای احراز هویت سرور را الزامی می‌کند. پروفایلی که اپراتور به شما می‌دهد باید هر دو را داشته باشد.

ca، یک بلوک <ca> درون‌خطی، و یکی از tls-crypt یا tls-auth را بجویید. پروفایلی که tls-auth دارد در سمت کلاینت به key-direction 1 نیاز دارد وقتی سمت سرور جهت 0 را به کار می‌برد، و ناهمخوانی دست‌دادن را با خطای TLS که شبیه عیب گواهی خوانده می‌شود شکست می‌دهد. CA درون‌خطی که به اپراتوری که نامش را همین حالا تجزیه کردید تعلق ندارد یعنی فایل از دو منبع سرهم شده است، و همین همان حالتی است که باید یکسره رد شود.

verify-x509-name حالت‌های name، name-prefix یا subject را می‌پذیرد، و آخری نام کامل تمایزیافته را دقیقاً به همان ترتیبی می‌خواهد که سرور چاپش می‌کند. حالتی را برگزینید که با شکل مقدار بخواند، چون کلاینت هر اتصال را رد می‌کند به جای آنکه درباره نزدیک بودن هشدار دهد. برای فایلی که خودتان ننوشته‌اید، name با یک نام میزبان ساده کم‌شگفت‌ترین انتخاب است.

گزینه‌هایی را بررسی کنید که بی‌صدا شکست می‌خورند

OpenVPN 2.6 رمزها را از طریق data-ciphers مذاکره می‌کند، و پروفایلی که تنها خط قدیمی cipher AES-256-CBC را دارد می‌تواند کانال کنترل را کامل کند و سپس روی داده بایستد. خواندن آن مقدار می‌گوید فایل پیش از سروری است که به آن می‌پیوندید یا نه؛ و صفحه راهنمای نسخه 2.6 ترتیب مذاکره را فهرست می‌کند اگر لازم شد آن را به اپراتور نقل کنید.

auth-user-pass بدون نام فایل یعنی کلاینت پرسش می‌کند، پس پروفایلی که خودبسنده به نظر می‌رسد هنوز به اعتبارنامه نیاز دارد. auth-user-pass credentials.txt یعنی انتظار فایلی را دارد که احتمالاً برایتان فرستاده نشده. nobind و resolv-retry infinite عادی و بی‌ضررند، در حالی که explicit-exit-notify فقط مخصوص UDP است و روی TCP بی‌فایده.

هیچ یک از این‌ها تغییر نمی‌دهد که پروفایل کجا وصل می‌شود، اما هر یک تغییر می‌دهد که آیا اصلاً وصل می‌شود، و هیچ‌کدام در پنجره درون‌ریزی کلاینت دیده نمی‌شود.

تصمیم بگیرید، سپس آنچه تصمیم گرفتید را ثبت کنید

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

هشی را که بررسی کردید ثبت کنید تا نفر بعدی بتواند بفهمد فایل تغییر کرده یا نه: sha256sum profile.ovpn، کنار نقطه پایانی در یادداشت‌هایتان بچسبانید. پروفایل یک چیدمان کامل است، نه فهرستی از نشانی‌ها، پس هرگز یک remote کارکننده را در بلوک اعتماد کسی دیگر با نگه داشتن اعتبارنامه‌های او نبندید.

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

اگر درون‌ریزی کردید و نخستین تلاش شکست خورد، کلاینت را با --verb 3 اجرا کنید و ده خط اول را بخوانید: نشانی remote تجزیه‌شده، proto مذاکره‌شده و خطای TLS به همین ترتیب می‌آیند، که می‌گوید کدام یک از بررسی‌های بالا را جا انداخته‌اید.