למה לקוחות OpenVPN מפספסים את בוררי ה-IPsec של השער
פינג מהשער מוכיח זרימה אחרת. עקבו אחר מאגר הלקוחות דרך המסלול הנדחף, בוררי ה-IPsec, שרשרת ההעברה ונתיב התשובה.
שלחו פינג למארח מאחורי מנהרת ה-IPsec המרוחקת מהשער והוא עונה נקי, כך המנהרה נראית תקינה והכרטיס ממשיך הלאה. אחר כך לקוח מחובר מנסה את אותו מארח ולא מקבל דבר בחזרה. הפינג הזה מעולם לא היה ראיה לזרימה של הלקוח, כי הוא יצא עם כתובת המקור של השער עצמו והתאים לבורר IPsec אחר. הבנת הסיבה לכך ששני המקרים מתפצלים היא רוב התיקון.
הפינג מהשער בודק זרימה שהלקוח שלכם לא משתמש בה לעולם
כתובת המקור היא שקובעת איזו מדיניות חלה. חבילה שנוצרת בשער יוצאת עם כתובת מה-LAN המקומי שלו או מנקודת הקצה של המנהרה, והמדיניות שמתאימה לה נכתבה בדיוק למקרה הזה. החבילה של לקוח מגיעה לממשק OpenVPN עם כתובת ממאגר הלקוחות, שזהו בורר אחר לגמרי.
לכן הכשל נראה כמו בעיית ניתוב כשבעצם מדובר בבעיית היקף מדיניות. נגישות מהשער מוכיחה שהעמית פעיל ושההצעות נוהלו, והיא לא מוכיחה דבר על האם המאגר מוגן.
דחפו את הקידומת המרוחקת שהאפליקציה באמת צריכה
קחו את הזוג הממחיש 10.8.0.0/24 ללקוחות מחוברים ו-172.30.239.0/25 לרשת המרוחקת המוגנת. מה שלקוח צריך הוא מסלול לקידומת השנייה, לא ל-LAN של השער ולא לכתובת מנהרה אחרת. מסלול שנדחף למאגר הוא מה שגורם ללקוח למסור את התעבורה הזו לשער בכלל. בלעדיו החבילה לא מגיעה לעולם להחלטת המדיניות שאתם מדבגים.
בשרת Community שמקבל מסלולים נדחפים, ההנחיה מקבלת את המסכה האמיתית: push "route 172.30.239.0 255.255.255.128". Access Server מגדיר את אותו יעד דרך הגדרות הרשת הפרטית או כללי הגישה של הגרסה המותקנת, עם מצב מנותב או מתורגם שנבחר בכוונה. עריכת שרשראות חומת אש שנוצרו במקום התצורה האחראית היא הדרך שבה התקנה עובדת נעשית בלתי ניתנת לשחזור.
לאחר החיבור קראו את טבלת הניתוב של הלקוח ולא את הכוונה של השרת. מסלול שמכסה רק את המאגר משמעו שהדחיפה לא הגיעה, ומסלול ברירת מחדל דרך המנהרה רחב מהדרישה הזו ויפתיע אתכם בהמשך. בדקו את המסכה וגם את הקידומת, כי /25 שנדחף כ-/24 שולח תעבורה של כתובות שכנות בנתיב שלא יכול לשאת אותה. אחר כך ודאו שהלקוח בחר בממשק המנהרה ליעד הזה.
גרמו לבוררים לכלול את מאגר הלקוחות
לגישה מנותבת ששומרת על כתובות הלקוחות, מדיניות ה-IPsec חייבת להגן על התעבורה בין המאגר לקידומת המרוחקת. בוררים שנכתבו עבור ה-LAN של השער עצמו מתירים את הפינג וזורקים את הבקשה של הלקוח, וזו בדיוק האסימטריה שהחלה את החקירה הזו.
בחנו את המדיניות שנוהלה וגם את ההצעות שהוגדרו, למשל עם ipsec statusall ב-strongSwan או פקודת הסטטוס המקבילה למימוש שלכם. ב-IPsec מבוסס מדיניות המסלול הרגיל יכול להצביע על ממשק פיזי בזמן שהתעבורה המתאימה עדיין מוצפנת, כך שהעדר התקן מנהרה לא מוכיח דבר. השוו את זוגות הבוררים למאגר ולקידומת שרשמתם.
NAT מקור גנרי בשער יכול גם הוא לשבור את ההתאמה. אם כלל masquerade משכתב את המקור של הלקוח לפני בדיקת המדיניות, החבילה כבר לא נראית כמו הבורר שכתבתם. זו סיבה אחת לכך שכלל masquerade רחב הוא תיקון גרוע ל-VPN שני: הוא משנה איזו מדיניות חלה ואיזו כתובת הצד המרוחק מתעד. פטרו את התעבורה שאתם מתכוונים לנתב, או תרגמו אותה בכוונה ועדכנו את הבוררים.
בחרו בניתוב או בתרגום בכוונה
ניתוב משאיר את כתובת הלקוח גלויה לצד המרוחק, כך שלוגים מרוחקים וכללים לפי מקור נשארים בעלי משמעות, והוא דורש שהשער המרוחק יכיר את נתיב החזרה למאגר. תרגום מסתיר את המאגר מאחורי כתובת אחת, מה שמסיר את בעיית נתיב החזרה והורס את הזהות של כל לקוח.
בחרו עיצוב אחד וכתבו אותו, כי השניים צריכים בוררים שונים וסדר חומת אש שונה. masquerade שהוחל למחצה נופל ביניהם ולא מספק אף אחד מהם. הבחירה הכתובה היא גם מה שמאפשר למהנדס הבא להבדיל בין באג להחלטה מכוונת.
סגרו את הלולאה בהעברה ובתשובה
השער חייב להעביר את הפרוטוקול והיעד שאתם מתכוונים אליהם, כלומר העברת IP מופעלת ושרשרת העברה שמתירה את הזוג. אחר כך הצד המרוחק חייב לשלוח תשובות חזרה דרך נתיב ה-IPsec, וזו החלטת ניתוב בשער שלהם ולא בשלכם. שני החצאים הם תצורה רגילה, ושניהם נשארים בקלות חצי גמורים. בדקו אותם בנפרד כדי שכלל העברה חסר לא ייחשב למנהרה שבורה.
אמתו עם בקשה אמיתית אחת מלקוח לאפליקציה, בצפייה בה עוברת דרך ממשק OpenVPN, החלטת ה-IPsec והמארח המרוחק. בחנו את התשובה כתצפית נפרדת, כי בקשה שמגיעה ותשובה שלעולם לא חוזרת נראות זהות ממקום מושבו של הלקוח. בקשה אחת עם מעקב שווה יותר מכל מספר של פינגים מהשער.
שמרו על הרשאת היעד צרה בזמן הבדיקה, וודאו שלקוח בלי הכלל לא יכול להגיע לשירות. מסלול מותקן בתוספת אסוציאציה מבוססת אינו אותו דבר כמו גישה שניתנה.