תפוקת IPsec נמוכה מהצפוי? בדקו קודם את ה-SA הפעיל
רשימת טרנספורמציות ארוכה אינה הסשן שמגן על ההעברה שלכם. תעדו את ה-SA שנקבע במשא ומתן, את גודל המטען ואת הקצב שנמסר בפועל לפני שאתם מאשימים את ההצפנה.
התצורה מציעה שמונה טרנספורמציות, מישהו קורא את החזקה ביותר, ומספר התפוקה מוצמד אליה. סביר שהמנהרה לא בחרה בטרנספורמציה הזו, וגם לא הריצה את עומס העבודה שמישהו דמיין. מה שנקבע במשא ומתן הוא רשומה אחת מהרשימה, עם גודל מנה אחד, בכיוון אחד, על גרסה אחת. מדדו את זה, והדיון על אלגוריתמים בדרך כלל נגמר לפני שהוא מתחיל.
התסמין: מספר מתחת למה שהתצורה מבטיחה
רשימת טרנספורמציות ארוכה מתארת אפשרויות, וכל אפשרות נמדדת על הנייר ולא על החומרה הזו. התוצאה שנקבעה היא שילוב אחד ששני הצדדים קיבלו, והוא יכול להיות החלש ביותר שכל צד עדיין מתיר מטעמי תאימות. מה שהשילוב הזה משיג תלוי במצב ה-offload, בגודל המנה ובהתנהגות התורים, כך ששני התקנים עם קובץ מדיניות זהה יכולים להגיע רחוק מאוד זה מזה. הרשימה היא תפריט; האסוציאציה היא ההזמנה שחזרה.
קריאת הרשימה אומרת לכם מה היה יכול להיבחר. קריאת האסוציאציה אומרת לכם מה באמת נושא את ההעברה, וזה הדבר היחיד שמספר תפוקה מתאר. כל שלב כוונון שמתחיל מהרשימה הוא ניחוש עם ניירת נוספת.
תעדו את האסוציאציה שנושאת את ההעברה הזו
ב-ASA show crypto ipsec sa מציג את האסוציאציות הפעילות עם הטרנספורמציות שלהן ומונים לכל כיוון, ו מפנה הפקודות של Cisco מתעד את הפלט הזה. בחרו את הצד השני ואת הכיוון שחשובים, ושימו לב ששיחוח מחדש של מפתחות מחליף את האסוציאציה ומאפס את המונים שלה, מה שמבטל בשקט קו בסיס שעדיין סמכתם עליו. שמרו את הפלט ליד הערות הבדיקה כדי שההרצה הבאה תדע למה להשוות. מזהה אסוציאציה שמשתנה בין הרצות הופך כל השוואה מאוחרת לחסרת משמעות.
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
חמש שורות מספיקות כדי שהמדידה תהיה ניתנת לשחזור, וכל אחת מהן שוללת הסבר מסוים כשהיא חסרה. אף אחת מהן אינה רשומה מרשימת ההצעות, כי הרשימה לא יכולה לומר מה מגן על הביטים שלכם ברגע זה. מלאו את הטבלה פעם אחת והתקרית הבאה תתחיל מנתונים במקום מוויכוח חדש על אלגוריתמים.
שורת קישור הגישה היא זו שאנשים מדלגים עליה, והיא זו שמסבירה לרוב פער שנראה קריפטוגרפי. שכבת תשתית רוויה או policer לאורך המסלול מייצרים אותה צורת תסמין כמו מנוע איטי.
מדדו כיוון אחד עם עומס מבוקר
הריצו את הבדיקה מנקודת קצה ב-LAN שמייצגת את האפליקציה ולא מהשער עצמו, כי בדיקה שנוצרת בשער עשויה לפעול לפי מדיניות מקומית אחרת. מדדו כיוון אחד לפני שמוסיפים זרם שני, ותעדו גם את הקצב המוצע וגם את מה שהמקלט באמת קיבל. הרצת UDP מוגבלת קצב מפרידה בין העומס המוצע לתגובת העומס של TCP, ואילו שולח UDP ללא הגבלה אינו אבחון נייטרלי. תעדו גם את אורך המטען, כי דטאגרם גדול יותר משנה גם את קצב המנות וגם את תקורת העטיפה.
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30הריצו את אותה בדיקה פעמיים עם אותו אורך מטען ואותה משך זמן, כי הרצה אחת לא מפרידה בין תקרה לדקה רעה. אם המקלט מדווח על פחות מנות ממה שהשולח שלח, האובדן הוא הממצא שלכם, ומנוע ההצפנה הוא רק אחד מכמה מועמדים.
הסבירו את הפער לפני שאתם מכווננים משהו
בדקו את מדיניות ההעברה, נפילות תור, שגיאות ממשק ומגבלות משאבים יחד עם מסלול ההצפנה, כי חוסר בקצב לבדו אף פעם לא מזהה מעבד. שמרו גם על שכבות החשבונאות מפורשות: בייטים של המנהרה החיצונית כוללים עטיפה, ושליחות חוזרות מזיזות את היחס בין מונים פנימיים וחיצוניים. השוואת מונים לא קשורים בייט מול בייט מייצרת פער שלא היה קיים מעולם.
גודל המנה ראוי להשוואה מבוקרת משלו ולא למספר שהועתק מדוגמה ישנה. TCP MSS מתאים את TCP ואין לו שום השפעה על דטאגרמים שרירותיים של UDP, ולכן ערך קבוע של 1350 שהועבר ממסמך ישן לא מודד דבר וחצי. שנו את אורך המטען בכוונה וצפו במה שהמקלט מדווח.
שנו משתנה אחד ושמרו על עומס העבודה
כשקו הבסיס חוזר על עצמו בתוך פס צר, שנו משתנה נתמך אחד והריצו שוב את משימת האפליקציה המקורית. השלב הזה הופך מספר לסיבה, והוא היחיד שמצדיק לגעת בתצורה. חזרו על אותו עומס עבודה ולא על אחד נוח יותר.
אל תבטלו הצעות, אל תחלישו אימות ואל תכבו הגנה כדי להגדיל מספר סינתטי. המהלכים האלה משנים את מצב האבטחה ואז מודדים את התוצאה של השינוי הזה, לא את הקיבולת של המנהרה.