چرا نتایج اسکن پورت پشت یک خروجی VPN تغییر می‌کند؟
خروجی را عوض کنید و یک پورت می‌تواند بدون اینکه سرویس جابه‌جا شود متفاوت پاسخ دهد. مشاهدهٔ مسیر را از فهرستی که واقعاً لازم دارید جدا کنید.
همان بررسی پورت را از یک خط دفتری و از یک خروجی VPN اجرا کنید، و دو پاسخ می‌توانند درباره نشانی که کسی آن را تغییر نداده اختلاف داشته باشند. این شکاف از مسیر و از میزبان پاسخ‌دهنده می‌آید، نه از فعال یا خاموش بودن سرویس. سه پرسش این توضیح‌ها را از هم جدا می‌کند: کاوشگر واقعاً چه پرسید، کدام میزبان پاسخ داد، و سرور خودتان چه ثبت کرد. آن‌ها را به همین ترتیب پیش ببرید و هر پاسخ را پیش از رفتن به بعدی بنویسید.
پیش از مقایسه دو اجرا، کاوشگر را درست کنید
یک واژهٔ وضعیت تنها زمانی با واژهٔ وضعیت دیگر قابل مقایسه است که هر دو از یک آزمایش بیرون آمده باشند. پنج میدان آن را تثبیت می‌کند: نشانی مبدأیی که سمت دور دیده، مقصد حل‌شده، پورت، نوع اسکن و زمان. هر یک را تغییر دهید و آزمایش دومی انجام داده‌اید نه اینکه اولی را دو بار اندازه گرفته باشید.
مبدأ را پیش از هر چیز بررسی کنید، چون ممکن است کارخواه VPN بالا باشد و ترافیک هنوز از واسط فیزیکی خارج شود. از سمت دور بپرسید چه می‌بیند، سپس از هسته بپرسید کدام واسط را انتخاب کرده:
curl -s https://ifconfig.me
ip route get 203.0.113.20دو نشانی در دو شبکهٔ متفاوت یعنی توضیح از همین حالا در دست است و بقیهٔ این بررسی‌ها فقط آن را تأیید می‌کنند. وقتی هم‌خوانی دارند، کاوشگر را با پرچم علت روشن ثبت کنید تا وضعیت به توضیحی پیوسته برگردد نه اینکه تنها به‌صورت واژه‌ای لخت بماند. نوع اسکن هم به همان ثبت تعلق دارد، چون توصیف می‌کند چه خواسته شد نه چه بازگشت. وضعیت بدون مبدأ، بدون روش و بدون مهر زمان را با هیچ چیز نمی‌توان مقایسه کرد:
nmap -sT -p 443,8443 --reason 203.0.113.20آن خروجی را کنار ثبت نگه دارید نه در بافر پیمایشی که نفر بعدی نمی‌بیند. دو اسکن صادق که اختلاف دارند تنها وقتی بحث‌اند که کسی شرط‌ها را ننوشته باشد. با شرط‌های تثبیت‌شده، یا نتایج هم‌خوانی دارند و پرسش بسته می‌شود، یا متفاوت‌اند و تفاوت واقعیتی درباره مسیر است.
بفهمید کدام میزبان دست‌دادن را تمام کرد
دست‌دادن کامل‌شده ثابت می‌کند که میزبانی آن را کامل کرده، و آن میزبان لزوماً همان فرایندی نیست که در ذهن دارید. یک متعادل‌ساز بار، یک پراکسی معکوس یا یک پراکسی SYN می‌توانند پیش از دخالت سرور واقعی پاسخ دهند، که طراحی معمولی است نه نشانه. گواهی معتبر برای نام مورد انتظار هم این را باریک نمی‌کند، چون گواهی رابطهٔ سرویس را توصیف می‌کند و چیزی درباره اینکه کدام ماشین اتصال را پایان داد نمی‌گوید.
مرجع وضعیت پورت Nmap این را پایه‌ای می‌داند: وضعیت ثبت می‌کند کاوشگر از محل ارسال چه چیزی را می‌توانست ببیند، نه ویژگی پورت را. واژهٔ وضعیت را این‌گونه بخوانید و دو اجرای مختلف هم‌خوان به نظر می‌رسند نه متناقض، در حالی که پرسش از باز بودن پورت به اینکه چه کسی جلوی آن ایستاده بود منتقل می‌شود.
به پرسش دوم در بک‌اند پاسخ دهید نه از بیرون. فرانت‌اندی که اتصال‌ها را می‌پذیرد و سپس به بالادست خود نمی‌رسد دقیقاً تصویر بیرونی یک سرویس سالم با برنامه‌ای کند را می‌سازد. تنها ثبت خود بالادست دو حالت را از هم جدا می‌کند:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'خط گزارش نشانی کارخواهی را نشان می‌دهد که برنامه واقعاً دید، و فرمان دوم نشان می‌دهد که آیا فرایندی که پورت 443 را در اختیار دارد برنامهٔ شماست یا چیزی جلوی آن. اگر آن دو درباره اینکه کدام نشانی متصل شد اختلاف داشته باشند، شما دو پای یک درخواست را می‌بینید و تیکت باید همین را بگوید.
پیش از سرزنش تونل، قواعد خودتان را بررسی کنید
سیاست عمدی شایع‌ترین دلیل پاسخ دادن یک پورت در یک شبکه و پاسخ ندادن در شبکه‌ای دیگر است، و کم‌جالب‌ترین توضیح در دسترس است. قواعد دسترسی برای اجازه دادن به یک مبدأ و دور انداختن بقیه وجود دارند، پس تغییر خروجی دقیقاً همان رویدادی است که برایش نوشته شده‌اند. بنابراین وضعیت متفاوت از طریق VPN نشان نمی‌دهد که ارائه‌دهنده ترافیک را بازرسی می‌کند. نشان می‌دهد که نشانی مبدأ شما اکنون متفاوت است، که ادعای بسیار کوچک‌تری است.
این قواعد روی سرور خواندنی‌اند، پس آن‌ها را بخوانید نه اینکه درباره میانهٔ شبکه گمانه بزنید. قواعد فیلتری را که هر یک از دو بازهٔ نشانی را ذکر می‌کنند فهرست کنید، سپس بررسی کنید که آیا اتصال اصلاً به دیمن رسیده است:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113نتیجهٔ دوم خالی آموزنده است، چون چیزی به دیمن نرسیده و پرسش به یک فیلتر، یک گروه امنیتی یا خود مسیر تعلق دارد. برخورد یعنی سرویس مبدأ شما را دیده و پاسخش را انتخاب کرده، و آن تصمیم معمولاً در قاعده‌ای نوشته شده که می‌توانید بخوانید. هیچ‌یک از دو نتیجه داستانی درباره ارائه‌دهنده را پشتیبانی نمی‌کند و بررسی هر دو از ضبط بسته ارزان‌تر است.
حمل‌ونقل، گواهی و پاسخ را جداگانه بخوانید
سه لایه سه مشاهده تولید می‌کنند، و کاوشگری که یکی از آن‌ها را می‌آزماید نمی‌تواند درباره دو تای دیگر گزارش دهد. آن‌ها را به‌صورت خطوط جداگانه در ثبت نگه دارید نه اینکه در یک حکم واحد تاشو کنید، چون هر خط به شیوهٔ خودش شکست می‌خورد و شیوهٔ شکست می‌گوید بعداً کجا را ببینید.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
یک فرمان سه ردیف اول را در برابر سرویسی که کنترل می‌کنید تولید می‌کند. خروجی آن را در ثبت کنار اسکن بگذارید نه در پیام گفت‌وگو:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/خروجی را به ترتیب بخوانید: دست‌دادن به پرسش حمل‌ونقل پاسخ می‌دهد، موضوع گواهی به پرسش نام و بدنهٔ پاسخ به پرسش برنامه. وقتی خط دست‌دادن موفق می‌شود و خط پاسخ نه، شما یک فرانت‌اند با بالادست شکسته دارید نه یک پورت مسدود. آن تیکتی متفاوت از تیکتی است که باز کردید و ارزش گفتن آشکار را دارد.
با نوشتن چهار واقعیت در تیکت تمام کنید: نشانی مبدأ، نوع اسکن، میزبانی که پاسخ داد و زمان. هر چیزی که مقایسهٔ بعدی لازم دارد در همان چهار واقعیت زندگی می‌کند، و هر کس پرونده را بعداً بردارد تاریخچهٔ ترمینال شما را نخواهد داشت. اگر نمی‌توانید هر چهار را پر کنید، اجرا تمام نشده است.