VPN ke VPC berfungsi, tetapi perkhidmatan terurus tamat masa
Terowong berakhir di tepi anda, bukan di pintu hadapan penyedia. Klasifikasikan sasaran sebagai dihoskan pada VM, disambungkan ke VPC atau awam sahaja sebelum menukar laluan.
Mencapai pangkalan data terurus melalui VPN biasanya gagal atas sebab yang tiada siapa tulis dalam runbook: terowong berakhir di tepi rangkaian anda, manakala perkhidmatan itu tidak pernah berada di sisi anda. Jadual laluan kelihatan betul, terowong melaporkan ia aktif, dan sambungan tetap tamat masa. Jalankan empat pemeriksaan di bawah mengikut urutan dan berhenti pada yang pertama yang syarat lulusnya tidak dipenuhi, kerana setiap pemeriksaan selepasnya mengandaikan yang sebelumnya dipenuhi.
Pemeriksaan satu: di manakah titik akhir sebenarnya berada?
Get laluan VPN menyatukan dua rangkaian yang pengealamatannya anda kawal. Perkhidmatan terurus dikendalikan di belakang pintu hadapan penyedia sendiri, dan pintu itu mengambil salah satu daripada tiga bentuk bergantung pada produk. Jika anda tidak tahu bentuk mana yang anda hadapi, tiada kerja laluan akan membantu, kerana kegagalan itu mungkin bukan kegagalan laluan sama sekali.
| 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 |
Kebanyakan petang yang terbuang berpunca daripada melangkau klasifikasi ini dan terus ke jadual laluan. Perkhidmatan yang dihoskan penyedia dengan titik akhir awam tidak berada di belakang terowong anda apa pun kata rajah, dan yang disambungkan ke VPC tidak akan muncul dalam jawapan DNS awam.
Pemeriksaan dua: perkhidmatan disambungkan ke VPC seperti ElastiCache
Cache jenis itu dialamatkan di dalam VPC anda sendiri dan tidak mempunyai pendengar yang menghadap internet langsung. VPN klien yang berakhir dalam VPC yang sama boleh mencapainya, tetapi hanya apabila tiga syarat bertemu. Titik akhir cache mesti dikaitkan dengan subnet yang boleh dilihat oleh terowong anda, kumpulan keselamatannya mesti membenarkan alamat asal klien anda, dan bahagian klien memerlukan laluan yang meliputi subnet cache.
Kesilapan biasa ialah menganggap sambungan di suatu tempat berdekatan juga dikira. Menyambungkan VPN ke VPC lain, atau bergantung hanya pada peering, tidak meluaskan kumpulan keselamatan cache atau jadual laluan subnetnya kepada klien anda. Apabila terowong sedia ada berakhir di tempat lain, hos lompat atau pelayan VPN yang diletakkan di dalam VPC itu ialah alternatif biasa. Alternatif itu ialah jalan pintas dan bukan reka bentuk, dan ia patut dilabel sedemikian dalam runbook.
Pemeriksaan tiga: titik akhir PaaS dengan nama awam
Azure Database for PostgreSQL mengemukakan nama pelayan awam. Ia tidak memberikan anda alamat peribadi yang boleh anda pin dalam fail hosts dan hala tuju melalui get laluan. Titik akhir perkhidmatan rangkaian maya mengehadkan subnet mana yang boleh mencapai sumber; ia tidak memberi kebenaran kepada klien di premis yang tiba melalui VPN.
Mendapatkan akses peribadi bermakna memperkenalkan titik akhir peribadi atau reka bentuk pautan peribadi, kemudian menambah zon DNS peribadi supaya nama awam menjawab dengan titik akhir itu dan bukan internet. VPN yang digabungkan dengan peraturan titik akhir perkhidmatan ialah seni bina lain yang kelihatan serupa hanya pada rajah. App Service mengikut logik yang sama dari arah bertentangan: integrasi VNet membolehkan aplikasi membuat panggilan keluar ke dalam VNet, dan ia tidak mencipta laluan peribadi masuk dari terowong anda. Oleh itu akses peribadi masuk memerlukan titik akhir peribadi, persekitaran App Service atau get laluan di hadapan aplikasi, dan yang mana boleh anda gunakan bergantung pada pelan.
Pemeriksaan empat: produk dengan pintu hadapan sendiri
Firebase Hosting tidak boleh disambungkan kepada Cloud VPN, kerana lapisan pengehosan ialah bahagian hadapan global dan bukan sesuatu di dalam VPC projek. Alternatif yang didokumenkan ialah membina titik masuk terkawal itu sendiri, dengan instans proksi atau pengimbang beban yang disokong oleh baldi. Sama ada cara, tapak berhenti menjadi produk pengehosan tulen dan menjadi infrastruktur yang kini anda kendalikan. Pertukaran itu wajar dinamakan sebelum seseorang berjanji terowong akan meliputinya.
Private API Gateway lebih dekat dengan sisi perkhidmatan VPC: titik akhir VPC jenis interface menerbitkan nama hos yang jawapannya alamat peribadi, dan trafik dari premis anda tiba melalui terowong atau interkoneksi khusus. Titik akhir mesti dikaitkan dengan API, dan sijil serta nama hos mesti sepadan dengan domain tersuai yang digunakan oleh pemanggil.
Terowong Google Cloud VPN terikat kepada alamat IP rakan, bukan kepada nama. Pemajuan DNS dikonfigurasikan secara berasingan, itulah sebabnya terowong boleh sihat sepenuhnya sementara carian dalam zon peribadi jauh masih gagal.
Kemudian tentukan sempadan
Jalankan sambungan yang sama dari VM di dalam VPC. Apabila ia berjaya di sana dan gagal dari klien VPN, jurangnya terletak antara laluan klien dan titik akhir perkhidmatan: laluan, kumpulan keselamatan, dasar titik akhir atau nama. Apabila kedua-dua percubaan gagal, tiada apa dalam rangkaian itu boleh mencapai perkhidmatan, dan VPN tidak pernah menjadi halangan.
getent hosts db.internal.example
nc -vz db.internal.example 5432Lakukan carian nama dan pemeriksaan port secara berasingan, kerana ia gagal atas sebab yang berbeza dan pasangan itu memberitahu anda separuh laluan mana yang rosak. Nama yang diselesaikan kepada alamat awam memberitahu anda bahawa zon DNS peribadi tidak berkuat kuasa.