AWS Site-to-Site VPN: חוץ, פנים וקידומת ה-LAN
שלושה תפקידי כתובת מתבלבלים ב-VPN אחד של AWS: עמיתים חיצוניים, קישור ה-/30 הפנימי וקידומות ה-LAN המוגנות. קראו אותם בתצורה שהורדה.
רוב הטעויות ב-AWS Site-to-Site VPN הן טעויות כתובת, והן נעשות לפני שאפילו חבילה אחת זזה. כתובות החוץ של המנהרה מגיעות לעמיתי IPsec, כתובות הפנים יוצרות את קישור הניתוב ביניהן, והקידומות המוגנות הן מה שהקישור הזה נועד לו. העתיקו תפקיד אחד לאחר והמנהרה עולה בעוד ששום דבר לא מנותב. הנה רצף קריאה-בדיקה-הגדרה שאני משתמש בו בשער לקוח BGP, כשהערכים נלקחים מתצורת ההתקן שהורדה ולא מהזיכרון.
שלושה תפקידי כתובת, מנהרה אחת
כתובות החוץ פומביות ושייכות לעמיתי IPsec: אחת לכל מנהרה בצד AWS, וזהות הנגישה של שער הלקוח בצד שלכם, מותאמת לכל סידור NAT שבאמת יש לכם. כתובות הפנים פרטיות ושייכות לקישור הלוגי, שאותו AWS מתעד כ-/30 הנלקח מ-169.254.0.0/16. הקידומות המוגנות הן רשתות ה-VPC, המקומיות או המעבר שאתם מנתבים ומכריזים מעל אותו קישור.
הקצאת קידומת LAN ככתובת ממשק המנהרה היא הצורה הקלאסית של הטעות הזו. הממשק נראה מוגדר, ה-LAN אינו מוכרז, ולצד השני אין נתיב אליו. המנהרה יכולה אפילו לעבור את הפינג הפנימי של עצמה בעוד כל שם יישום מגיע לפסק זמן. מסמך אפשרויות המנהרה מפרט את מגבלות ה-CIDR הפנימי, כולל טווח הכתובות שממנו הוא חייב לבוא.
קראו את הערכים מהתצורה שהורדה
הורידו את התצורה עבור דגם ההתקן הספציפי שלכם מהחיבור, ואז התייחסו לטבלת הכתובות שלה כמקור האמת. הקונסולה מציגה את אותם ערכים לכל מנהרה: IP חוץ, CIDR פנים וכתובת עמית ה-BGP בצד AWS. שתי המנהרות הן אובייקטים נפרדים עם נקודות קצה חיצוניות נפרדות ו-/30 פנימיים נפרדים, אף ששתיהן נושאות את אותן רשתות מוגנות.
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
--query 'CustomerGateways[0].[IpAddress,BgpAsn]'אם הקובץ שהורד והקונסולה החיה אינם תואמים, הקובץ מיושן. הורידו מחדש במקום לערוך כתובות ביד, כי אי-התאמה בין הזוג הפנימי לשכן המוגדר של העמית היא כשל BGP שקט.
בנו את הקישור עם הכתובת הנכונה עליו
בשער Linux המנהרה היא ממשק VTI או XFRM, וה-/30 הפנימי יושב על אותו ממשק. שתי מנהרות משמעותן שני ממשקים ושני שכני BGP, אחד לכל נקודת קצה של AWS. המוסכמה ש-AWS מדפיסה בתצורת ההתקן שהורדה שמה את השער הפרטי הווירטואלי בכתובת הראשונה של כל /30 פנימי ואת שער הלקוח שלכם בשנייה, כך שאתם לוקחים את הכתובת הגבוהה ועושים עמיתות עם הנמוכה. שום דבר כאן לא צריך כתובת LAN.
ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400אם הקובץ של דגם ההתקן שלכם מדפיס את הזיווג ההפוך, השתמשו במספרים שלו ושמרו על הכלל: הכתובת על הממשק היא שלכם, כתובת העמית שייכת ל-AWS. עשייה הפוכה מייצרת מנהרה שלעולם לא מגיעה ל-Established, כי השכן שהגדרתם הוא הכתובת שכבר מחזיק הממשק שלכם.
שמרו על הסימון ומפתח ה-VTI מיושרים עם מה שדמון ה-IKE משתמש בו כדי לקשור SA בן לממשק, אחרת תעבורה מגיעה למנהרה בלי ממשק לנחות עליו. בדקו את ה-MTU מול הנתיב ומול ההגדרות של דמון ה-IKE עצמו במקום להעתיק מספר מאתר אחר.
אמתו BGP לפני שאתם מאמתים נתיבים
עליית IPsec מוכיחה שהעמיתים מסכימים על אסוציאציית אבטחה ושום דבר אחר. הפעלת BGP היא משא ומתן נפרד מעל הקישור הפנימי, אז קראו את מצב השכן ואת מוני הקידומות, ואז השוו אותם למה שהתכוונתם להכריז.
ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'מצב Established עם אפס קידומות שהתקבלו הוא בעיית מדיניות או הכרזה, לא בעיית מנהרה. חזרו על הבדיקה כולה במנהרה השנייה; מנהרה ראשונה שעובדת אומרת לכם שהכתובות סבירות, לא שהמנהרה השנייה הוגדרה בכלל.
עקבו אחרי חבילה מנותבת ואז עצרו
כשהפעלת ה-BGP נושאת את הקידומות, בדקו את הנתיב בשני הכיוונים מהשער: כתובת מקור, הקפיצה הבאה, ומדיניות האבטחה שמתירה את התעבורה. הפעלת BGP יכולה להיות למעלה בעוד הקידומת הספציפית שהיישום שלכם צריך מסוננת, מסוכמת או מפנה לממשק הלא נכון.
Reachability Analyzer הוא הכלי בצד AWS שלוקח מקור, יעד ונתיב, ומדווח איזה רכיב בתצורה נתמכת חסם אותו. השתמשו בו כדי לבדוק את הנתיב מה-VPC לכתובת שער הלקוח שלכם, לא ממארח יישום. הוא מנתח תצורה ואינו שולח חבילה דרך חומת אש מקומית, אז שמרו את פסק הדין שלו נפרד מהמונים של הממשק שלכם ומלכידות החבילות.
רשמו את הזוג החיצוני, את ה-/30 הפנימי ואת הקידומות המוכרזות לכל מנהרה בטבלה אחת. הטבלה הזו היא מה שהופך את השינוי הבא לניתן לבדיקה.