چرا nc -uz نمی‌تواند ثابت کند که یک سرور OpenVPN آماده است

اجرای nc -uz در برابر یک سرور OpenVPN تقریباً هیچ چیزی را اندازه نمی‌گیرد، و راهنمای OpenBSD این را در هشدارهای خود می‌گوید: اسکن‌های UDP در آن حالت چه چیزی گوش بدهد و چه ندهد، موفقیت گزارش می‌کنند. وضعیت خروج فرستادن محلی را نشان می‌دهد، نه وضعیت دور، بنابراین سرپرستی که به آن اعتماد می‌کند یک سرور مرده را تا زمانی که جدول فرایندها باورپذیر به نظر برسد سالم نگه می‌دارد. جایگزینی آن با تصمیم‌گیری درباره این شروع می‌شود که بررسی باید به کدام پرسش پاسخ دهد، چون فرایند، شنونده، احراز هویت و دسترس‌پذیری برنامه چهار مشاهده متفاوت‌اند. بررسی‌ای که یکی از آن‌ها را نام می‌برد مفید است؛ بررسی‌ای که به هر چهار مورد اشاره می‌کند یک بار اضافی است.

یک بررسی UDP چه چیزی را می‌تواند و چه چیزی را نمی‌تواند مشاهده کند

nc -uz یک داده‌نگار می‌فرستد و خارج می‌شود، و وضعیتی که برمی‌گرداند فرستادن محلی را توصیف می‌کند. یک درگاه بسته ممکن است با ICMP port unreachable پاسخ دهد، اما رفتار مستند این حالت اسکن آن را به شکست تبدیل نمی‌کند، و یک درگاه فیلترشده هیچ پاسخی نمی‌دهد. پس سکوت و موفقیت برای فراخواننده یک معنا دارند.

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

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

سه فراخواننده، سه پرسش متفاوت

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

این‌ها یک بررسی نیستند و یک بررسی نمی‌تواند هر سه را صادقانه پوشش دهد. نخست فراخواننده را انتخاب کنید، سپس شاهد را.

بررسی را از نمونه کنونی بسازید

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

آن را عمداً بشکنید و بررسی را تماشا کنید

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

بلوک را خط به خط بخوانید. فرمان netcat چاپ می‌کند exit=0 در حالی که هیچ چیز متصل نیست، و این تمام مشکل در یک خط است. نخستین ss چیزی چاپ نمی‌کند، راه‌اندازی مجدد موفق می‌شود، و دومی ss دوباره شنونده را نشان می‌دهد. اگر بررسی شما در برابر سرور متوقف‌شده بگذرد، پشته محلی را اندازه می‌گیرد و نه چیز دیگری.

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

خط وضعیت باید چه بگوید

ثبت کنید هر بررسی کدام مرز را پوشش می‌دهد: فرایند، شنونده، احراز هویت یا برنامه. یک بررسی به‌ندرت بیش از یکی را پوشش می‌دهد، و صفحه وضعیتی که آن‌ها را در “up” فشرده می‌کند تفاوتی را پنهان می‌کند که در هنگام رخداد اهمیت دارد. برای مسیر شبکه از کلاینتی واقعی با هویتی اختصاصی استفاده کنید، بگذارید دست‌دادن و یک عملیات بی‌خطر مجاز را کامل کند، سپس قطعش کنید. این کانال کنترل، سیاست احراز هویت و شنونده را در یک گام می‌آزماید.

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

مرز را در متن هشدار نام ببرید تا نخستین پاسخ‌دهنده بداند باید به واحد، سوکت، گواهی یا مسیر نگاه کند. بررسی‌ای که نمی‌تواند بگوید چه چیزی را ثابت کرده به دلیل اشتباهی مورد اعتماد قرار می‌گیرد، و بررسی netcat در وهله نخست همین‌گونه زنده ماند.