AWS Client VPN מחובר אבל אין גישה לאינטרנט: בדיקת מסלולים

AWS Client VPN מחובר בלי גישה לאינטרנט? בדקו את מסלולי הלקוח, הרשאת נקודת הקצה, היציאה מהתת-רשת ו-DNS בסדר הזה.

אתם מחוברים לנקודת הקצה של AWS Client VPN, התת-רשת הפרטית עונה, ובכל זאת כל עמוד ציבורי מסתיים בפסק זמן. השילוב הזה מצמצם את הבעיה לאחד משלושה אובייקטים בצד המנוהל: המסלול שהלקוח מתקין, המסלול של נקודת הקצה יחד עם כלל ההרשאה שלה, או הקפיצה הבאה של התת-רשת המשויכת. אני בודק אותם בסדר הזה, כי כל כשל נראה אחרת מצד הלקוח. מדריך זה מכסה את נקודת הקצה המנוהלת המשויכת ל-VPC, לא שרת OpenVPN על מופע EC2 ולא חיבור Cloud WAN או Transit Gateway.

התחילו במה שהלקוח באמת מנתב

מצב מחובר מוכיח את הפעלת ה-TLS ואת הקצאת ה-CIDR ללקוח, ולא יותר מזה. שאלו את מערכת ההפעלה לאן תלך כתובת ציבורית כשהמנהרה פעילה. ב-Linux, ip route get 1.1.1.1 אמור לציין את ממשק המנהרה; ב-macOS, netstat -rn -f inet | head -5 מציג את רשומת ברירת המחדל; ב-Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 מדפיס את הממשק הנבחר ואת הקפיצה הבאה.

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

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

כאשר SplitTunnel הוא true, יעד ציבורי משתמש במנהרה רק אם נקודת הקצה מפרסמת מסלול שמכסה אותו, ולכן 0.0.0.0/0 חסר משאיר את התעבורה הזו בממשק המקומי. כאשר הוא false, הלקוח לוכד את התעבורה, אבל נקודת הקצה עדיין חייבת לנתב ולאשר אותה; אחרת מנות נכנסות למנהרה ונעצרות שם. חברו את הלקוח מחדש לאחר שינוי כל אחד מהשניים, כי מסלולים ושרתי DNS נמסרים בזמן החיבור ולקוח שרץ יכול לשמור על הסט הישן שלו.

קראו את מסלול נקודת הקצה ואת כלל ההרשאה בנפרד

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

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

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

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

כלל ל-CIDR של ה-VPC לא אומר דבר על 0.0.0.0/0. הוספת החלקים החסרים למנהרה מלאה משמעה מסלול אחד לכל תת-רשת משויכת בתוספת כלל הרשאה שתוכלו לבקר אחר כך:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

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

עקבו אחרי המנה אל מחוץ לתת-הרשת המשויכת

מסלול נקודת הקצה קובע ש-AWS מוסרת את המנה לאותה תת-רשת. הוא לא קובע את הקפיצה הבאה מעבר לה, שנמצאת בטבלת המסלולים של ה-VPC של התת-רשת עצמה:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

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

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

בחרו את השכבה הראשונה לפי התסמין במקום לשנות את כל השלוש בבת אחת:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

הפרידו כשל DNS ממסלול מת

פתרון שמות נכשל אחרת מהעברה, ומנהרה מלאה הופך את ההבדל לחשוב כי עכשיו מגיעים לפותר הנדחף דרך המנהרה. אם נקודת הקצה מגדירה שרתי DNS של ה-VPC, הכתובות שלהם זקוקות לכיסוי מסלול ולהרשאה כמו כל יעד אחר. שאלו את הפותר ישירות כדי לראות איזה כשל יש לכם: dig +short example.com @10.0.0.2, או nslookup example.com 10.0.0.2 ב-Windows.

כאשר URL מספרי עונה ובעל שם לא, הפסיקו לערוך את מסלול ברירת המחדל ועבדו על DNS. בקשה לכתובת IP לא מוכיחה דבר על מארח וירטואלי בעל שם והתעודה שלו, ולכן השאירו בדיקה אחת בעלת שם בבדיקה הסופית.

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

חזרו אחורה בצורה נקייה, ואז אמתו את נתיב היציאה

שני האובייקטים היו תוספתיים, ולכן החזרה אחורה היא מחיקה ולא תיקון:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

סיימו ברשימה קצרה והתייחסו לפריט האחרון כחלק מהשינוי ולא כתיעוד:

  • מסלול 0.0.0.0/0 אחד של נקודת הקצה לכל תת-רשת משויכת.
  • כלל הרשאה שמכסה 0.0.0.0/0 עבור הלקוחות שאתם רוצים לשרת.
  • מסלול ברירת מחדל של VPC שאינו במצב blackhole בכל תת-רשת משויכת.
  • יציאת קבוצת האבטחה של השיוך, בתוספת תעבורת החזרה של ACL.
  • כתובות הפותר מנותבות ומאושרות, מאומתות בבקשה בעלת שם.
  • חזרה אחורה מתועדת עבור המסלול והכלל.

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

מאמרים קשורים