מדוע לקוחות Access Server אינם נגישים מה-LAN

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

קראו את כתובת המקור שהשירות רואה

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

הוסיפו את המסלול במקום שבו מוכרעת התגובה

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

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

ההעברה והמסננים חייבים להסכים עם המסלול

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

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

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

מנותב או ממוסך: בחרו במכוון

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

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

תת-רשת מאחורי הלקוח היא משימה נפרדת

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

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

אמתו בזרימה אחת ובלכידה אחת

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

tcpdump -ni any host 10.90.0.25 and port 443

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

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