اسکن خام Nmap از طریق VPN شکست می‌خورد اما اتصال -sT کار می‌کند؟

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

قابلیت را از تونل جدا کنید

یک برنامه معمولی از هسته می‌خواهد یک اتصال TCP باز کند و هسته دست‌دادن را بدون اختیار ویژه انجام می‌دهد. اسکن خام خودش بسته‌ها را می‌سازد و این بسته به سکو به سوکت خام یا درایور ضبط نیاز دارد. این‌ها پرسش‌های مجوز و درایور هستند و چه VPN وصل باشد چه نه وجود دارند.

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

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

بررسی اتصال را روی یک میزبان تأییدشده اجرا کنید

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

یک خط، یک میزبان، یک پورت، بدون مرحله کشف:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT اتصال کامل TCP را انتخاب می‌کند، پس همان مسیر هسته را که یک برنامه استفاده می‌کند می‌آزماید و به درایور ضبط نیاز ندارد. -Pn کشف میزبان را رد می‌کند؛ nmap با این حال برای هدف‌های بخش محلی تفکیک لایه پیوند را انجام می‌دهد، پس این پرچم وعده ترافیک مقدماتی صفر نیست. --unprivileged به nmap می‌گوید فرض کند حق بسته خام یا شنود ندارد، که روش را تغییر می‌دهد و چیزی نمی‌دهد.

هر پرچم را یک تغییر بخوانید، نه یک تعمیر

هر گزینه را بیانیه‌ای درباره روش بدانید. هیچ‌یک از -sT، -Pn یا --unprivileged مسیر اضافه نمی‌کند، دیوار آتش دوردست را باز نمی‌کند یا گواهی را اعتبارسنجی نمی‌کند. اسکن اتصال یک دست‌دادن واقعی را هم کامل می‌کند که سرویس ثبت می‌کند، پس بررسی تأییدشده و پیمایش تأییدنشده از دید سرور یکسان به نظر می‌رسند مگر از نظر دامنه و آهنگ. انباشتن گزینه‌ها تا تغییر خروجی همان راهی است که مشکل روش به‌عنوان یافته شبکه ثبت می‌شود.

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

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

روی نتیجه انتقال بایستید، سپس سرویس را بیازمایید

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

آن را با کلاینت خود سرویس ادامه دهید تا هویت TLS و رفتار برنامه به‌عنوان واقعیت‌های جداگانه مشاهده شوند:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

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

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