Google API праз VPN: маршрут да VIP, а не толькі да падсеткі
Маршрут да падсеткі VPC не выбірае VIP-адрасы API. Развязайце правільныя імёны, абвясціце прэфікс VIP, захавайце зваротны шлях у VPC і потым праверце HTTPS.
Падключыцеся па SSH да лакальнага сервера, узніміце тунэль, і прыватная VM адказвае; затым першы запыт да Google API не ўдаецца без маршруту. Падсетка VM і VIP-адрасы API — розныя пункты прызначэння, таму маршрут да аднаго не выбірае іншы. Тры ўмовы павінны выконвацца, каб прыватны запыт да API спрацаваў. Імя API павінна развязвацца ў VIP, прэфікс VIP павінен абвяшчацца праз тунэль, а VPC павінна ведаць, як адправіць адказ назад. Ping не паведамляе нічога з гэтага, і працоўная 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, таму няўдалы ping нічога не даказвае, а паспяховы — вельмі мала. З фактычнага кліента праверце адказ імя і выбраны маршрут, затым зрабіце дазволены HTTPS-запыт да патрэбнай паслугі. Калі запыт дасягае паслугі і яго адхіляюць, глядзіце на ўліковыя даныя, IAM і любую палітыку перыметра паслугі, якая дзейнічае.
Прыватная маршрутызацыя не дае аўтарызацыі API і не змяняе таго, што ідэнтычнасці дазволена рабіць. Поспех транспарту і дазволены адказ — асобныя вынікі, і патрэбны абодва. Трымайце шлях IPv6 яўным, бо наладка прэфіксаў IPv4 нічога не кажа пра кліента, які аддае перавагу IPv6.
Дапаможнік Google па Private Google Access для лакальнай сеткі ахоплівае запісы DNS і патрабаванні да маршрутызацыі разам, таму параўноўвайце налады рэзалвера і абвяшчэння з ім, а не з допісам на форуме. Затым паўтарыце той жа запыт і запішыце адказ і маршрут у тым жа тыкеце.