OpenVPN push-peer-info: برچسب‌گذاری کلاینت‌ها بدون اعطای دسترسی

برچسب‌های استقرار دلیل معمول روی آوردن افراد به این قابلیت هستند: هر اتصال باید چیزی مانند یک سایت یا یک نقش حمل کند و سرور باید آن را بدون ابداع قالب دوم اعتبارنامه بخواند. OpenVPN جامعه همین مکانیزم را دارد و کوچک است. بخش آزاردهنده انتظارات است. تعیین یک متغیر معمولی در پروفایل کلاینت هیچ کاری روی سرور نمی‌کند و مقداری که واقعاً می‌رسد فقط این را ثابت می‌کند که کلاینت آن را فرستاده است.

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

متغیر را تعیین کنید و مسیر را فعال کنید

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

setenv UV_DEPLOY field-support
push-peer-info

پیشوند UV_ تزئینی نیست. متغیر ساده DEPLOY محلی در فرایند کلاینت می‌ماند و هرگز ارسال نمی‌شود، در حالی که شکل پیشوندی همان فضای نامی است که پروتکل برای فیلدهای تعریف‌شده توسط کاربر رزرو می‌کند. بقیه پروفایل تأییدشده را دست‌نخورده نگه دارید و پیش از استقرار مطمئن شوید بیلد کلاینتی که مستقر می‌کنید هر دو دستور را پشتیبانی می‌کند.

یک بررسی عملی جای‌اش اینجاست نه در پایان: مطمئن شوید دستور به باینری کلاینت می‌رسد و لایه پوششی آن را نمی‌بلعد. یک کلاینت گرافیکی که خط فرمان خودش را تولید می‌کند، یا یک رابط مدیریتی که پروفایل ذخیره‌شده را دوباره بارگذاری می‌کند، ممکن است خطوطی را که نمی‌شناسد دور بیندازد. اگر سرور چیزی نمی‌بیند، این اولین جایی است که باید نگاه کرد.

فیلد را از یک قلاب سرور بخوانید

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

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

متغیر را از طریق محیط بخوانید نه با تجزیه گزارش، و همیشه به آن یک مقدار پیش‌فرض بدهید. ${UV_DEPLOY:-unset} اسکریپت را برای کلاینت‌هایی که هرگز فیلد را نمی‌فرستند کارآمد نگه می‌دارد، که در استقرار مرحله‌ای حالت عادی است. برای پیدا کردن نام، کل محیط را در گزارش نریزید؛ بسیار بیشتر از برچسب دارد، از جمله مقادیری که قصد نداشتید نگه دارید.

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

بررسی کنید واقعاً چه رسیده است

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

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

برچسب را ادعا بدانید، نه هویت

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

تمیز بازگردانید

حذف این قابلیت دو حذف و یک بررسی است. خطوط setenv و push-peer-info را از پروفایل کلاینت بردارید، سپس قلاب و هدف گزارش آن را روی سرور حذف یا غیرفعال کنید.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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