גישה מרחוק של מפתחים ל-VPC של Google Cloud: בחרו את המסלול

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

רשמו את היעדים והפרוטוקולים

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

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

IAP לכמה שירותי TCP

העברת TCP ב-Identity-Aware Proxy נותנת מנהרה מאומתת למשאבי VM מתאימים בלי לחשוף את השירות לאינטרנט. הצורה היומיומית היא gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, וניתן להעביר פורט אחד מקומית עם gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

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

העברת TCP ב-IAP אינה VPN של שכבה שלוש. היא נושאת TCP ליעד נבחר, לא תעבורת IP שרירותית או UDP, והיא אינה מתאימה כאשר יישום צריך DNS פרטי על פני שירותים רבים.

VPN לגישה מרחוק לטווח הגעה רחב יותר

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

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

Cloud VPN הוא שער אתר, לא פרופיל מחשב נייד

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

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

אמתו ותעדו

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

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