מה לתעד עבור VPN בין אתרים: סלקטורים והיקף

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

מוגדר אינו מנוהל במשא ומתן

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

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

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

מנהרות מבוססות נתיב בוחרות אחרת

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

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

התרגום שייך לאותה טבלה

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

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

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

צרף את דרישת השירות

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

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

הפוך את הרשומה לתכנית בדיקה

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

swanctl --list-sas

שלד של חמש שורות בדרך כלל מספיק כדי לשמור על הרשומה ישרה. הגרסה שלמטה נכנסת לכרטיס שינוי בלי קיצור:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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