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

שרטטו את הקו היכן שהחבילה מפסיקה להיות מוצפנת

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

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

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

חומת אש כנקודת סיום: התקן אחד, נקודת מדיניות אחת

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

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

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

נתב כנקודת סיום: צעד הבדיקה הופך לאופציונלי

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

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

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

שאלו את שני המועמדים את אותן חמש שאלות

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

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

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

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

אמתו את הנתיב בלכידה, לא בשרטוט

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

tcpdump -ni wan0 esp
tcpdump -ni lan0 host 10.60.4.20
ip xfrm policy list

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

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

מאמרים קשורים