סריקה גולמית של 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 אומר ליומנפ להניח שאין לו זכויות גולמיות או אזנה, מה שמשנה את השיטה ולא מעניק דבר.

קראו כל דגל כשינוי אחד, לא כתיקון

התייחסו לכל אפשרות כהצהרה על השיטה. אף אחת מ־-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. אם לחיצת היד נכשלת, רשמו את מחרוזת השגיאה המקומית במקום להכליל על המנהרה. שמרו את הערת ההיקף לצד התוצאה, כי האדם הבא צריך לדעת איזו שיטה יצרה אותה.