Google API VPN-en át: a VIP-et irányítsd, ne csak az alhálózatot

Jelentkezz be SSH-val a helyi szerverre, hozd fel az alagutat, és a privát VM válaszol; aztán a Google API felé indított első hívás útvonal nélkül meghiúsul. A VM alhálózata és az API VIP-jei különböző célok, ezért az egyikhez tartozó útvonal nem választja ki a másikat. Három feltételnek kell teljesülnie ahhoz, hogy egy privát API-hívás működjön. Az API-nevet VIP-vé kell feloldani, a VIP-előtagot az alagúton keresztül hirdetni kell, és a VPC-nek tudnia kell, hogyan küldje vissza a választ. A ping ezekről semmit nem mond, és egy működő SSH-munkamenet sem az alhálózatban lévő géppel.

Az API VIP-jei külön célok

A Google dedikált VIP-címeket tesz közzé a helyi hálózatból induló API-hozzáféréshez, és ezeket a címeket kell a DNS-nek visszaadnia az API-nevekhez. Mindkettő kis előtag, és egyik sem RFC 1918-es tartomány:

A nyilvánosnak látszó címek nem jelentik azt, hogy az útvonalnak el kell hagynia az alagutat a hétköznapi internet felé. Az előtagok azért léteznek, hogy a helyi ügyfél támogatott úton érje el a Google előtereit, ne egy önkényes kimeneti ponton. Célokként kezeld őket, amelyek az alagúthoz tartoznak, nem vizsgálandó hosztként. Az internetes kimenetre írt tűzfal-szabály általában eldobja őket, és ez a gyakori oka annak, hogy egy hívás még az indulás előtt meghiúsul.

A DNS dönti el, melyik végpontot éred el

Irányítsd a helyi feloldót a kiválasztott végponthoz dokumentált Google-rekordokra, hogy az alkalmazás által igényelt nevek ezzel a VIP-pel válaszoljanak. Önmagában a googleapis.com nem leltár: a csomagregisztereknek, a konténerregisztereknek és a migrációs összekötőknek saját dokumentált nevük van. A korlátozott VIP sem hordoz minden szolgáltatást, ezért egy feloldódó név még mindig nem támogatott lehet. Jegyezd fel azokat a domaineket, amelyeket az alkalmazás ténylegesen felkeres, mielőtt hozzányúlsz a feloldóhoz.

Egy VPC-beli VM-cím kitalálása egy szolgáltatásnév helyett nem javítás, és általában elrejti a DNS-hiányt, amíg egy másik ügyfél meg nem hibázik.

Hirdesd a VIP-előtagot, tartsd meg a többit

BGP-alapú kapcsolatnál a Cloud Routernek hirdetnie kell a kiválasztott VIP-előtagot, hogy a helyi router a szándékolt munkameneten keresztül megtanulja ezt a tartományt. A csak VPC-alhálózatok hirdetése nem adja hozzá ezt a tartományt, és a helyi router továbbra is az alapértelmezett útját használja ezekhez a címekhez. Az útválasztási táblában lévő előtag az egyetlen bizonyíték arra, hogy a hirdetmény átjutott a munkameneten.

Tartsd meg a meglévő hirdetményeket, miközben hozzáadod az újat, mert a router szintű és a peer szintű beállítások hatóköre eltér, és a készlet cseréje visszavonhat olyan hálózatokat, amelyek már működtek. Ezután minden munkameneten ellenőrizd a tényleges hirdetményt, ne a router egészén. A hiányzó előtag és a visszavont előtag a helyi oldalról egyformán néz ki, ezért éppen a munkamenet nézete választja el a kihagyást a regressziótól.

A VPC oldalának saját útvonalra és visszaútra van szüksége

A VPC-n belül a VIP-útvonalnak az alapértelmezett internet-átjárót kell következő ugrásként használnia, és a név ellenére ez a forgalom a Google hálózatán belül marad. A VPC-nek a VPN-en keresztül visszaútra is szüksége van a helyi forráshoz, ami külön objektum a hirdetett előtagtól. Vedd figyelembe a dokumentált regionális útválasztási követelményeket, amikor az alagút és az ügyfél nem ugyanabban a régióban van.

A visszautat önállóan ellenőrizd, mert egy működő kérésirány elrejthet egy törött válaszirányt. Két irány, két útvonal, és mindegyik a saját tünetével hibázik.

Teszteld a kérést, aztán olvasd el az elutasítást

Az ICMP-visszhang nem kap választ ezektől a VIP-ektől, ezért a sikertelen ping semmit nem bizonyít, a sikeres pedig nagyon keveset. A tényleges ügyféltől vizsgáld meg a név válaszát és a kiválasztott útvonalat, majd küldj engedélyezett HTTPS-kérést a számodra fontos szolgáltatáshoz. Ha a kérés eléri a szolgáltatást és elutasítják, nézd meg a hitelesítő adatokat, az IAM-et és a vonatkozó szolgáltatásperem-szabályzatot.

A privát útválasztás nem ad API-engedélyt, és nem változtatja meg, mit tehet az identitás. Az átvitel sikere és az engedélyezett válasz külön eredmények, és mindkettőre szükség van. Tartsd az IPv6 útvonalat is kifejezettként, mert az IPv4-előtagok beállítása semmit nem mond az IPv6-ot előnyben részesítő ügyfélről.

A Google útmutatója a Private Google Access helyi hálózati változatáról együtt tárgyalja a DNS-rekordokat és az útválasztási követelményeket, ezért a feloldó és a hirdetmény beállításait ehhez hasonlítsd, ne egy fórumbejegyzéshez. Ezután futtasd újra ugyanazt a kérést, és jegyezd fel a választ és az útvonalat ugyanabban a jegyben.