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