VPN en la VPC funkcias, sed la administrata servo tempolimas
La tunelo finiĝas ĉe via rando, ne ĉe la antaŭa pordo de la provizanto. Klasifiku la celon kiel VM-gastigita, VPC-ligita aŭ nur publika antaŭ ol ŝanĝi itineron.
Atingi administratajn datumbazojn tra VPN kutime malsukcesas pro kialo, kiun neniu skribis en la manlibro: la tunelo finiĝas ĉe la rando de via reto, dum la servo neniam sidis ĉe via flanko de ĝi. La itinara tabelo aspektas ĝusta, la tunelo raportas sin aktiva, kaj la konekto tamen tempolimas. Trapasu la kvar kontrolojn sube en ordo kaj haltu ĉe la unua, kies sukcesa kondiĉo ne validas, ĉar ĉiu posta kontrolo supozas, ke la antaŭaj plenumiĝis.
Kontrolo unua: kie efektive loĝas la finpunkto?
VPN-enirejo kunigas du retojn, kies adresadon vi regas. Administrata servo funkciigas malantaŭ la propra antaŭa pordo de la provizanto, kaj tiu pordo alprenas unu el tri formoj laŭ la produkto. Se vi ne scias, kun kiu formo vi traktas, nenia itinara laboro helpos, ĉar la paneo eble tute ne estas itinara paneo.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Plej multaj perditaj posttagmezoj venas de preterlasado de tiu klasifiko kaj de iri rekte al la itinara tabelo. Provizanto-gastigita servo kun publika finpunkto ne estas malantaŭ via tunelo, kion ajn diras la diagramo, kaj VPC-ligita servo neniam aperos en publika DNS-respondo.
Kontrolo dua: VPC-ligita servo kiel ElastiCache
Kaŝmemoroj de tiu speco adresiĝas ene de via propra VPC kaj tute ne havas interretan aŭskultanton. Klienta VPN finiĝanta en la sama VPC povas atingi ilin, sed nur kiam tri kondiĉoj kunfalas. La finpunkto de la kaŝmemoro devas esti ligita al subretoj, kiujn via tunelo povas vidi, ĝia sekureca grupo devas permesi la adreson, de kiu venas viaj klientoj, kaj la klienta flanko bezonas itineron, kiu kovras la subretojn de la kaŝmemoro.
La ofta eraro estas supozi, ke konekto ie proksime validas. Ligi la VPN al alia VPC, aŭ apogiĝi nur sur peerado, ne etendas la sekurecan grupon de la kaŝmemoro nek ĝian subretan itinaran tabelon al viaj klientoj. Kiam la ekzistanta tunelo finiĝas aliloke, saltgastiganto aŭ VPN-servilo metita ene de tiu VPC estas la kutima rezerva solvo. Tiu rezerva solvo estas provizora solvo kaj ne dezajno, kaj ĝi devus esti tiel etikedita en la manlibro.
Kontrolo tria: PaaS-finpunkto kun publika nomo
Azure Database for PostgreSQL prezentas publikan servilan nomon. Ĝi ne donas al vi privatan adreson, kiun vi povus fiksi en hosts-dosiero kaj itinerigi tra enirejo. Finpunktoj de virtuala reta servo limigas, kiuj subretoj rajtas atingi rimedon; ili ne rajtigas lokan klienton, kiu alvenas tra VPN.
Akiri privatan aliron signifas enkonduki privatan finpunkton aŭ privatan ligdezajnon, poste aldoni privatan DNS-zonon, por ke la publika nomo respondu per tiu finpunkto anstataŭ per la interreto. VPN kombinita kun regulo de serva finpunkto estas alia arkitekturo, kiu aspektas sama nur en diagramo. App Service sekvas la saman logikon el la mala direkto: VNet-integrigho ebligas al la aplikaĵo fari elirantajn vokojn en VNet, kaj ĝi ne kreas enirantan privatan vojon el via tunelo. Eniranta privata aliro do postulas privatan finpunkton, App Service Environment aŭ enirejon antaŭ la aplikaĵo, kaj kiun el tiuj vi povas uzi dependas de la plano.
Kontrolo kvara: produktoj kun propra antaŭa pordo
Firebase Hosting ne povas esti ligita al Cloud VPN, ĉar la gastiga tavolo estas tutmonda fasado kaj ne io ene de projekta VPC. La dokumentita alternativo estas konstrui la kontrolitan enirpunkton mem, per prokura instance aŭ per ŝarĝbalancilo subtenata de korbo. Ĉiuokaze la retejo ĉesas esti pura gastiga produkto kaj fariĝas infrastrukturo, kiun vi nun funkciigas. Tiu interŝanĝo indas esti nomata antaŭ ol iu promesos, ke la tunelo kovros ĝin.
Private API Gateway staras pli proksime al la flanko de VPC-servoj: interface-tipa VPC-finpunkto publikigas gastignomon, kies respondoj estas privataj adresoj, kaj trafiko de via sidejo alvenas tra la tunelo aŭ tra dediĉita interkonekto. La finpunkto devas esti ligita al la API, kaj la atestilo plus la gastignomo devas kongrui kun la kutima domajno, kiun uzas la vokantoj.
Google Cloud VPN-tuneloj ligiĝas al IP-adresoj de partneroj, ne al nomoj. DNS-plusendado agordiĝas aparte, kaj tial tunelo povas esti tute sana dum serĉoj en la malproksima privata zono ankoraŭ malsukcesas.
Poste lokalizu la limon
Rulu la saman konekton de VM ene de la VPC. Kiam ĝi sukcesas tie kaj malsukcesas de la VPN-kliento, la breĉo kuŝas inter la klienta vojo kaj la serva finpunkto: itinero, sekureca grupo, finpunkta politiko aŭ nomo. Kiam ambaŭ provoj malsukcesas, nenio en tiu reto povas atingi la servon, kaj la VPN neniam estis la barilo.
getent hosts db.internal.example
nc -vz db.internal.example 5432Faru la nomserĉon kaj la pordokontrolon aparte, ĉar ili malsukcesas pro malsamaj kialoj kaj la paro diras al vi, kiu duono de la vojo estas rompita. Nomo, kiu solviĝas al publika adreso, diras al vi, ke la privata DNS-zono ne ludas.