פינג דרך VPN: למה כללי תגובת הד מפספסים את מסלול החזרה

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

החבילה משנה סוג, לא פורט

בקשת הד היא ICMP מסוג 8, קוד 0, והיא נושאת מזהה ומספר רצף. התגובה היא מסוג 0, קוד 0, עם אותו מזהה ואותו רצף, וקצוות ה-IP מוחלפים. RFC 792 מגדיר את השדות האלה, והמזהה הוא שמאפשר לשולח להתאים תגובות לבקשות שלו.

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

שלושה הקשרים מחליטים על החבילה

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

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

מסננים בעלי מצב ובלי מצב מטפלים בתגובה אחרת

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

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

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

התרגום משנה גם את המזהה

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

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

אל תמזגו שגיאות ICMP לתוך מדיניות ההד

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

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

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