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

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

هدف اینجا کلاینت خط فرمان OpenVPN 2.6 برای Linux است، با مسیریابی TUN روی UDP و احراز هویت گواهی.

فقط فایل‌های سمت کلاینت را جمع کنید

در یک دایرکتوری محافظت‌شده کار کنید و مواد اعتماد CA تأییدشده، گواهی کلاینت صادرشده و کلید خصوصی متناظر آن را جمع کنید. در این مثال نام‌ها ca.crt، laptop-a.crt و laptop-a.key هستند. نام فایل‌ها فقط برچسب‌اند؛ چیزی درباره محتوای هر فایل نمی‌گویند.

اگر کلید را هنگام ثبت ساخته‌اید، هرگز از دستگاه خارج نشده است؛ از صادرکننده فقط گواهی امضاشده و زنجیره عمومی باید برگردد. بررسی کنید که گواهی نقش کلاینتی را که سرویس انتظار دارد داشته باشد. همچنین بررسی کنید که کلید به همان گواهی تعلق دارد نه به گواهی قدیمی‌تر از تلاش قبلی. جفت ناسازگار خیلی دیرتر خطای TLS می‌دهد که شبیه مشکل سرور به نظر می‌رسد.

کلید امضای خصوصی CA، کلید خصوصی سرور و پارامترهای DH را بیرون از این بسته بگذارید.

فایل‌ها را در یک پروفایل کوچک به هم وصل کنید

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

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

خط remote نقطه پایانی شبکه را انتخاب می‌کند. remote-cert-tls server اصرار دارد که همتا گواهی با نقش سرور ارائه دهد. verify-x509-name نام مورد انتظار را سنجاق می‌کند، اینجا vpn-gateway به‌عنوان Common Name گواهی سرور با فیلد نام پیش‌فرض OpenVPN. این مقدار از نام میزبان DNS استنتاج نمی‌شود، پس از هر طرح هویتی که اپراتور داده استفاده کنید.

این بررسی‌ها را فقط به این دلیل که یک نقطه پایانی آزمایشی گواهی متفاوتی نشان می‌دهد کنار نگذارید.

این پروفایل پایه فرض می‌کند چالش حساب جداگانه و کلید کانال کنترل وجود ندارد. اگر سرویس به auth-user-pass، tls-auth یا tls-crypt نیاز دارد، پیکربندی و موادی را که گرفته‌اید نگه دارید، زیرا رمز کانال کنترلی که خودتان تولید کنید با آنچه سرور نگه می‌دارد مطابقت نخواهد داشت. سیاست رمزنگاری سرویس را هم نگه دارید، به‌جای واردکردن خطوط فشرده‌سازی یا رمز از یک نمونه قدیمی.

دایرکتوری کار را صریح کنید

مسیرهای نسبی از دایرکتوری کار فرایند پیروی می‌کنند، نه از محل فایل .ovpn.

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

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

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

کلید را فقط برای کاربر یا هویت سرویس موردنظر قابل خواندن نگه دارید.

تحویل را بررسی کنید، نه نام فایل‌ها را

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

اگر درخواست عبارت عبور ظاهر شد، متعلق به کلید خصوصی است، نه به حساب VPN.

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