משתמש שער ב-Access Server: ניתוב ה-LAN של סניף לקוח

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

שתי כתובות, שתי תביעות בעלות שונות

כשהלקוח מתחבר, Access Server מקצה לו כתובת מבריכת ה-VPN המוגדרת, למשל 10.90.0.0/24. ההקצאה הזו היא חכירה למארח אחד. שום דבר בחיבור לא אומר שאותו לקוח עומד גם מול 10.60.0.0/24, והשרת לא ינחש: קידומת LAN נגישה דרך לקוח מסוים רק אם מנהל מצהיר עליה.

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

מה הגדרת השער באמת מתקינה

ב-Admin Web UI ההצהרה היא מאפיין משתמש: הפעילו Configure VPN gateway במשתמש המחבר והזינו את קידומת הסניף האמיתית ב-Network on the VPN client side. המשתמש הזה מאומת כמו כל אחר, לכן הוא זקוק למדיניות אישורים המתאימה להתקן ללא השגחה, ופרופיל ההתחברות האוטומטית שלו הוא סוד, לא קובץ נוחות.

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

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

השלימו את נתיבי החזרה של שתי הרשתות

תוכנית קונקרטית: מטה 10.40.0.0/24, סניף 10.60.0.0/24, בריכת VPN 10.90.0.0/24, ו-Access Server נגיש בכתובת פרטית בצד המטה. הנתב במטה זקוק למסלולים לקידומת הסניף ולבריכה, שניהם לעבר Access Server. בלעדיהם המנהרה נושאת את הבקשה ו-התשובה יוצאת דרך שער ברירת המחדל, מה שיוצר את החיבור החצי-פתוח המוכר.

בסניף המחבר חייב להעביר חבילות שאינן ממוענות אליו: העברת IP במערכת ההפעלה שלו ועוד הרשאת העברה המוגבלת לממשקי המנהרה וה-LAN; ב-Linux זה net.ipv4.ip_forward=1 יחד עם כללי שרשרת ה-forward, ב-Windows זה routing and remote access. לאחר מכן המארחים בסניף זקוקים לנתיב חזרה: או שהמחבר הוא שער ברירת המחדל שלהם, או שהשער הקיים נושא מסלולים ספציפיים לקידומות המטה והבריכה.

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

קראו כשל כנתיב, לא כהרשאה

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

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

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

המדריך site-to-site של Access Server מפרט את אותן הגדרות בסדר המוצר; כדאי לעקוב אחריו פעם אחת לפני שמתאימים את התכנון לקידומות שלכם.