API Google prin VPN: rutează VIP-ul, nu doar subrețeaua

Conectează-te prin SSH la serverul local, ridică tunelul și VM-ul privat răspunde; apoi primul apel către un API Google eșuează fără rută. Subrețeaua VM-ului și adresele VIP ale API-ului sunt destinații diferite, așa că o rută pentru una nu o selectează pe cealaltă. Trei condiții trebuie să fie valabile înainte ca un apel API privat să funcționeze. Numele API-ului trebuie să se rezolve într-un VIP, prefixul VIP trebuie anunțat prin tunel, iar VPC-ul trebuie să știe cum să trimită răspunsul înapoi. Un ping nu îți spune nimic din toate acestea, iar o sesiune SSH funcțională către o mașină din subrețea nici atât.

Adresele VIP ale API-ului sunt destinații separate

Google publică VIP-uri dedicate pentru accesul la API din rețeaua locală, iar acelea sunt adresele pe care DNS-ul tău trebuie să le returneze pentru numele API-ului. Ambele sunt prefixe mici și niciunul nu este spațiu RFC 1918:

Adresele care par publice nu înseamnă că ruta trebuie să părăsească tunelul pentru internetul obișnuit. Prefixele există pentru ca un client local să ajungă la front-end-urile Google printr-o cale suportată, nu printr-un punct de ieșire arbitrar. Tratează-le ca destinații care aparțin tunelului, nu ca gazde de sondat. O regulă de firewall scrisă pentru ieșirea în internet le aruncă de obicei, și acesta este un motiv frecvent pentru care un apel eșuează înainte de a începe.

DNS-ul decide la ce endpoint ajungi

Îndreaptă resolverul local către înregistrările pe care Google le documentează pentru endpointul ales, astfel încât numele de care are nevoie aplicația să răspundă cu acel VIP. Doar googleapis.com nu este un inventar: registrele de pachete, registrele de containere și conectorii de migrare au propriile nume documentate. Nici VIP-ul restricționat nu transportă fiecare serviciu, așa că un nume care se rezolvă poate rămâne nesuportat. Notează domeniile cu care aplicația contactează efectiv înainte de a atinge resolverul.

Ghicirea unei adrese de VM din VPC în locul unui nume de serviciu nu este o remediere și de obicei ascunde golul din DNS până când eșuează alt client.

Anunță prefixul VIP, păstrează restul

Cu o conexiune bazată pe BGP, Cloud Router trebuie să anunțe prefixul VIP ales pentru ca routerul local să învețe intervalul prin sesiunea dorită. Anunțarea doar a subrețelelor VPC nu adaugă intervalul, iar routerul local continuă să folosească calea implicită pentru acele adrese. Prefixul din tabela de rutare este singura dovadă că anunțul a trecut sesiunea.

Păstrează anunțurile existente în timp ce îl adaugi pe cel nou, pentru că opțiunile la nivel de router și la nivel de peer au acoperire diferită, iar schimbarea setului poate retrage rețele care funcționau deja. Apoi verifică anunțul efectiv pe fiecare sesiune, nu pe router în ansamblu. Un prefix lipsă și un prefix retras arată la fel din partea locală, așa că vizualizarea sesiunii este cea care separă o omisiune de o regresie.

Partea VPC are nevoie de propria rută și de calea de întoarcere

În interiorul VPC-ului, calea VIP trebuie să folosească gateway-ul de internet implicit ca următor salt, iar, în ciuda numelui, acel trafic rămâne în rețeaua Google. VPC-ul are nevoie și de o rută înapoi la sursa locală prin VPN, iar acesta este un obiect separat de prefixul anunțat. Ia în calcul cerințele regionale de rutare documentate când tunelul și clientul nu sunt în aceeași regiune.

Verifică calea de întoarcere independent, pentru că o direcție de cerere funcțională poate ascunde o direcție de răspuns defectă. Două direcții, două rute, și fiecare eșuează cu propriul simptom.

Testează cererea, apoi citește respingerea

Eco-ul ICMP nu primește răspuns de la aceste VIP-uri, așa că un ping eșuat nu dovedește nimic, iar unul reușit foarte puțin. Din clientul real, examinează răspunsul numelui și ruta selectată, apoi fă o cerere HTTPS autorizată către serviciul care te interesează. Dacă cererea ajunge la serviciu și este respinsă, uită-te la acreditări, IAM și orice politică de perimetru de serviciu aplicabilă.

Rutarea privată nu acordă autorizare API și nu schimbă ce are voie să facă identitatea. Succesul transportului și un răspuns autorizat sunt rezultate separate, și ai nevoie de ambele. Păstrează explicită și calea IPv6, pentru că a configura prefixele IPv4 nu spune nimic despre un client care preferă IPv6.

Ghidul Google despre Private Google Access din rețeaua locală acoperă împreună înregistrările DNS și cerințele de rutare, așa că compară setările de resolver și de anunțare cu el, nu cu o postare de forum. Apoi rulează din nou aceeași cerere și notează răspunsul și ruta în același tichet.