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

اسکریپتی که OpenVPN را راه می‌اندازد و هرگز وصل نمی‌شود معمولاً مشکل شبکه نیست: کلاینت جلوی یک اعلان نشسته و ترمینالی ندارد که آن را روی آن رسم کند. OpenVPN دقیقاً دو روش پشتیبانی‌شده برای پاسخ به آن اعلان بدون انسان دارد، یک فایل اعتبارنامه پشت auth-user-pass و سوکت مدیریت، و این دو قابل جایگزینی نیستند. فایل یک دستورالعمل هزینه دارد و به یک اعلان پاسخ می‌دهد؛ سوکت به همه اعلان‌ها پاسخ می‌دهد و به هر چیزی که بتواند درگاهی روی loopback باز کند یک کانال کنترل بدون احراز هویت می‌دهد. اینکه کدام به استقرار شما تعلق دارد به این بستگی دارد که کدام اعلان واقعاً مسدود شده و کدام راز را می‌توانید از عهده‌اش برآیید که ساکن بماند.

پیش از انتخاب مکانیزم، اعلان را نام‌گذاری کنید

چهار اعلان روی ترمینال یکسان به نظر می‌رسند. جفت حساب از پیکربندی PAM یا auth-user-pass-verify سرور می‌آید و auth-user-pass به آن پاسخ می‌دهد. عبارت عبور کلید خصوصی به فایل کلید تعلق دارد و از طریق --askpass خوانده یا دستی تایپ می‌شود. بسته PKCS#12 گذرواژه خودش را می‌خواهد. احراز هویت پراکسی از فایل auth که --http-proxy می‌گیرد استفاده می‌کند، نه اعتبارنامه حساب.

وقتی OpenVPN به‌عنوان فرزند systemd، PHP یا Node اجرا می‌شود ترمینالی وجود ندارد، پس هر یک از این‌ها بی‌صدا مسدود می‌شود. فرایند همان‌جا می‌ماند، گزارش پس از خط رمزنگاری متوقف می‌شود و واحد در نهایت به مهلت می‌رسد؛ همان سکوت دلیل آن است که افراد به‌جای نگاه کردن به اینکه کدام اعلان منتظر است، یک حلقه تلاش دوباره یا sleep اضافه می‌کنند. تنها سوکت مدیریت می‌تواند به هر چهار پاسخ دهد. فایل اعتبارنامه به اولی پاسخ می‌دهد و به هیچ چیز دیگری.

auth-user-pass: یک فایل، یک اعلان

فایل نام کاربری را در خط یک و گذرواژه را در خط دو نگه می‌دارد، و چیز دیگری نه: بدون گیومه، بدون نام کلید، بدون توضیح. حالت 600 را تنظیم کنید و مالک را حسابی کنید که openvpn را اجرا می‌کند، که برای یک سرویس اغلب کاربر اختصاصی است و نه ورود شما. فایلی متعلق به root زیر /root تفاوت میان دستوری است که در پوسته شما کار می‌کند و واحدی که هنگام بوت شکست می‌خورد.

دو جزئیات یک فایل درست را به اعلان تبدیل می‌کند. ویرایشگری که CRLF ذخیره می‌کند یک بازگشت کالسکه چسبیده به گذرواژه باقی می‌گذارد، پس سرور گذرواژه‌ای را رد می‌کند که در فایل درست به نظر می‌رسد؛ با cat -A یا od -c بررسی کنید نه با چشم. و auth-user-pass بدون آرگومان درون پروفایل به‌طور طراحی یعنی «از کاربر بپرس»، که دستورالعمل دومی در خط فرمان ممکن است آن را لغو نکند، چون پروفایل همان‌جا که هست تجزیه می‌شود.

ترتیب گزینه‌ها سومین تله است و به نسخه بستگی دارد. برخی ساخت‌های OpenVPN 2.4 وقتی --auth-user-pass پیش از --config می‌آید آن را نادیده می‌گیرند، پس همان دو گزینه در ترتیب دیگر وصل می‌شوند. دستورالعمل را درون پروفایل یا پس از --config در خط فرمان بگذارید و پیش از تغییر هر چیز دیگری هر رخداد را در پروفایل grep کنید.

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

سوکت مدیریت: هر اعلان، سطح بیشتر

کلاینت را با یک شنونده راه بیندازید و صریحاً اعلام کنید که اعلان‌ها روی آن گزارش می‌شوند، با دستورالعمل‌هایی که در راهنمای OpenVPN 2.6 مستند شده‌اند:

management 127.0.0.1 3030
management-query-passwords

از bash اتصال را روی یک توصیفگر فایل یدکی نگه دارید و بر اساس نام اعلان پاسخ دهید نه موقعیت، چون اتصال دوباره ممکن است با ترتیب دیگری بپرسد:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

مرز، انتقال است. پروتکل مدیریت متن ساده روی TCP روی loopback است، پس شنونده نباید روی نشانی LAN یا تونل منتشر شود تا کنترلر راه دور به آن برسد؛ کنترلر راه دور یعنی انتقال SSH، نه bind گسترده‌تر. دیمن انجمن نیز هر بار یک کلاینت مدیریت می‌پذیرد، پس یک GUI یا مانیتور نمی‌تواند سوکت را با اسکریپت شما شریک شود. اتصال دوم رد می‌شود نه در صف می‌نشیند، و خرابی مانند اسکریپتی به نظر می‌رسد که کر شده است.

آن سوکت یک کانال کنترل هم هست. بدون گذرواژه مدیریت، هر چیزی که بتواند به 127.0.0.1:3030 وصل شود می‌تواند وضعیت را بخواند، تونل را بکشد یا خودش به یک اعلان پاسخ دهد. گذرواژه مدیریت و فایل اعتبارنامه از یک طبقه راز هستند و هر دو همان دقت را می‌طلبند.

کدام با استقرار سازگار است

فایل اعتبارنامه را انتخاب کنید وقتی تنها اعلان جفت حساب است، کلاینت به‌عنوان سرویس با مالک پایدار اجرا می‌شود و می‌توانید فایل 600 را بیرون از نسخه‌های پشتیبانی که کنترل نمی‌کنید نگه دارید. سوکت مدیریت را انتخاب کنید وقتی عبارت عبور کلید یا گذرواژه PKCS#12 در میان است، وقتی پوشش‌دهنده از قبل بر فرایند نظارت می‌کند، یا وقتی هنگام اشکال‌زدایی اتصال دوباره باید وضعیت و اعلان‌ها را ببینید.

دو شرط تصمیم را جابه‌جا می‌کند. اگر پوشش‌دهنده /bin/sh است، یک واحد systemd که باینری را مستقیم صدا می‌زند، یا یک کانتینر حداقلی، چسب سوکت فقط برای bash در دسترس نیست و فایل پاسخ ارزان‌تر است. اگر راز اغلب می‌چرخد، هیچ‌کدام از فایل‌ها خانه خوبی برای آن نیست: از یک پوشش‌دهنده کوچک یک جاکلیدی بپرسید و بگذارید واحد آن پوشش‌دهنده را صدا بزند، که چرخش را در یک جا نگه می‌دارد و گذرواژه را بیرون از تاریخچه پوسته.

جانشینی فرایند میان آن دو می‌ایستد و به هیچ‌کدام تعلق ندارد. تک‌خطی زیر کار می‌کند چون bash آن را پیش از شروع openvpn باز می‌کند، نه چون کلاینت نحو را می‌فهمد:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

زیر /bin/sh می‌شکند، در واحدی که پوسته را دور می‌زند، و در تصاویری بدون bash یا /dev/fd. آن را برای آزمون تعاملی نگه دارید، هرگز به‌عنوان قراردادی که سرویس به آن وابسته است.

راز را محافظت کنید، سپس از گزارش راستی‌آزمایی کنید

هر دو مکانیزم رازی را برای فرایند OpenVPN خواندنی می‌گذارند. هرگز گذرواژه را روی خط فرمان یا در فایل واحد نگذارید، جایی که ps و systemctl آن را به هر کاربر محلی نشان می‌دهند؛ مسیر فایل را بدهید، نه مقدار درون آن را. جایی که گواهی‌ها می‌توانند جای جفت حساب را بگیرند، آن دسته اعلان را حذف می‌کند نه اینکه پنهانش کند.

اجرای درست نشان می‌دهد توالی اعلان‌ها کامل می‌شود و نشست به «Initialization Sequence Completed» می‌رسد. اگر کلاینت در همان اعلان متوقف شود، تطبیق شکست خورده است: خطوط دقیقی را که سوکت فرستاده چاپ کنید، گیومه و نام اعلان را بررسی کنید و الگو را درست کنید نه اینکه sleep اضافه کنید. تونلی که موفقیت گزارش می‌کند و چیزی حمل نمی‌کند مشکل مسیریابی یا push است، نه اعتبارنامه.

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