LAN מאחורי הפעלה אחת של AWS Client VPN: מה מועבר הלאה
הפעלה שעובדת במארח אינה מתרחבת מעצמה אל ה-LAN. בדקו את תמיכת הלקוח, את ההעברה, את התרגום ואת נתיב התשובה בסדר הזה.
המחשב הנייד מתחבר לנקודת הקצה של AWS Client VPN, מגיע לתת-הרשת הפרטית, והכול נראה תקין. המחשב השולחני באותה LAN לא מגיע לשום דבר, למרות שגם למארח ה-Linux יש ממשק גשר ושתי המכונות נמצאות על אותו כבל. שום דבר לא מוגדר שגוי במנהרה; החלק החסר הוא ניתוב, והגשר הוא עקבות שווא.
הרחבת הפעלה של Client VPN אל LAN היא תפקיד שער. זה אינו מקטע Ethernet הנמתח אל תוך שירות מנוהל.
המארח עובד וה-LAN לא
לממשק המנהרה במחשב ה-Linux יש כתובת בתוך ה-CIDR של לקוח Client VPN, ונקודת הקצה דחפה נתיבים עבור טווחי ה-VPC. בקשה שנעשית במחשב הזה היא תעבורה שנוצרת מקומית: היא בוחרת נתיב, יוצאת דרך המנהרה ומקבלת תשובה. הנתיב הזה אינו נוגע בקוד ההעברה, בממשק ה-LAN או בכלל חומת אש שמסדיר מעבר.
תעבורה מהתקן LAN אחר היא זרימה שונה. היא מגיעה לממשק ה-LAN, זקוקה לנתיב שמצביע אל המנהרה, זקוקה להעברה מופעלת, זקוקה לחומת אש שמתירה אותה, וזקוקה לכך שהתשובה תחזור דרך אותו מארח. ארבעה תנאים, ובחינת המחשב הנייד שעובדת אינה מוכיחה אף אחד מהם. מהשולחני התקלה נראית מוזרה: המנהרה פעילה, האישורים תקפים, והיעד פשוט אינו עונה לעולם. הפגם מקומי בנתיב ההעברה של השער, לא בשירות.
לא כל לקוח יכול להיות שער
AWS מציינת שאפליקציית השולחן שלה ל-Client VPN אינה תומכת בהעברת IP, ושקוחות אחרים עשויים לתמוך. ההגבלה הזו קובעת את הארכיטקטורה לפני שנכתבת פקודה כלשהי. אם הלקוח היחיד הזמין הוא אפליקציית השולחן הרשמית, שער Linux שמעביר עבור ה-LAN אינו תצורה שאפשר להשלים, ושום כמות של masquerading לא תשנה זאת.
גם לקוח התחליף חייב להתאים לשיטת האימות של נקודת הקצה ולמדיניות שאתם מתכוונים לאכוף. נקודות קצה מבוססות תעודות, ספרייה ו-SAML אינן מקבלות אותן תצורות לקוח, ולקוח צד שלישי שמאמת אך מתעלם מהנתיבים שנדחפו אינו שיפור.
התייחסו לבחירת הלקוח כחלק מסקירת התכנון. היא קובעת אם דפוס העברת ה-LAN זמין בכלל, והיא קובעת איזו זהות נקודת הקצה רואה עבור כל התקן מאחורי השער. תעדו את הלקוח ואת תצורת נקודת הקצה שמולה נבדק. החלפת לקוח כעבור חצי שנה עשויה להסיר בשקט את היכולת שהתכנון הניח.
נתבו את ה-LAN אל המנהרה ותרגמו אותו
כשלקוח נתמך נמצא במקום, השאר הוא עבודת שער רגילה. התקני ה-LAN זקוקים לנתיב עבור טווח ה-VPC שמצביע אל מארח ה-Linux, והמארח זקוק להעברה מופעלת. אם אתם רוצים שה-VPC יראה את התעבורה כלקוח המחובר ולא ככתובת LAN שרירותית, תרגמו את המקור ביציאה.
LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16
iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADEהגבילו את הכלל לממשק המנהרה ולטווח ה-VPC, כמו למעלה, במקום לבצע masquerading לכל מה שהמארח מעביר. הכלל הצר יותר קל לניתוח, והוא אינו משנה בשקט תעבורה שהייתה אמורה לשמור על כתובת המקור המקורית שלה.
תנו לנתיב ה-LAN להגיע אוטומטית אם אפשר: אפשרות DHCP, הודעת נתב או נתיב סטטי שנדחף על ידי מה שמנהל את ה-LAN. נתיב שקיים רק במכונת בדיקה אחת יגרום לתכנון להיראות שבור ברגע שמישהו אחר ינסה אותו.
גם לתשובה דרוש נתיב
לאחר שהבקשה מגיעה ל-VPC, התשובה חייבת לחזור דרך אותם מצבי תרגום ולמצוא את נתיב ה-LAN בשער. החלק הזה בדרך כלל עובד כשכלל ה-masquerade במקום, משום שהמיפוי חי במארח שביצע אותו. הוא נשבר כשבצד ה-VPC יש נתיב ששולח את התשובה למקום אחר, ולכן גם נתיב ה-CIDR של הלקוח וגם שיוך תת-הרשת בנקודת הקצה חשובים.
הסתכלו על המונים, לא רק על ה-ping. כלל masquerade עם אפס מנות אומר לכם שהבקשה מעולם לא הגיעה לממשק המנהרה, מה שמצביע חזרה על נתיב ה-LAN או על טבלת הניתוב של הלקוח עצמו. כלל עם מנות אך בלי תשובות מצביע על צד ה-VPC, על כללי ההרשאה או על קבוצת אבטחה שאינה מקבלת את המקור המתורגם. קראו את שני הכיוונים לפני שמשנים משהו, כי מונה שגדל רק בצד אחד הוא נתיב חד-סטרי ולא נתיב איטי.
זכרו שנקודת הקצה היא שירות מנוהל. אין קובץ תצורת שרת לערוך ואין הנחיית client-config להוסיף, ולכן הוראות שנכתבו לשרת OpenVPN בניהול עצמי עם נתיבי תת-רשת לקוח מותאמים אינן עוברות. ב-AWS המנופים הם שיוך תת-רשת, כללי הרשאה וטבלאות הניתוב של ה-VPC.
זהות משותפת היא החלק שהמדיניות חייבת לענות עליו
כל התקן מאחורי השער משתמש בהפעלת ה-VPN של השער. כללי ההרשאה של נקודת הקצה מעניקים גישה למשתמש או לקבוצה, ומנקודת המבט של השירות יש בדיוק משתמש אחד בהפעלה הזו. העברה מקומית אינה מכפילה את הזהות הזו לאימות לכל התקן, והיא אינה מרחיבה בדיקות מצב התקן אל המדפסת שבפינה.
זה עשוי להיות מקובל, או שזו הסיבה שהתכנון נדחה. זה תלוי במה שמשאבי ה-VPC מניחים לגבי מי שמתקשר. זהות משותפת שמתאימה למודל ההרשאה היא בסדר; כזו שהופכת בשקט הפעלה מאומתת אחת לגישה לכל ה-LAN היא ממצא שמחכה להיכתב.
אם הדרישה היא באמת לחבר אתר שלם ל-VPC, השוו תכנון אתר-לאתר נתמך לפני הרחבת לקוח גישה מרחוק. הסמנטיקה שונה, והפעלת לקוח עם NAT היא תחליף גרוע לקישור אתר כאשר ה-VPC צריך ליזום חיבורים אל ה-LAN.
החליטו על הלקוח, הנתיב, התרגום וסיפור הזהות בסדר הזה. כל אחד מגביל את הבא, והסדר מסביר מדוע המארח עובד בעוד ה-LAN אינו עובד.