ESP יוצא ללא תשובה אינו אומר שה־VPN מת
ESP מגן על כיוון אחד לכל אגודה ואינו מאשר מאומה. יישרו את השיחה הפנימית ואת ה־SA הנכנסת לפני שמכנים את השרת לא מגיב.
לכדתם תעבורה במארח ה־IPsec, ראיתם מקטעי ESP יוצאים, לא ראיתם דבר חוזר והסקתם שהצד הרחוק מקולקל. הלכידה אינה תומכת במסקנה הזו. ESP מגן על כיוון אחד של שיחה ואינו מאשר מאומה בשכבת ה־IP, ולכן היעדר ESP חוזר יכול באותה קלות לומר שליישום לא היה מה לומר, כמו לומר שהמנהרה מתה. קראו את החליפין הפנימי ואת מצב צד הקליטה לפני שאתם מאשימים מי מהקצוות.
המיתוס: כל מקטע מוגן זוכה לתשובה
ESP אינו פרוטוקול בקשה־תשובה. הוא מצפין ומאמת כל מה שהמדיניות בוחרת, והמקבל מאמת, מפענח ומוסר את המקטע הפנימי הזה בלי לייצר מקטע משל עצמו. שאילתת UDP שהיעד מתעלם ממנה, או הד ICMP שמדיניות הכניסה פוסלת, מייצרים שקט בשני הכיוונים כתוצאה הנכונה. התייחסות לאותו שקט כתקלת תעבורה שולחת אתכם לחפש תקלת רשת שמעולם לא הייתה.
מה שלכידה חד־כיוונית באמת מוכיחה הוא שמחסנית השולח הצפינה משהו בנקודת התצפית ההיא. דבר לא על ההגעה, ודבר לא על הכוונה להשיב. השאלה המועילה אינה "מדוע אין תשובה" אלא "מה השיחה הפנימית הייתה אמורה להפיק".
שתי SA, שני SPI, שיחה אחת
אגודות האבטחה של IPsec חד־כיווניות, ולכן חליפין מוגן רגיל כולל אגודה נכנסת ואגודה יוצאת עם מזהים נפרדים ומצב בלתי תלוי. חיפוש תעבורת החזור לפי ה־SPI של המקטע היוצא הוא אפוא שגיאת קטגוריה, משום שכל תשובה נוסעת תחת ה־SA היוצאת של העמית עם ה־SPI שלו עצמו. התאימו את הזוג לפי בוררי תעבורה וכתובות העמית במקום זאת.
החלפת מפתחות מסבכת את התמונה לכמה שניות בכל פעם, מפני שמצב ישן ומצב מחליף יכולים לחפוף. אם התסמין החל סביב החלפת מפתחות, אספו מזהי אגודה וחתימות זמן יחד ולא רק את שם החיבור.
מה על המקבל לעשות לפני שדבר משיב
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
כל שורה נכשלת באופן עצמאי ולכל כשל בעלים אחר, ולכן לכידה אחת אינה יכולה להבחין ביניהם. מונה הכניסה הוא הראיה הישירה היחידה להגעה, מפני שמקטע שנכשל באימות או בבדיקת החזרה נזרק בלי כל תגובה. עמית שמונה הכניסה שלו לא זז אינו שולח לכם אפוא שום מידע על המדיניות שלו.
המסירה היא שלב נפרד מהפענוח. המצב יכול להיות תקף והמקטע בכל זאת נזרק לאחר מכן בידי מדיניות כניסה או נתיב שאינו כולל את היעד הפנימי, לכן בדקו אם המארח המיועד ראה טקסט גלוי במקום להניח שמונה נקי פירושו שהמקטע הלך לאן שרציתם.
ESP מקורי אינו UDP
ESP מקורי הוא פרוטוקול IP 50, שאינו TCP ואינו UDP ואין לו שום פורט. לכן כלל חומת אש שמתיר IKE על UDP 500 אינו אומר דבר על נתיב הנתונים, ומסנן שנכתב סביב פורטים יכול לתת למנהרה לנהל משא ומתן ואז לזרוק את כל מה שנישא בתוכה. בדקו את נתיב הנתונים בעצמו, במצב שבאמת צפיתם בו.
מאחורי NAT הצורה משתנה: המטען המוגן נוסע בתוך UDP, בדרך כלל בפורט 4500, כפי שמגדיר RFC 3948. תעדו את המצב הפעיל לפני כתיבת כלל כלשהו, מפני שהתקן בנתיב עשוי לטפל ב־ESP מקורי וב־ESP עטוף UDP אחרת לגמרי, וחלק מתיבות הביניים מתירות אחד וזורקות את השני.
קראו מונים ששייכים לתקרית הזו
במארח strongSwan, swanctl --list-sas מדווח מוני מקטעים ובתים לכל אגודה בשני הכיוונים, וזה מספיק כדי להפריד בין "מעולם לא הגיע" לבין "הגיע ולא נענה". בלינוקס, /proc/net/xfrm_stat סופר כשלים מצטברים כמו מצב חסר, מדיניות חסרה ושגיאות פרוטוקול. הסכומים האלה מצטברים מהאתחול ושייכים למרחב שמות רשת אחד, ולכן מספר גדול אינו ייחוס.
קחו שתי קריאות סביב חלון התקרית במרחב השמות הנכון והשוו הפרשים, אחרת תיצמדו שגיאות של השבוע שעבר לכרטיס של אחר הצהריים. רשמו את מרחב השמות ושתי חתימות הזמן בכרטיס כדי שהקורא הבא יוכל לשחזר את ההשוואה במקום לסמוך על סכום.
תנו שם לשלב, לא לחשוד
מסקנה מועילה אומרת היכן המקטע נעצר: מעולם לא התקבל, התקבל ונזרק, נמסר אך לא נענה, או נענה ואבד בדרך חזרה. כל אחד מאלה מצביע על בעלים אחר ועל פקודה הבאה אחרת. "אין תגובה משרת ה־VPN" מרסק ארבע תקלות נפרדות למשפט אחד שהלכידה מעולם לא הצדיקה.
השאירו לכידות צרות, והשאירו מצב גרעין גולמי מחוץ לכרטיסים, מפני שהוא יכול לשאת חומר מפתח שאין לו מה לעשות מחוץ למארח. הפרשי המונים וחתימות הזמן הם החלקים ששווה למסור לאדם הבא.