VPNa VPCra sartzen da, baina kudeatutako zerbitzuak denbora-muga gainditzen du
Tunela zure ertzean amaitzen da, ez hornitzailearen atean. Sailkatu helburua VMan ostatatua, VPCra konektatua edo soilik publikoa gisa ibilbidea aldatu aurretik.
VPN baten bidez kudeatutako datu-base batera heltzeak huts egiten du normalean inork eskuliburuan idatzi ez zuen arrazoi batengatik: tunela zure sarearen ertzean amaitzen da, eta zerbitzua ez zen inoiz egon haren zure aldean. Ibilbide-taula zuzena dirudi, tunelak martxan dagoela dio, eta konexioak denbora-muga gainditzen du hala ere. Egin beheko lau egiaztapenak hurrenez hurren eta gelditu baldintza betetzen ez duen lehenengoan, ondorengo egiaztapen bakoitzak aurrekoek bete zutela suposatzen baitu.
Lehen egiaztapena: non bizi da amaiera-puntua benetan?
VPN atebide batek zuk helbideratzea kontrolatzen duzun bi sare elkartzen ditu. Kudeatutako zerbitzua hornitzailearen bere atearen atzean ustiatzen da, eta ate horrek hiru formetako bat hartzen du produktuaren arabera. Ez badakizu zein formarekin ari zaren, ibilbide-lanek ez dute lagunduko, hutsegitea agian ez baita ibilbide-hutsegite bat.
| 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 |
Galdu ohi diren arratsalde gehienak sailkapen hau saltatu eta zuzenean ibilbide-taulara joateagatik gertatzen dira. Hornitzailean ostatatutako zerbitzu batek amaiera-puntu publikoa badu, ez dago zure tunelaren atzean diagramak esaten duena esaten duela ere, eta VPCra konektatutako bat ez da inoiz agertuko DNS erantzun publiko batean.
Bigarren egiaztapena: VPCra konektatutako zerbitzu bat, ElastiCache bezala
Mota horretako cacheak zure VPC propioaren barruan helbideratzen dira eta ez dute internet aldera begira dagoen entzulerik. VPC berean amaitzen den bezero VPN batek haietara irits daiteke, baina hiru baldintza batera etortzen direnean soilik. Cachearen amaiera-puntuak zure tunelak ikus ditzakeen azpisareekin lotuta egon behar du, bere segurtasun-taldeak zure bezeroak datozen helbidea onartu behar du, eta bezeroaren aldeak cachearen azpisareak estaltzen dituen ibilbidea behar du.
Ohiko akatsa da gertuko konexio bat baliagarritzat jotzea. VPNa beste VPC batera konektatzeak, edo soilik peering-ean oinarritzeak, ez dio cachearen segurtasun-taldeari edo haren azpisarearen ibilbide-taulari zure bezeroetaraino hedatzen. Dagoen tunela beste leku batean amaitzen denean, jauzi-host bat edo VPC horren barruan jarritako VPN zerbitzari bat izaten da ohiko ordezko aukera. Ordezko aukera hori saihesbidea da eta ez diseinua, eta eskuliburuan hala etiketatu beharko litzateke.
Hirugarren egiaztapena: izen publiko bat duen PaaS amaiera-puntua
Azure Database for PostgreSQLek zerbitzari-izen publiko bat aurkezten du. Ez dizu hosts fitxategi batean finkatu eta atebide baten bidez bideratu dezakezun helbide pribaturik ematen. Sare birtualeko zerbitzu-amaiera-puntuek mugatzen dute zein azpisarek har dezaketen baliabide bat; ez dute VPN bidez iristen den bezero lokal bat baimintzen.
Sarbide pribatua lortzeak amaiera-puntu pribatu bat edo esteka pribatuaren diseinu bat sartzea esan nahi du, eta gero DNS zona pribatu bat gehitzea, izen publikoak interneten ordez amaiera-puntu horrekin erantzun dezan. VPN bat zerbitzu-amaiera-puntuaren arau batekin konbinatuta beste arkitektura bat da, diagrama batean soilik antzekoa dirudiena. App Service-k logika bera jarraitzen du kontrako norabidetik: VNet integrazioak aplikazioari VNet batera irteerako deiak egitea ahalbidetzen dio, eta ez du zure tunelatik sarbide pribatu sarrerako biderik sortzen. Sarrerako sarbide pribatuak, beraz, amaiera-puntu pribatu bat, App Service ingurune bat edo aplikazioaren aurretik dagoen atebide bat behar du, eta horietatik zein erabil dezakezun planaren araberakoa da.
Laugarren egiaztapena: beren ate propioa duten produktuak
Firebase Hosting ezin da Cloud VPN batera konektatu, ostatu-geruza aurreko alde globala baita, eta ez proiektu baten VPCaren barruko zerbait. Dokumentatutako alternatiba sarrerako puntu kontrolatua zuk zeuk eraikitzea da, proxy instantzia batekin edo biltegi batean oinarritutako karga-banatzaile batekin. Edozein modutan gunea ez da ostatu-produktu hutsa izateari uzten eta orain zuk kudeatzen duzun azpiegitura bihurtzen da. Truke hori izendatzea merezi du norbaitek tunelak estaliko duela agindu aurretik.
Private API Gateway VPC zerbitzuen aldetik gertuago dago: interfaze motako VPC amaiera-puntu batek erantzunak helbide pribatuak dituen ostalari-izena argitaratzen du, eta zure instalazioetatik trafikoa tunelaren edo interkonexio dedikatu baten bidez iristen da. Amaiera-puntuak APIarekin lotuta egon behar du, eta ziurtagiriak eta ostalari-izenak deitzaileek erabiltzen duten domeinu pertsonalizatuarekin bat etorri behar dute.
Google Cloud VPN tunelak pareko IP helbideei lotzen zaizkie, ez izenei. DNS birbidaltzea bereiz konfiguratzen da, eta horregatik tunel bat erabat osasuntsu egon daiteke urruneko zona pribatuko bilaketek huts egiten duten bitartean.
Ondoren kokatu muga
Exekutatu konexio bera VPCaren barruko VM batetik. Han lortzen denean eta VPN bezerotik huts egiten duenean, hutsunea bezeroaren bidearen eta zerbitzuaren amaiera-puntuaren artean dago: ibilbide bat, segurtasun-talde bat, amaiera-puntuaren politika bat edo izen bat. Bi saiakerek huts egiten dutenean, sare horretan ezerk ezin du zerbitzura iritsi, eta VPN ez zen inoiz oztopoa izan.
getent hosts db.internal.example
nc -vz db.internal.example 5432Egin izen-bilaketa eta ataka-egiaztapena bereiz, arrazoi desberdinengatik huts egiten baitute eta bikoteak bidearen zein erdi dagoen hautsita esaten dizu. Helbide publiko batera ebazten den izen batek DNS zona pribatua ez dagoela jokoan esaten dizu.