توقف یک کلاینت OpenVPN: چرا ابطال اهرم اشتباه است
کشتن نشست برگشتپذیر است؛ ابطال گواهی نیست. تصمیم بگیرید پرونده کدام اهرم را میخواهد و CRL را فقط وقتی جور است دوباره بسازید.
متوقف کردن دسترسی یک کلاینت و حذف همیشگی آن تا وقتی یکی از این دو را برنگردانید یک کار به نظر میرسند. ابطال گواهی رکوردی مینویسد که سرور آن را نهایی میداند، و برگرداندنش یعنی ویرایش دستی پایگاه داده صادرکننده. انداختن تونل زنده فرمانی مدیریتی است که چیزی در اعتماد تغییر نمیدهد. اهرم را با این پرسش انتخاب کنید که آیا کلید هنوز قابل اعتماد است، نه با این پرسش که درخواست چقدر فوری به نظر میرسد.
باور: ابطالشده و معلق یک چیزند
پیمانکاری یک هفته معلق میشود و واکنش اولیه ابطال است، چون ابطال شبیه خاموش کردن چیزی به گوش میرسد. مرتب به نظر میرسد، ده ثانیه طول میکشد، و ویرایش پایگاه داده را تنها راه بازگشت باقی میگذارد. این واکنش فهمیدنی است و به سوزاندن گذرنامه نزدیکتر است تا بستن در. دستگاه معلق و کلید بهخطرافتاده درمان متفاوتی میخواهند، و فقط یکی از آن دو ارزان برگشتپذیر است.
تفاوت در اعتبارنامه است نه در شخص. کلیدی که هنوز در دست درست است را میتوان بدون هیچ کاهش اعتماد معلق و دوباره فعال کرد. کلیدی که ممکن است کپی شده باشد را هرگز نباید بازگرداند، چون بازگرداندن ادعا میکند که کپی وجود ندارد.
پاسخ را قبل از دست زدن به هر یک از دو سامانه بنویسید. اگر نمیتوانید بگویید کلید افشا شده است یا نه، پاسخ محافظهکارانه جایگزینی است.
نشست زنده را با رابط مدیریت بیندازید
OpenVPN رابطی مدیریتی عرضه میکند که میتواند نشستها را فهرست کند و یکی را با نام مشترک بکشد. آن را روی localhost فعال کنید، از رابط عمومی دور نگه دارید، و وقتی نشستی باید همین حالا ناپدید شود فرمان کشتن را بفرستید. فرمان فقط همان تونل را میبندد و هر کلاینت دیگر به کار خود ادامه میدهد.
این پاسخ به یک مشکل فعال است، نه سیاست تعلیق. همان پروفایل میتواند در یک دقیقه دوباره وصل شود، چون چیزی در اعتبارنامهاش عوض نشده است. وقتی نشست باید برود و تصمیم ماندگار هنوز گرفته میشود از آن استفاده کنید.
قبل از کشتن، مطمئن شوید نشست متصل بوده، تا دنبال کلاینتی نگردید که هرگز وصل نشد. فرمان وضعیت در پایین چاپ میکند که در این لحظه چه چیزی متصل است.
printf 'status 2\nquit\n' | nc 127.0.0.1 7506
printf 'kill kiosk-14\nquit\n' | nc 127.0.0.1 7506اگر کشتن گزارش داد که چنین کلاینتی وجود ندارد، نام مشترک در گواهی همان رشتهای نیست که تایپ کردید. خروجی وضعیت را بخوانید نه نام فایل پروفایل را.
CRL در واقع چه چیزی را کنترل میکند
سرور به پرچم ابطالی که روی گواهی ذخیره شده مراجعه نمیکند. او فهرست ابطال گواهیها را که در crl-verify نام برده شده، در هر اتصال تازه میخواند و گواهیای را که شماره سریالش در آن فهرست است رد میکند. دو پیامد از این میآید و هر دو در عمل مهماند. فایل باید برای حسابی که سرور امتیازات را به آن واگذار میکند خواندنی باشد، و کلاینتی که از قبل متصل است تا وقتی دوباره وصل نشود به کار ادامه میدهد.
پیامد دوم آدمها را هنگام رخداد غافلگیر میکند. ابطال گواهی تونلی را که همین حالا از آن استفاده میکند نمیبندد. اگر نشست باید فورا تمام شود، ابطال را با یک کشتن مدیریتی جفت کنید، و دو کار را دو گام جدا در دفترچه بدانید.
فهرست را بررسی کنید تا ببینید سرور واقعا چه چیزی را اعمال میکند، نه اینکه به مهر زمانی آخرین فایلی که کپی کردید اعتماد کنید. بخش مهم شمارش سریال است.
openssl crl -in /etc/openvpn/server/crl.pem -noout -text | sed -n '1,14p'
ls -l /etc/openvpn/server/crl.pemفهرست بدون ورودی و فهرست با ورودیهای درست در فهرست یک پوشه یکسان به نظر میرسند، پس ارزش دارد شمارش سریال چاپ شود. خط اجازهها هم به همان اندازه مهم است، چون فایلی که دیمن نمیتواند بخواند شکستی میسازد که شبیه کلاینت ردشده است.
بازگرداندن یک رکورد، با احتیاط
بازگرداندن گواهی یعنی وارونه کردن یک رکورد در پایگاه داده صدور و انتشار فهرست تازه. easy-rsa 3 آن پایگاه داده را بهصورت index.txt در پوشه PKI نگه میدارد، در حالی که چیدمانهای قدیمیتر ترتیب دیگری داشتند. یک ردیف با یک حرف وضعیت و یک تاریخ انقضا شروع میشود. ردیف ابطالشده یک مهر زمانی برای ابطال درج میکند پیش از آنکه با شماره سریال، نام فایل گواهی و نام تمایزی ادامه دهد. برگرداندن ردیف یعنی پاک کردن آن مهر زمانی و وارونه کردن حرف، و دست نگذاشتن به بقیه چیزها.
اول از فایل نسخه پشتیبان بگیرید و ویرایش را به شکل اسکریپت بنویسید، نه با تایپ در ویرایشگر متن. غلط تایپیای که تعداد فیلدهای یک ردیف را عوض کند صدور را برای هر گواهی که بعدا اضافه شود خراب میکند. دلیل خودکار کردن تغییر و کپی کردن فایل قبل از دست زدن همین است.
ابطال دوم با همان نام هم اغلب شکست میخورد، چون اجرای اول آن گواهی و کلیدش را از پوشههایی که ابزار انتظار دارد بیرون برده است. آنگاه ابزار نمیتواند چیزی را که خواسته شده ابطال کند پیدا کند، و پیام خطا همیشه روشن نمیگوید چرا.
cp /etc/easy-rsa/pki/index.txt /root/index.txt.$(date +%F-%H%M)
grep -c '^R' /etc/easy-rsa/pki/index.txt
easyrsa gen-crlفهرست تازه را منتشر کنید، مالکیتش را درست کنید و کاری کنید سرور آن را بخواند. در بیشتر نصبها بازخوانی کافی است، اما تایید باید از یک اتصال تازه بیاید، چون نشست موجود هرگز چیزی را دوباره بررسی نکرد.
بررسی کنید پرونده کدام اهرم را سزاوار است
پرسشی را بپرسید که کل دفترچه را تعیین میکند: آیا کلید خصوصی هنوز فقط جایی است که باید باشد. اگر هست، کشتن نشست بههمراه یک توقف مستند پرونده را پوشش میدهد و هیچ رکورد دائمی جا نمیگذارد. اگر نیست، تنها پاسخ ایمن یک کلید تازه است و گواهی قدیمی ابطالشده میماند.
بعد نتیجه را با یک تلاش اتصال بررسی کنید نه با تفاوت پیکربندی. تفاوت میگوید چه قصدی داشتید و اتصال میگوید سرور چه چیزی را اعمال میکند.
openssl crl -in /etc/openvpn/server/crl.pem -noout -text | grep -c 'Serial Number'
printf 'status 2\nquit\n' | nc 127.0.0.1 7506وقتی کلاینت بازگرداندهشده وصل میشود و در خروجی وضعیت ظاهر میشود، ویرایش رکورد کار کرده است. وقتی کلاینت ابطالشده رد میشود و گزارش نام CRL را میآورد، ابطال کار کرده است. هر چیزی بین این دو مشکل اجازه یا بازخوانی است، و ارزش دارد پیش از رسیدن درخواست بعدی درست شود.