תקורת IPsec: המצב, NAT-T והאלגוריתמים משנים אותה
מספר תקורה אחד שפורסם מתאר אנקופסולציה אחת בנתיב אחד. חברו את הכותרות שהמנהרה שלכם באמת מנהלת משא ומתן עליהן, ואז מדדו את הנתיב.
איפשהו במדריך יש מספר, בדרך כלל בין שישים לשמונים בייט, שמישהו החסיר מ-1500 כדי לקבל MTU של ממשק. המספר הזה מתאר אנקופסולציה מסוימת בנתיב מסוים. החליפו את המצב, את משפחת הכתובות החיצונית, את הצופן או את נוכחות NAT, והחשבון כבר לא חל על המנהרה שלכם.
המספר הגיע ממנהרה אחרת
תקורה אינה תכונה של IPsec במובן המופשט. היא תכונה של החבילה שנבנית בפועל: מצב שעליו סוכם, כותרת חיצונית, כותרת הגנה, ריפוד, שדה שלמות ואולי גם עטיפת UDP נוספת.
מספר שמצוטט למצב תעבורה עם IPv4 וללא NAT מתאר חבילה קטנה יותר ממצב מנהרה עם IPv6 תחת מעבר NAT. שניהם נכונים למקרה שלהם. העתקה של אחד מהם לפריסה אחרת היא הדרך שבה אנשים מגיעים ל-MTU ששובר העברות גדולות. הכשל שקט כי בקשות קטנות ממשיכות לעבוד.
חברו את השכבות שבאמת נמצאות שם
התחילו בכותרת ה-IP החיצונית והתקדמו פנימה. במצב מנהרה החבילה המקורית נמצאת בפנים, כך שהכותרת החיצונית היא תוספת ולא החלפה. RFC 4303 מתאר את כותרת ESP, את הריפוד ואת נתוני השלמות שאחריה.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
אף אחת מהשורות האלה אינה קבועה בין פריסות, ושורת הריפוד אינה קבועה אפילו בתוך פריסה אחת. זו כל הסיבה שמספר תקורה אחד שפורסם מאכזב.
שני אתרים יכולים לחלוק על אותה מנהרה
החבילה המוגנת עדיין צריכה לחצות את הנתיב החיצוני, והנתיב החיצוני אינו זהה בכל מקום. קישור גישה PPPoE נושא פחות מקטע Ethernet נקי. רשת סלולרית עשויה להתכווץ עוד, וספק שמנהר את התעבורה שלו מוסיף אנקופסולציה נוספת שאיש לא הזכיר. מנהרה שעובדת בקישור אחד ונכשלת באחר מתארת את הקישור השני, לא את הפרוטוקול.
גם שני הכיוונים יכולים להיות שונים. נתיב א-סימטרי יכול לתת העלאה שעובדת והורדה שנתקעת, מה שנקרא כבעיית יישום עד שמסתכלים על גדלי חבילות במקום על נגישות. הצלחה של ping קטן מוכיחה מעט מאוד על תגובה בגודל מלא.
מדדו במקום להחסיר
מצאו את הדאטגרם הגדול ביותר ששורד את הנתיב. אחר כך השוו אותו לערך שהממשק מדווח:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
הורידו את גודל ה-ping עד שתגובות מגיעות, והתייחסו לערך הגדול שעובד כתקציב של אותו נתיב. הפלט של xfrm אומר לכם איזה מצב ואילו אלגוריתמים סוכמו, וזה הקלט לכל חישוב כן. הלכידה מאשרת אם על החוט נמצא ESP או ESP עטוף ב-UDP, וזה מכריע את שאלת ה-NAT בלי ניחושים.
הקצו ערך אחד גם למישור הבקרה. לחבילות לחיצת היד של IKE יש מבנה שונה מחבילות נתונים, ולכן גודל שנגזר מלכידת לחיצת יד אינו MTU של מישור הנתונים.
שימו את המספר במקום שבו הוא שייך
עבור TCP דרך מנהרה, מהדק MSS הוא לעתים קרובות הבקרה הפחות פולשנית, כי הוא מקטין את מה שהקצוות שולחים בלי לשנות את המנהרה עצמה. במנהרה מבוססת נתיבים, קבעו את ה-MTU של ממשק המנהרה במכוון ותעדו מדוע. עשיית שניהם בבת אחת ואז מדידה לא נותנת לכם שום מידע על איזה מהם עזר.
שמרו יחד בכרטיס את המצב שסוכם, המשפחה החיצונית, מצב ה-NAT והתסמין שניתן לשחזר. סט מתועד של ארבע עובדות מנצח קבוע שנזכר, והוא הגרסה היחידה של זה ששורדת את שדרוג הלקוח הבא.