Google API sa VPN: i-route ang VIP, hindi lang ang subnet

Pumasok sa lokal na server gamit ang SSH, itaas ang tunnel, at sumasagot ang pribadong VM; pagkatapos ay nabigo ang unang tawag sa Google API nang walang ruta. Magkaibang destinasyon ang subnet ng VM at ang mga VIP ng API, kaya hindi pinipili ng ruta para sa isa ang isa pa. Tatlong kundisyon ang dapat totoo bago gumana ang pribadong tawag sa API. Dapat malutas ang pangalan ng API sa isang VIP, dapat i-anunsyo ang VIP prefix sa tunnel, at dapat alam ng VPC kung paano ibabalik ang sagot. Wala ni isa sa mga iyon ang sinasabi ng ping, at wala rin ang gumaganang SSH session papunta sa makina sa subnet.

Ang mga VIP ng API ay hiwalay na destinasyon

Naglalathala ang Google ng mga dedikadong VIP para sa access sa API mula sa lokal na network, at iyon ang mga address na dapat ibalik ng iyong DNS para sa mga pangalan ng API. Pareho silang maliliit na prefix at wala sa kanila ang space ng RFC 1918:

Ang mga address na mukhang pampubliko ay hindi nangangahulugang dapat lisanin ng ruta ang tunnel para sa karaniwang internet. Umiiral ang mga prefix para maabot ng lokal na kliyente ang mga frontend ng Google sa suportadong landas sa halip na sa arbitraryong exit point. Ituring ang mga ito na destinasyong kabilang sa tunnel, hindi bilang host na susuriin. Ang firewall rule na isinulat para sa labasan ng internet ay karaniwang nagtatapon sa kanila, at iyon ay karaniwang dahilan kung bakit nabigo ang tawag bago pa ito magsimula.

Ang DNS ang nagpapasya kung aling endpoint ang naaabot mo

Ituro ang lokal na resolver sa mga record na dokumentado ng Google para sa piniling endpoint, upang ang mga pangalang kailangan ng aplikasyon ay sumagot gamit ang VIP na iyon. Ang pagmamapa lamang ng googleapis.com ay hindi imbentaryo: may sariling dokumentadong pangalan ang mga registry ng pakete, registry ng container at connector ng migrasyon. Hindi rin dinadala ng restricted VIP ang bawat serbisyo, kaya ang pangalang nalutas ay maaaring hindi pa rin suportado. Isulat ang mga domain na aktuwal na kinokontak ng aplikasyon bago mo hawakan ang resolver.

Ang paghula ng address ng VM sa VPC bilang kapalit ng pangalan ng serbisyo ay hindi pagtatama, at karaniwang itinatago nito ang puwang sa DNS hanggang may ibang kliyenteng mabigo.

I-anunsyo ang VIP prefix, panatilihin ang iba

Sa koneksyong nakabatay sa BGP, dapat i-anunsyo ng Cloud Router ang piniling VIP prefix upang matutunan ng lokal na router ang saklaw na iyon sa nilalayong session. Ang pag-anunsyo lamang ng mga subnet ng VPC ay hindi nagdaragdag ng saklaw na iyon, at patuloy na ginagamit ng lokal na router ang default nitong landas para sa mga address na iyon. Ang prefix sa routing table ang tanging patunay na tumawid ang anunsyo sa session.

Panatilihin ang mga umiiral na anunsyo habang idinaragdag mo ang bago, dahil magkaiba ang saklaw ng mga opsyon sa antas ng router at sa antas ng peer, at ang pagpapalit ng set ay maaaring magbawi ng mga network na gumagana na. Pagkatapos ay suriin ang epektibong anunsyo sa bawat session at hindi sa buong router. Ang nawawalang prefix at ang binawing prefix ay magkatulad ang hitsura mula sa lokal na panig, kaya ang tanaw ng session ang naghihiwalay ng paglihis mula sa regression.

Kailangan ng panig ng VPC ang sariling ruta at pabalik na landas

Sa loob ng VPC, dapat gamitin ng landas ng VIP ang default na internet gateway bilang susunod na hop, at sa kabila ng pangalan ay nananatili ang trapik na iyon sa network ng Google. Kailangan din ng VPC ng rutang pabalik sa lokal na pinagmulan sa pamamagitan ng VPN, at hiwalay itong object sa inanunsyong prefix. Isaalang-alang ang dokumentadong panrehiyong pangangailangan sa routing kapag ang tunnel at ang kliyente ay wala sa parehong rehiyon.

Suriin ang pabalik na landas nang hiwalay, dahil ang gumaganang direksyon ng kahilingan ay maaaring magtago ng sirang direksyon ng sagot. Dalawang direksyon, dalawang ruta, at bawat isa ay nabigo sa sarili nitong sintomas.

Subukan ang kahilingan, pagkatapos basahin ang pagtanggi

Walang sagot ang ICMP echo mula sa mga VIP na ito, kaya walang pinatutunayan ang bigong ping at napakaliit ang pinatutunayan ng matagumpay. Mula sa aktuwal na kliyente, suriin ang sagot ng pangalan at ang piniling ruta, pagkatapos gumawa ng awtorisadong HTTPS na kahilingan sa serbisyong mahalaga sa iyo. Kung naabot ng kahilingan ang serbisyo at tinanggihan, tingnan ang mga kredensyal, IAM at anumang naaangkop na patakaran ng perimeter ng serbisyo.

Hindi nagbibigay ng awtorisasyon sa API ang pribadong routing at hindi nito binabago ang pinapayagang gawin ng identidad. Magkaibang resulta ang tagumpay sa transportasyon at ang awtorisadong sagot, at kailangan mo ang pareho. Panatilihing malinaw din ang landas ng IPv6, dahil walang sinasabi ang pagkumpigura ng mga prefix ng IPv4 tungkol sa kliyenteng mas gusto ang IPv6.

Ang gabay ng Google tungkol sa Private Google Access mula sa lokal na network ay sumasaklaw sa mga DNS record at sa mga pangangailangan sa routing nang sabay, kaya ihambing ang mga setting ng resolver at anunsyo mo rito at hindi sa isang post sa forum. Pagkatapos ay patakbuhin muli ang parehong kahilingan at itala ang sagot at ruta sa parehong ticket.