Gumagana ang VPN papasok sa VPC, ngunit nag-time out ang pinamamahalaang serbisyo

Ang pag-abot sa pinamamahalaang database sa pamamagitan ng VPN ay kadalasang nabibigo dahil sa dahilang walang nakasulat sa runbook: nagtatapos ang tunnel sa gilid ng iyong network, samantalang ang serbisyo ay hindi kailanman nasa iyong panig niyon. Mukhang tama ang talahanayan ng ruta, iniuulat ng tunnel na aktibo ito, at nag-time out pa rin ang koneksyon. Gawin ang apat na pagsusuri sa ibaba nang sunod-sunod at huminto sa una na hindi natutugunan ang kondisyon ng pagpasa, dahil ipinapalagay ng bawat susunod na pagsusuri na nakapasa ang mga nauna.

Pagsusuri isa: saan talaga nakatira ang endpoint?

Ang VPN gateway ay nag-uugnay ng dalawang network na ikaw ang may kontrol sa pag-address. Ang pinamamahalaang serbisyo ay pinapatakbo sa likod ng sariling harap na pinto ng provider, at ang pintong iyon ay kumukuha ng isa sa tatlong hugis depende sa produkto. Kung hindi mo alam kung anong hugis ang hinaharap mo, walang anumang gawain sa ruta ang makakatulong, dahil maaaring hindi ito pagkabigo ng ruta.

Karamihan ng nasayang na hapon ay nagmumula sa paglaktaw sa pag-uuring ito at pagpunta diretso sa talahanayan ng ruta. Ang serbisyong naka-host sa provider na may publikong endpoint ay wala sa likod ng iyong tunnel anuman ang sabihin ng diagram, at ang nakakabit sa VPC ay kailanman hindi lilitaw sa publikong sagot ng DNS.

Pagsusuri dalawa: serbisyong nakakabit sa VPC tulad ng ElastiCache

Ang mga cache ng ganoong uri ay ina-address sa loob ng iyong sariling VPC at wala silang anumang tagapakinig na nakaharap sa internet. Ang client VPN na nagtatapos sa parehong VPC ay maaaring makarating sa kanila, ngunit kapag nagtugma lamang ang tatlong kondisyon. Ang endpoint ng cache ay dapat na nauugnay sa mga subnet na nakikita ng iyong tunnel, ang security group nito ay dapat payagan ang address na pinanggagalingan ng iyong mga client, at ang panig ng client ay nangangailangan ng rutang sumasaklaw sa mga subnet ng cache.

Ang karaniwang pagkakamali ay ipagpalagay na ang koneksyon sa isang lugar na malapit ay binibilang. Ang pagkabit ng VPN sa ibang VPC, o pag-asa lamang sa peering, ay hindi nagpapalawak ng security group ng cache o ng talahanayan ng ruta ng subnet nito sa iyong mga client. Kapag nagtatapos ang umiiral na tunnel sa ibang lugar, ang jump host o VPN server na inilagay sa loob ng VPC na iyon ang karaniwang alternatibo. Ang alternatibong iyon ay isang lusot at hindi isang disenyo, at dapat itong markahan nang ganoon sa runbook.

Pagsusuri tatlo: PaaS endpoint na may publikong pangalan

Nagpapakita ang Azure Database for PostgreSQL ng publikong pangalan ng server. Hindi nito ibinibigay sa iyo ang pribadong address na maaari mong i-pin sa file ng hosts at iruta sa pamamagitan ng gateway. Nililimitahan ng mga service endpoint ng virtual network kung aling mga subnet ang makakaabot sa isang resource; hindi nila pinapahintulutan ang lokal na kliyenteng dumarating sa pamamagitan ng VPN.

Ang pagkuha ng pribadong access ay nangangahulugan ng pagpapasok ng pribadong endpoint o disenyo ng pribadong link, at pagkatapos ay pagdaragdag ng pribadong DNS zone upang ang publikong pangalan ay sumagot gamit ang endpoint na iyon sa halip na internet. Ang VPN na sinamahan ng service endpoint rule ay ibang arkitektura na kamukha lamang sa diagram. Sinusunod ng App Service ang parehong lohika mula sa kabilang direksyon: pinapayagan ng VNet integration ang app na gumawa ng papalabas na tawag papasok sa VNet, at hindi ito lumilikha ng papasok na pribadong landas mula sa iyong tunnel. Kaya ang papasok na pribadong access ay nangangailangan ng pribadong endpoint, App Service environment o gateway sa harap ng app, at kung alin sa mga ito ang magagamit mo ay nakadepende sa plano.

Pagsusuri apat: mga produktong may sariling harap na pinto

Hindi maikakabit ang Firebase Hosting sa Cloud VPN, dahil ang host layer ay isang pandaigdigang harap at hindi isang bagay sa loob ng VPC ng isang proyekto. Ang dokumentadong alternatibo ay itayo mismo ang kontroladong pasukan, gamit ang proxy instance o load balancer na sinusuportahan ng bucket. Sa alinmang paraan, tumitigil ang site sa pagiging purong produkto ng hosting at nagiging imprastrukturang pinapatakbo mo na ngayon. Ang palitang iyon ay karapat-dapat pangalanan bago may mangako na sasaklawin ito ng tunnel.

Ang Private API Gateway ay mas malapit sa panig ng mga serbisyo ng VPC: ang interface na VPC endpoint ay naglalathala ng hostname na ang mga sagot ay pribadong address, at ang trapiko mula sa iyong pasilidad ay dumarating sa tunnel o sa dedikadong interconnect. Ang endpoint ay dapat nauugnay sa API, at ang sertipiko at hostname ay dapat tumugma sa custom na domain na ginagamit ng mga tumatawag.

Ang mga tunnel ng Google Cloud VPN ay nakatali sa mga IP address ng kapares, hindi sa mga pangalan. Ang DNS forwarding ay naka-configure nang hiwalay, kaya ang isang tunnel ay maaaring ganap na malusog habang nabibigo pa rin ang mga paghahanap sa malayong pribadong zone.

Pagkatapos, hanapin ang hangganan

Patakbuhin ang parehong koneksyon mula sa VM sa loob ng VPC. Kapag nagtagumpay doon at nabigo mula sa client VPN, ang agwat ay nasa pagitan ng landas ng client at ng endpoint ng serbisyo: isang ruta, isang security group, isang patakaran ng endpoint o isang pangalan. Kapag nabigo ang dalawang pagtatangka, walang anuman sa network na iyon ang makakaabot sa serbisyo, at ang VPN ay hindi kailanman naging hadlang.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Gawin nang hiwalay ang paghahanap ng pangalan at ang pagsusuri ng port, dahil nabibigo sila sa magkaibang dahilan at sinasabi sa iyo ng pares kung aling kalahati ng landas ang sira. Ang pangalang nagsasalin sa publikong address ay nagsasabi sa iyo na hindi gumagana ang pribadong DNS zone.