להבדיל בין פיצול IKEv2 לבין בעיה בשרשרת אישורים

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

שני מנגנוני פיצול, תסמין אחד

ל-IKEv2 יש הרחבת פיצול משלו, המוגדרת ב-RFC 7383, המפצלת הודעות IKE מוגנות להודעות IKE קטנות יותר. הצדדים מנהלים משא ומתן על היכולת הזו, וההודעה מורכבת מחדש על ידי מימוש IKE ולא על ידי שכבת ה-IP.

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

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

קראו את החליפין שנכשל

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

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

שנו את הנתיב, לא את האישור

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

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

מדדו את החליפין לפני שתערכו משהו

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

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

השניים הראשונים נותנים את מספר האישורים ואת גודל הקובץ, וזה מדד סביר לכמה גדולה תהיה הודעת האימות. בדיקת ה-ping מדווחת אם דאטהגרם בגודל כזה שורד את הנתיב, ומוני הממשק מראים אם שברים הופלו בקצה שלכם. ב-Windows, הבדיקה המקבילה היא ping עם דגל do-not-fragment וגודל מטען מפורש.

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

תקנו את השכבה שבאמת שבורה

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

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

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