ESP הוא פרוטוקול IP 50, לא פורט TCP 50: מה לאפשר
מספרי פרוטוקול ומספרי פורט הם מרחבי שמות שונים. כלל לפורט TCP 50 אינו מתיר דבר, ו-NAT traversal מעביר את ESP ל-UDP 4500.
טפסי חומת אש מבקשים פורט TCP, והערך המתבקש הוא 50. הערך הזה אינו מתיר דבר, כי ESP הוא פרוטוקול IP מספר 50 ומספרי פרוטוקול אינם פורטים. שני מרחבי השמות חולקים רק מספרים שלמים קטנים ולא דבר אחר, והטעות נשארת בלתי נראית עד ש-IKE מסתיים והתעבורה המוגנת לעולם אינה מגיעה.
שני מרחבי שמות שחולקים מספרים קטנים
כותרת IP נושאת שדה פרוטוקול שמציין מה בא אחריו: 6 עבור TCP, 17 עבור UDP, 1 עבור ICMP, 50 עבור ESP, 51 עבור AH. כותרת TCP או UDP נושאת מספרי פורט, שבוחרים תהליך במארח היעד. פרוטוקול 50 ופורט TCP 50 הם ערכים לא קשורים, אבל תיבת דו-שיח יכולה לגרום להם להיראות ניתנים להחלפה.
לכן כלל העברת פורטים אינו יכול לבטא ESP מקורי. אין פורט יעד של ESP להעביר, והתקן שמבין רק כללי פורט כלל אינו מכיר את הפַּקֶט הזה. הכלל הנכון מציין את פרוטוקול ה-IP במקום. כל תיבת דו-שיח של פורטים היא הכלי הלא נכון עבור הפַּקֶט הזה.
לבלבול יש חצי שני. כשהפַּקֶט מוצפן, כל מה שבתוכו אטום, כולל כותרת ה-TCP של החיבור המקורי. חומת אש שבודקת פורטים בפַּקֶט הזה מסתכלת על הכותרת החיצונית, שבמקרה המקורי אין בה פורטים לבדוק.
ESP מקורי, ואז החלופה העטופה
ESP מקורי ננשא ישירות כפרוטוקול IP, וזה יעיל ומסורבל באותה מידה. יעיל כי אין כותרת נוספת, ומסורבל כי כל התקן שמתרגם כתובות ופורטים אינו יכול לעקוב אחריו. NAT traversal קיים כדי לפתור זאת, על ידי עטיפת פַּקֶט ה-ESP בתוך UDP כדי שלמתרגם יהיו פורטים לשכתב.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
שתי הצורות הן פריסות חלופיות של אותו ערוץ נתונים, לא שכבות של אחד. התרת ESP מקורי אינה מתירה את הצורה העטופה, והתרת UDP 4500 אינה מתירה תעבורה מקורית, ולכן מערכת כללים חייבת להתאים לפריסה ולא לכסות את שתיהן בטעות.
גם הזיהוי חשוב כאן. נקודות הקצה מחליטות בין הצורות במהלך המשא ומתן, והמעבר קורה בדרך כלל כשמזוהה NAT ביניהן. לכן מסלול שמשתנה לאחר הקמת המנהרה עלול להעביר את התעבורה למרחב שמות שהכללים שלך מעולם לא כיסו.
קרא איזו צורה החיבור באמת משתמש
שאל את נקודת הקצה במקום לנחש מחומת האש. בלינוקס רשומת המצב מדווחת אם האגודה משתמשת בעטיפת UDP ואילו פורטים מעורבים. לכידת פַּקֶטים עונה על אותה שאלה מהחוט, ושתיהן מהירות יותר מקריאת מערכת כללים ותקווה.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'הפקודה הראשונה מציגה סוג עטיפה כשמשתמשים ב-NAT traversal ושום דבר כשלא. השנייה מציגה איזו משתי הצורות באמת חוצה את הממשק, וזה מכריע בוויכוחים על תצורה שנראית נכונה על הנייר.
הראיה הנגדית שייכת לאותו שלב. כלל שמדווח אפס התאמות אומר לך שהפַּקֶט מעולם לא הגיע אליו, וזו שאלה של ניתוב או של בורר, לא של חומת אש.
ואז אמת את ערוץ השליטה בנפרד. ל-IKE יש פורטים משלו ויומנים משלו, ומשא ומתן שהושלם בלי נתונים הוא בדיוק הפיצול שהמאמר הזה עוסק בו.
כתוב את הכלל במרחב השמות הנכון
כלל פרוטוקול וכלל פורט הם הוראות שונות, ולכן הכלי חייב לבטא את זו שאתה מתכוון אליה. ב-nftables התאמת הפרוטוקול מפורשת, והחלופה העטופה מקבלת כלל UDP משלה. החזק את שני הכללים זה לצד זה כדי שהזוג יהיה גלוי בסקירה.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptהתנגד לפיתוי להרחיב אחד מהכללים כדי לפצות על אבחון שגוי. התרת הכול לפרוטוקול ESP בכל ממשק, או התרת UDP מכל מקום לכל מקום, מתקנת סימפטום ומסירה את השליטה שניסית להגדיר. הזרימה הצרה הנתמכת כמעט תמיד מספיקה ברגע שהצורה ידועה.
לבסוף, שמור על השכבות ישרות כשהמנהרה עובדת והאפליקציה לא. פַּקֶטים שמגיעים לשער עדיין זקוקים להעברה, למסלול חזרה ולמדיניות שמקבלת אותם, ואף אחד מאלה אינו מבוטא בכלל ESP. הפורט החסר מסביר כשל מסוים, לא כל כשל IPsec. החזק את תיקון הכלל ואת בדיקת הניתוב כשני מסקנות נפרדות.
רשום את הצורה שהתבוננת בה, את כלל הפרוטוקול שהוספת ואת המונה שראית לאחר מכן. שלוש שורות, והאדם הבא יוכל להבחין בין טעות במרחב שמות לטעות בניתוב בדקה במקום בצהריים שלמים.