מדוע ה-VM שלך ב-GCP אינו יכול להשיב לבריכת IPv6 של OpenVPN

לקוח ה-VPN שלך על IPv6 מגיע לעומס העבודה, עומס העבודה משיב אל תוך המנהרה, והתשובה לעולם לא מגיעה. האינסטינקט הראשון הוא להאשים את חומת האש או את המנהרה, ובדרך כלל אף אחד מהם אינו אשם. כתובת ש-OpenVPN מקצה היא רשת פנימית שקיימת רק בתוך המנהרה; ל-Google Cloud אין מושג ש-fd42:90::/64 אמור לשבת מאחורי VM מסוים עד שתספרו לה.

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

הבריכה היא רשת פנימית, לא תת-רשת

OpenVPN יכול להקצות כתובות IPv6 מטווח שתבחרו, והטווח הזה הוא בדיה ששני קצות המנהרה מסכימים עליה. היא אינה תת-רשת של Google Cloud, היא אינה מופיעה ברשימת תת-הרשתות של ה-VPC, וממשק הרשת של ה-VM אינו מקבל את הכתובות האלה. לכן עומס עבודה שמשיב ללקוח שולח מנה לכתובת שהרשת מחשיבה כבלתי ניתנת לניתוב.

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

כתובת מקומית ייחודית כמו fd42:90::/64 היא בחירה סבירה לרשת הפנימית הזו. הקידומת גם מזכירה שהתכנון פרטי מעצם הגדרתו. שום דבר בבריכת ULA לא הופך אותה למקור חוקי באינטרנט הציבורי.

תנו ל-VPC יעד וקפיצה הבאה

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

כתובת קפיצה הבאה חייבת להיות הכתובת שמוקצית בפועל לממשק הענן של המופע. כתובת המנהרה הפנימית של ה-VM אינה הכתובת הזו. שימוש בה בכל זאת יוצר נתיב שמתקין בצורה נקייה ולעולם אינו תואם מנה. קראו את רשימת הממשקים לפני שתכתבו את הנתיב.

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ההעברה חייבת להיות מופעלת פעמיים

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

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

אמרו ל-OpenVPN מי הבעלים של מה

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

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

השאירו את יציאת האינטרנט מחוץ לתכנון הזה

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

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