מנהרה מלאה של Access Server ב-EC2: מדוע תיבת סימון אחת אינה מספיקה

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

מה הבדיקה באמת שולטת בו

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

בדקו את הערך הנוכחי עם aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck לפני שתשנו דבר. אם תשנו אותו בקונסולה, שנו אותו מפני שהמופע מעביר עבור אחרים, לא מפני שלקוח לא מגיע לאינטרנט.

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

ב-Access Server 3 פתחו את Access Controls ומצאו את הקטע Internet Access and DNS. בחירת Internet Gateway מציעה מנהרה מלאה או מנהרה מפוצלת; מנהרה מלאה מורה ללקוח לנתב את תעבורת ברירת המחדל שלו אל תוך ה-VPN, ומנהרה מפוצלת משאירה את תעבורת האינטרנט בנתיב המקומי של הלקוח. שמרו והחילו דרך זרימת העבודה של המוצר, ואז חברו מחדש לקוח בדיקה, מפני שהמדיניות נמסרת בזמן החיבור.

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

עקבו אחר המנה אחרי המנהרה

לאחר שהלקוח שולח תעבורת אינטרנט אל המנהרה, השרת חייב להעביר אותה ובדרך כלל לתרגם אותה. Access Server מנהל את כללי ה-NAT והניתוב שלו עצמו, ולכן קראו את התצורה האפקטיבית במקום להוסיף כללי Community OpenVPN לקבצים שנוצרו; כללים לא מנוהלים נדרסים או מתנגשים בעדכון המוצר הבא. sudo iptables -t nat -L -n -v או המקבילה ב-nftables מראה מה באמת מתורגם.

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

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

הפרידו בין יציאת IP ל-DNS

בדקו תחילה כתובת מפורשת ואחר כך שם, מאותה אפליקציית לקוח. אם curl -4 https://checkip.amazonaws.com מחזיר כתובת ציבורית אך שמות מארחים נכשלים, המנהרה ונתיב ה-NAT עובדים והבעיה היא DNS: הפותר שנדחף, מצב הפותר בלקוח, או קבוצת אבטחה שחוסמת את הפותר. הגדרות ה-DNS של Access Server נמצאות באותו אזור Internet Access, אך הן עוברות בנתיב קוד אחר.

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

אל תתנו לתיבת סימון אחת לסגור את החקירה

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

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