Google-API VPN:n yli: reititä VIP, älä vain aliverkkoa
Reitti VPC:n aliverkkoon ei valitse API:n VIP-osoitteita. Ratkaise oikeat nimet, mainosta VIP-etuliite, pidä VPC:n paluureitti ja testaa sitten HTTPS.
Kirjaudu SSH:lla paikalliselle palvelimelle, nosta tunneli ja yksityinen VM vastaa; sitten ensimmäinen Google-API-kutsu epäonnistuu ilman reittiä. VM:n aliverkko ja API:n VIP-osoitteet ovat eri kohteita, joten reitti toiseen ei valitse toista. Kolmen ehdon on oltava voimassa, ennen kuin yksityinen API-kutsu voi toimia. API-nimen on ratkettava VIP-osoitteeksi, VIP-etuliite on mainostettava tunnelin yli ja VPC:n on tiedettävä, miten vastaus lähetetään takaisin. Ping ei kerro sinulle mitään siitä, eikä kerro toimiva SSH-istunto aliverkon koneeseenkaan.
API:n VIP-osoitteet ovat erillisiä kohteita
Google julkaisee erilliset VIP-osoitteet API-käyttöön paikallisverkosta, ja juuri ne osoitteet DNS:si on palautettava API-nimille. Molemmat ovat pieniä etuliitteitä, eikä kumpikaan ole RFC 1918 -avaruutta:
| 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 |
Julkisilta näyttävät osoitteet eivät tarkoita, että reitin pitäisi lähteä tunnelista tavalliseen internetiin. Etuliitteet ovat olemassa, jotta paikallinen asiakas voi tavoittaa Googlen etupäät tuetun polun kautta mielivaltaisen ulostulopisteen sijaan. Käsittele niitä tunneliin kuuluvina kohteina, älä tutkittavina isäntinä. Internetin ulostuloa varten kirjoitettu palomuurisääntö yleensä hylkää ne, ja se on tavallinen syy siihen, että kutsu epäonnistuu ennen kuin se alkaa.
DNS päättää, mihin päätepisteeseen päädyt
Osoita paikallinen resolver valitun päätepisteen osalta Googlen dokumentoimiin tietueisiin, jotta sovelluksen tarvitsemat nimet vastaavat kyseisellä VIP-osoitteella. Pelkkä googleapis.com ei ole luettelo: pakettirekistereillä, konttirekistereillä ja migraatiokonnektoreilla on omat dokumentoidut nimensä. Myöskään rajoitettu VIP ei kuljeta jokaista palvelua, joten ratkeava nimi voi silti olla tukematon. Kirjoita muistiin toimialueet, joihin sovellus todella ottaa yhteyttä, ennen kuin kosket resolveriin.
VPC:n VM-osoitteen arvaaminen palvelunimen korvikkeeksi ei ole korjaus, ja se yleensä piilottaa DNS:n aukon, kunnes jokin toinen asiakas epäonnistuu.
Mainosta VIP-etuliite, pidä loput
BGP-pohjaisessa yhteydessä Cloud Routerin on mainostettava valittu VIP-etuliite, jotta paikallinen reititin voi oppia kyseisen alueen aiottua istuntoa pitkin. Pelkkien VPC-aliverkkojen mainostaminen ei lisää kyseistä aluetta, ja paikallinen reititin jatkaa oletuspolkunsa käyttöä näille osoitteille. Reititystaulun etuliite on ainoa todiste siitä, että mainos ylitti istunnon.
Säilytä olemassa olevat mainokset, kun lisäät uuden, koska reititintason ja vastapään tason asetuksilla on eri kattavuus, ja joukon vaihtaminen voi vetää pois verkkoja, jotka jo toimivat. Tarkista sitten tehokas mainos jokaisessa istunnossa eikä reitittimessä kokonaisuutena. Puuttuva etuliite ja pois vedetty etuliite näyttävät paikalliselta puolelta samoilta, joten juuri istunnon näkymä erottaa laiminlyönnin regressiosta.
VPC:n puoli tarvitsee oman reittinsä ja paluupolkunsa
VPC:n sisällä VIP-polun on käytettävä oletusarvoista internet-yhdyskäytävää seuraavana hyppyynä, ja nimestään huolimatta tämä liikenne pysyy Googlen verkossa. VPC tarvitsee myös reitin takaisin paikalliseen lähteeseen VPN:n kautta, ja se on erillinen objekti mainostetusta etuliitteestä. Ota huomioon dokumentoidut alueelliset reititysvaatimukset, kun tunneli ja asiakas eivät ole samalla alueella.
Tarkista paluupolku itsenäisesti, koska toimiva pyyntösuunta voi peittää rikkinäisen vastaussuunnan. Kaksi suuntaa, kaksi reittiä, ja kumpikin epäonnistuu omalla oireellaan.
Testaa pyyntö ja lue sitten hylkäys
ICMP-kaiku ei saa vastausta näiltä VIP-osoitteilta, joten epäonnistunut ping ei todista mitään ja onnistunut hyvin vähän. Tarkista todellisesta asiakkaasta nimen vastaus ja valittu reitti ja tee sitten valtuutettu HTTPS-pyyntö palveluun, joka sinua kiinnostaa. Jos pyyntö saavuttaa palvelun ja se hylätään, katso tunnistetietoja, IAM:ää ja mahdollista palvelun kehän käytäntöä.
Yksityinen reititys ei anna API-valtuutusta eikä muuta sitä, mitä identiteetti saa tehdä. Siirron onnistuminen ja valtuutettu vastaus ovat erillisiä tuloksia, ja tarvitset molemmat. Pidä myös IPv6-polku selkeänä, koska IPv4-etuliitteiden määrittäminen ei kerro mitään asiakkaasta, joka suosii IPv6:ta.
Googlen opas Private Google Accessista paikallisverkosta kattaa DNS-tietueet ja reititysvaatimukset yhdessä, joten vertaa resolver- ja mainosasetuksiasi siihen etkä foorumiviestiin. Suorita sitten sama pyyntö uudelleen ja kirjaa vastaus ja reitti samaan tikettiin.