VPN-ja në VPC funksionon, por shërbimi i menaxhuar skadon
Tuneli përfundon në skajin tuaj, jo në derën e përparme të ofruesit. Klasifikoni objektivin si i strehuar në VM, i lidhur me VPC ose vetëm publik përpara se të ndryshoni një rrugë.
Arritja e një baze të dhënash të menaxhuar përmes VPN dështon zakonisht për një arsye që askush nuk e shkroi në udhëzues: tuneli përfundon në skajin e rrjetit tuaj, ndërsa shërbimi nuk ka qenë kurrë në anën tuaj të tij. Tabela e rrugëve duket e saktë, tuneli raporton se është aktiv dhe lidhja gjithsesi skadon. Kryeni katër kontrollet më poshtë me radhë dhe ndaloni te i pari, kushti i kalimit të të cilit nuk plotësohet, sepse çdo kontroll pas tij supozon se të mëparshmit kaluan.
Kontrolli i parë: ku jeton në të vërtetë pika fundore?
Një portë VPN bashkon dy rrjete, adresimin e të cilave e kontrolloni ju. Një shërbim i menaxhuar operohet prapa derës së përparme të vetë ofruesit, dhe ajo derë merr një nga tre format në varësi të produktit. Nëse nuk e dini me cilën formë keni të bëni, asnjë punë rrugësh nuk do të ndihmojë, sepse defekti mund të mos jetë fare defekt rruge.
| 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 |
Shumica e pasditeve të humbura vijnë nga anashkalimi i këtij klasifikimi dhe kalimi drejt e te tabela e rrugëve. Një shërbim i strehuar te ofruesi me pikë fundore publike nuk është prapa tunelit tuaj çfarëdo që thotë diagrami, dhe ai i lidhur me VPC nuk do të shfaqet kurrë në një përgjigje publike DNS.
Kontrolli i dytë: një shërbim i lidhur me VPC si ElastiCache
Cache-t e këtij lloji adresohen brenda VPC-së tuaj dhe nuk kanë fare dëgjues të kthyer nga interneti. Një VPN klienti që përfundon në të njëjtën VPC mund t'i arrijë ato, por vetëm kur tre kushte përputhen. Pika fundore e cache-s duhet të lidhet me nënrrjeta që tuneli juaj i sheh, grupi i tij i sigurisë duhet të lejojë adresën nga e cila vijnë klientët tuaj, dhe ana e klientit ka nevojë për një rrugë që mbulon nënrrjetat e cache-s.
Gabimi i zakonshëm është të supozohet se një lidhje diku afër llogaritet. Lidhja e VPN-së me një VPC tjetër, ose mbështetja vetëm në peering, nuk e zgjat grupin e sigurisë së cache-s apo tabelën e rrugëve të nënrrjetës së tij te klientët tuaj. Kur tuneli ekzistues përfundon diku tjetër, një host kërcimi ose një server VPN i vendosur brenda atij VPC është alternativa e zakonshme. Ajo alternativë është një shmangie dhe jo një dizajn, dhe duhet të etiketohet si e tillë në udhëzues.
Kontrolli i tretë: një pikë fundore PaaS me emër publik
Azure Database for PostgreSQL paraqet një emër serveri publik. Nuk ju jep një adresë private që mund ta fiksoni në një skedar hosts dhe ta drejtoni përmes një porte. Pikat fundore të shërbimit të rrjetit virtual kufizojnë cilat nënrrjeta mund të arrijnë një burim; ato nuk autorizojnë një klient lokal që vjen përmes VPN.
Marrja e aksesit privat do të thotë të futni një pikë fundore private ose një dizajn lidhjeje private, dhe më pas të shtoni një zonë DNS private që emri publik të përgjigjet me atë pikë fundore në vend të internetit. Një VPN e kombinuar me një rregull pikë fundore shërbimi është një arkitekturë tjetër që duket e njëjtë vetëm në një diagram. App Service ndjek të njëjtën logjikë nga drejtimi i kundërt: integrimi me VNet lejon aplikacionin të bëjë thirrje dalëse në një VNet dhe nuk krijon një rrugë private hyrëse nga tuneli juaj. Prandaj aksesi privat hyrës kërkon një pikë fundore private, një mjedis App Service ose një portë përpara aplikacionit, dhe cila prej tyre mund të përdoret varet nga plani.
Kontrolli i katërt: produkte me derën e tyre të përparme
Firebase Hosting nuk mund të lidhet me një Cloud VPN, sepse shtresa e strehimit është një front global dhe jo diçka brenda VPC-së së një projekti. Alternativa e dokumentuar është të ndërtoni vetë pikën e kontrolluar të hyrjes, me një instancë proxy ose një balancues ngarkese të mbështetur nga një kovë. Në çdo rast faqja pushon së qeni produkt i pastër strehimi dhe bëhet infrastrukturë që tani e operoni ju. Ai shkëmbim meriton të emërtohet përpara se dikush të premtojë se tuneli do ta mbulojë.
Private API Gateway qëndron më afër anës së shërbimeve VPC: një pikë fundore VPC e tipit interface publikon një emër hosti, përgjigjet e të cilit janë adresa private, dhe trafiku nga ambientet tuaja vjen përmes tunelit ose një interkoneksioni të dedikuar. Pika fundore duhet të lidhet me API-në, dhe certifikata bashkë me emrin e hostit duhet të përputhen me domenin e personalizuar që përdorin thirrësit.
Tunelet e Google Cloud VPN lidhen me adresa IP homologësh, jo me emra. Përcjellja e DNS konfigurohet veçmas, prandaj një tunel mund të jetë plotësisht i shëndoshë ndërsa kërkimet në zonën private të largët ende dështojnë.
Pastaj lokalizoni kufirin
Ekzekutoni të njëjtën lidhje nga një VM brenda VPC-së. Kur atje funksionon dhe nga klienti VPN dështon, boshllëku qëndron midis rrugës së klientit dhe pikës fundore të shërbimit: një rrugë, një grup sigurie, një politikë pike fundore ose një emër. Kur dështojnë të dyja përpjekjet, asgjë në atë rrjet nuk mund ta arrijë shërbimin, dhe VPN-ja nuk ishte kurrë pengesa.
getent hosts db.internal.example
nc -vz db.internal.example 5432Bëni kërkimin e emrit dhe kontrollin e portës veçmas, sepse dështojnë për arsye të ndryshme dhe çifti ju tregon cila gjysmë e rrugës është e prishur. Një emër që zgjidhet në një adresë publike ju thotë se zona private DNS nuk është në lojë.