איך לקרוא את חילופי ה-IKEv2 הראשונים בקובץ לכידת מנות

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

ודאו שאתם מסתכלים על חילופי הפתיחה

משא ומתן של IKEv2 מתחיל ב-IKE_SA_INIT, סוג חילופין 34, מזהה הודעה 0. היוזם בוחר SPI שאינו אפס, וה-SPI של המשיב הוא אפס בבקשה הראשונה הזו ואינו אפס בתשובה. שלוש העובדות האלה מפרידות בין ניסיון חדש לבין חידוש מפתחות או לבין הודעת IKE_AUTH שבמקרה נמצאת בראש הלכידה.

שדות הכותרת קריאים, וכך גם מטעני ההצעה, החלפת המפתחות וה-nonce. קריא אינו אומר מאומת: אף אחד מהצדדים לא הוכיח זהות בנקודה זו, והערך הפרטי של Diffie-Hellman לעולם אינו מופיע על החוט.

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

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

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

קראו דחייה לפני שאתם קוראים הצלחה

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

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

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

פורט 4500 אינו פרוטוקול אחד

בדרך כלל UDP 500 נושא את חילופי הפתיחה. לאחר שזיהוי NAT רץ, IKE עובר ל-4500 ומצמיד לכל הודעה סמן אפס של ארבעה בתים שאינו ESP. ESP עטוף באותו פורט מתחיל לעומת זאת ב-SPI של ESP שאינו אפס, ו-keepalive של NAT באורך בית אחד הוא צורה שלישית שמופיעה כששום דבר אחר לא קורה.

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

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

שתיקה מתארת את נקודת התצפית

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

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

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

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