הפעלת העברת IP בשער GCE VPN קיים

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

מה הדגל מתיר, ומה לא

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

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

קראו את המאפיין הנוכחי

בדקו את ההגדרה לפני שמשנים משהו, עם describe לקריאה בלבד מול המופע, הפרויקט והאזור המיועדים:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

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

עדכנו את המופע הקיים

ההליך של Google לעדכון מאפייני מופע מייצא את המשאב הנוכחי, משנה את המאפיין ומגיש את התוצאה. זהו תהליך עבודה שונה מהדגל --can-ip-forward בזמן היצירה, וזה התהליך שעובד על מכונה פועלת.

ייצאו תחילה את ההגדרה לקובץ מקומי, ושמרו עותק ללא שינוי להשוואה:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

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

canIpForward: true

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

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

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

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

החילו את הקובץ הנבדק עם מגבלת refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

האורח עדיין צריך לנתב את המנה

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

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

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

בשער Linux, העברה בקרנל היא חלק מתצורת האורח. להתקן pfSense יש מקבילה משלו, והעתקת פקודת sysctl של Linux לתוכו אינה הצעד המתאים.

אמתו מהלקוח שזקוק לגישה

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

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

סדר העבודה: קראו את המאפיין, ייצאו וערכו שורה אחת, אמתו עם NO_EFFECT, החילו עם REFRESH, אשרו שהאורח מעביר, ואז בדקו מלקוח.