Ping אינו הוכחה: בדקו את הנתיב בין שני אתרים

המנהרה פעילה, השערים עונים זה לזה, והמשתמשים באתר אחד עדיין אינם יכולים לפתוח את שיתוף הקבצים באתר האחר. מישהו עושה פינג מהשער, מקבל תשובה ומכריז שהרשת בריאה. התשובה הזו עברה בין שני התקנים שלא היו הבעיה מעולם. בדיקה שימושית מתחילה במארח שזקוק לשירות, משתמשת בפרוטוקול שהאפליקציה משתמשת בו ומשחזרת את התנאי שבו היא נכשלת. כל השאר הוא אור ירוק לנתיב שאין עליו אף אחד.

התחילו בלקוח שזקוק לשירות

רשמו ארבעה דברים לפני כל בדיקה: כתובת הלקוח, כתובת היעד, שם המארח ופורט האפליקציה. אחר כך אשרו שהשירות עובד מקומית באתר שלו, ממארח שלידו. בלי קו הבסיס הזה אינכם יכולים להבדיל בין מנהרה שבורה לשירות שבור, ומחצית מהקריאות האלה היא השנייה.

נסו את שם המארח המתועד, ובמקום שהשירות מאפשר זאת, בדיקת כתובת ישירה של אותו פורט. חיפוש שם שנכשל וכתובת שנפתרה ואינה נגישה מובילים אתכם בנתיבים שונים. אם תחליפו שם מארח בכתובת IP, אל תשביתו את בדיקת הזהות של HTTPS כדי שזה יעבוד; אזהרת תעודה היא מידע, לא מכשול.

עברו את הנתיב בכל קצה

קראו את המסלול שהלקוח בוחר, אחר כך את המסלול שהשער בוחר ליעד הזה, אחר כך את המונים או לכידה מוגבלת בכל קצה. אתם מחפשים שתי עובדות: האם הבקשה הגיעה לרשת המקומית המרוחקת, והאם חזרה תשובה. מוני ממשק כוללים כל זרימה אחרת, לכן התאימו לפי חתימת זמן מדויקת וזוג כתובות ולא לפי צורת הגרף. לכידה בקצה הלא נכון גרועה מהיעדרה, כי היא נראית כראיה.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

אם הבקשה מופיעה בקצה המרוחק בלי תשובה מאחוריה, הבעיה בצד השני: חומת אש, מסלול חזרה חסר או מארח שאינו מקבל את המקור. אם הבקשה אינה מופיעה כלל, המסלול המקומי או בוררי המנהרה לא נשאו אותה, והצד השני עוד לא שווה חקירה.

השתמשו בפרוטוקול שהאפליקציה משתמשת בו

ICMP הוא בדיקה חלשה. אפשר לסנן אותו, להגביל אותו בקצב או לטפל בו במדיניות שונה מזו של השירות, מה שהופך גם את הצלחתו וגם את כישלונו לדו-משמעיים. בדקו את הפורט האמיתי, וכאשר אפשר, את לחיצת היד האמיתית של הפרוטוקול.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

לחיצת יד TCP שהושלמה מוכיחה נגישות ומדיניות לאותו פורט. היא אינה מוכיחה שהאפליקציה עובדת: אימות, העלאה או קריאת API מסוימת עדיין עלולים להיכשל. בדקו את הפעולה שהמשתמשים באמת מבצעים, באמצעות מקבילה בלתי מזיקה במקום לשלוח שוב ושוב עסקה אמיתית.

שחזרו את התנאי שנכשל

כשלים שמופיעים רק בהעברות גדולות הם בעיית גודל, לא בעיית קישוריות. שלחו מנה גדולה עם סיבית don't-fragment מופעלת וראו היכן היא נעצרת. אם בקשה קטנה מצליחה וגדולה נתקעת, ה-MTU של המנהרה וטיפול ה-MSS בשערים הם החשודים הבאים.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

אם רק תת-רשת אחת נכשלת, הביטו בבוררי התעבורה, בהכרזות המסלול ובשער החזרה של אותה תת-רשת. אם רק שם המארח נכשל, עקבו אחרי DNS, כולל איזה פותר הלקוח השתמש ובין אם התצוגה המרוחקת נראית מאותו אתר. שלושה כשלים שונים, שלושה תיקונים שונים, ובדיקת הפינג אינה מבחינה באף אחד מהם.

אחרי התיקון, חזרו על אותה בדיקה

הריצו שוב את אותו לקוח, יעד, פורט ומטען. אחר כך התחברו מחדש או תרגלו את נתיב הגיבוי אם בתכנון יש כזה, כי תיקון שעובד רק כל עוד מופע המנהרה המקורי חי לא נבדק. החזיקו את הבדיקה קשורה למקור אמיתי, ליעד אמיתי ולפעולה אמיתית ולא למחוון ירוק אחד על לוח בקרה.

רשמו את ארבעת ערכי הבסיס ואת התוצאה. הדיווח הבא על אותו סימפטום יוכל אז להתחיל מראיות ולא מפינג.