API של Google דרך VPN: נתבו את ה-VIP, לא רק את תת-הרשת
מסלול לתת-רשת ב-VPC לא בוחר את כתובות ה-VIP של ה-API. פתרו את השמות הנכונים, פרסמו את קידומת ה-VIP, שמרו על נתיב החזרה ב-VPC, ואז בדקו HTTPS.
התחברו ב-SSH לשרת המקומי, העלו את המנהרה וה-VM הפרטי עונה; אז הקריאה הראשונה ל-API של Google נכשלת בלי מסלול. תת-הרשת של ה-VM וכתובות ה-VIP של ה-API הן יעדים שונים, ולכן מסלול לאחת אינו בוחר את השנייה. שלושה תנאים חייבים להתקיים לפני שקריאת API פרטית תעבוד. שם ה-API חייב להיפתר ל-VIP, קידומת ה-VIP חייבת להיות מוכרזת דרך המנהרה, וה-VPC חייב לדעת איך לשלוח את התשובה בחזרה. פינג לא אומר לכם דבר מזה, וגם לא הפעלה תקינה של SSH למכונה בתת-הרשת.
כתובות ה-VIP של ה-API הן יעדים נפרדים
Google מפרסמת כתובות VIP ייעודיות לגישה ל-API מהרשת המקומית, ואלה הכתובות שה-DNS שלכם חייב להחזיר עבור שמות ה-API. שתיהן קידומות קטנות ואף אחת מהן אינה מרחב RFC 1918:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
כתובות שנראות ציבוריות אינן אומרות שהמסלול צריך לעזוב את המנהרה עבור האינטרנט הרגיל. הקידומות קיימות כדי שלקוח מקומי יגיע לחזיתות של Google בנתיב נתמך ולא בנקודת יציאה שרירותית. התייחסו אליהן כיעדים ששייכים למנהרה, לא כמארחים לבדיקה. כלל חומת אש שנכתב ליציאה לאינטרנט בדרך כלל מפיל אותן, וזו סיבה נפוצה לכך שקריאה נכשלת לפני שהיא מתחילה.
ה-DNS קובע לאיזו נקודת קצה תגיעו
כוונו את הפותר המקומי לרשומות ש-Google מתעדת עבור נקודת הקצה שנבחרה, כך שהשמות שהאפליקציה צריכה יענו בכתובת ה-VIP הזו. עצם googleapis.com אינו מלאי: לרישומי חבילות, לרישומי מכולות ולמחברי הגירה יש שמות מתועדים משלהם. גם כתובת ה-VIP המוגבלת אינה נושאת כל שירות, ולכן שם שנפתר עדיין עשוי להיות לא נתמך. רשמו את התחומים שהאפליקציה באמת פונה אליהם לפני שאתם נוגעים בפותר.
ניחוש כתובת VM ב-VPC במקום שם שירות אינו תיקון, והוא בדרך כלל מסתיר את פער ה-DNS עד שלקוח אחר נכשל.
פרסמו את קידומת ה-VIP, שמרו על השאר
בחיבור מבוסס BGP, ה-Cloud Router חייב לפרסם את קידומת ה-VIP שנבחרה כדי שהנתב המקומי ילמד את הטווח דרך הסשן המיועד. פרסום תת-הרשתות של ה-VPC בלבד אינו מוסיף את הטווח, והנתב המקומי ממשיך להשתמש בנתיב ברירת המחדל שלו לכתובות האלה. הקידומת בטבלת הניתוב היא ההוכחה היחידה שהפרסום חצה את הסשן.
שמרו על הפרסומים הקיימים בזמן שאתם מוסיפים את החדש, כי לאפשרויות ברמת הנתב וברמת העמית יש טווח שונה, והחלפת הקבוצה עלולה למשוך רשתות שכבר עבדו. לאחר מכן בדקו את הפרסום האפקטיבי בכל סשן ולא בנתב כולו. קידומת חסרה וקידומת שנמשכה נראות זהות מהצד המקומי, ולכן תצוגת הסשן היא מה שמפריד בין השמטה לרגרסיה.
לצד ה-VPC דרושים מסלול ונתיב חזרה משלו
בתוך ה-VPC, נתיב ה-VIP חייב להשתמש בשער האינטרנט המוגדר כברירת מחדל כקפיצה הבאה, ולמרות השם התעבורה הזו נשארת בתוך הרשת של Google. ה-VPC צריך גם מסלול חזרה למקור המקומי דרך ה-VPN, וזה אובייקט נפרד מהקידומת המוכרזת. התחשבו בדרישות הניתוב האזוריות המתועדות כאשר המנהרה והלקוח אינם באותו אזור.
בדקו את נתיב החזרה בנפרד, כי כיוון בקשה עובד יכול להסתיר כיוון תשובה שבור. שני כיוונים, שני מסלולים, וכל אחד נכשל עם התסמין שלו.
בדקו את הבקשה, ואז קראו את הדחייה
הד ICMP אינו מקבל תשובה מכתובות ה-VIP האלה, ולכן פינג שנכשל אינו מוכיח דבר ופינג שמצליח מוכיח מעט מאוד. מהלקוח האמיתי, בדקו את תשובת השם ואת המסלול שנבחר, ואז שלחו בקשת HTTPS מורשית לשירות שמעניין אתכם. אם הבקשה מגיעה לשירות והוא דוחה אותה, בדקו את פרטי ההתחברות, IAM וכל מדיניות היקף שירות שחלה.
ניתוב פרטי אינו מעניק הרשאת API ואינו משנה מה הזהות רשאית לעשות. הצלחת התעבורה ותשובה מורשית הן תוצאות נפרדות, וצריך את שתיהן. שמרו גם על נתיב IPv6 מפורש, כי הגדרת קידומות IPv4 אינה אומרת דבר על לקוח שמעדיף IPv6.
המדריך של Google ל-Private Google Access מהרשת המקומית מכסה יחד את רשומות ה-DNS ואת דרישות הניתוב, ולכן השוו את הגדרות הפותר והפרסום שלכם אליו ולא לפוסט בפורום. לאחר מכן הריצו שוב את אותה בקשה ורשמו את התשובה ואת המסלול באותו כרטיס.