VPN ke VPC berfungsi, tetapi layanan terkelola kehabisan waktu

Menjangkau basis data terkelola melalui VPN biasanya gagal karena alasan yang tidak ditulis siapa pun di runbook: tunel berakhir di tepi jaringan Anda, sedangkan layanan itu tidak pernah berada di sisi Anda. Tabel rute tampak benar, tunel melaporkan aktif, dan koneksi tetap kehabisan waktu. Jalankan keempat pemeriksaan di bawah secara berurutan dan berhenti pada pemeriksaan pertama yang syarat lolosnya tidak terpenuhi, karena setiap pemeriksaan setelahnya mengandaikan yang sebelumnya terpenuhi.

Pemeriksaan satu: di mana titik akhir sebenarnya berada?

Gateway VPN menyatukan dua jaringan yang penalamatannya Anda kendalikan. Layanan terkelola dijalankan di balik pintu depan penyedia sendiri, dan pintu itu mengambil salah satu dari tiga bentuk tergantung produknya. Jika Anda tidak tahu bentuk mana yang sedang dihadapi, tidak ada pekerjaan rute yang akan membantu, karena kegagalannya mungkin bukan kegagalan rute sama sekali.

Sebagian besar sore yang terbuang berasal dari melewati klasifikasi ini dan langsung menuju tabel rute. Layanan yang dihosting penyedia dengan titik akhir publik tidak berada di balik tunel Anda apa pun kata diagramnya, dan yang terhubung ke VPC tidak akan pernah muncul dalam jawaban DNS publik.

Pemeriksaan dua: layanan terhubung VPC seperti ElastiCache

Cache jenis itu dialamatkan di dalam VPC Anda sendiri dan sama sekali tidak memiliki pendengar yang menghadap internet. VPN klien yang berakhir di VPC yang sama dapat menjangkaunya, tetapi hanya bila tiga syarat terpenuhi bersamaan. Titik akhir cache harus terhubung dengan subnet yang dapat dilihat tunel Anda, grup keamanannya harus mengizinkan alamat asal klien Anda, dan sisi klien memerlukan rute yang mencakup subnet cache.

Kesalahan umum adalah menganggap koneksi di suatu tempat terdekat turut dihitung. Menyambungkan VPN ke VPC lain, atau hanya mengandalkan peering, tidak memperluas grup keamanan cache atau tabel rute subnetnya ke klien Anda. Bila tunel yang ada berakhir di tempat lain, jump host atau server VPN yang ditempatkan di dalam VPC itu adalah alternatif yang lazim. Alternatif itu adalah jalan pintas, bukan rancangan, dan sebaiknya diberi label demikian di runbook.

Pemeriksaan tiga: titik akhir PaaS dengan nama publik

Azure Database for PostgreSQL menyajikan nama server publik. Ia tidak memberi Anda alamat privat yang bisa dipasang di berkas hosts dan dirutekan melalui gateway. Titik akhir layanan jaringan virtual membatasi subnet mana yang boleh menjangkau sumber daya; itu tidak memberi otorisasi kepada klien lokal yang datang lewat VPN.

Mendapatkan akses privat berarti memasukkan titik akhir privat atau rancangan private link, lalu menambahkan zona DNS privat agar nama publik menjawab dengan titik akhir itu alih-alih internet. VPN yang digabung dengan aturan titik akhir layanan adalah arsitektur lain yang hanya tampak serupa di diagram. App Service mengikuti logika yang sama dari arah sebaliknya: integrasi VNet memungkinkan aplikasi melakukan panggilan keluar ke VNet, dan itu tidak menciptakan jalur privat masuk dari tunel Anda. Akses privat masuk karena itu memerlukan titik akhir privat, App Service Environment, atau gateway di depan aplikasi, dan mana yang bisa Anda pakai bergantung pada paketnya.

Pemeriksaan empat: produk dengan pintu depan sendiri

Firebase Hosting tidak dapat dihubungkan ke Cloud VPN, karena lapisan hosting merupakan frontend global dan bukan sesuatu di dalam VPC proyek. Alternatif yang didokumentasikan adalah membangun titik masuk terkendali sendiri, dengan instans proxy atau penyeimbang beban yang ditopang bucket. Bagaimanapun situs berhenti menjadi produk hosting murni dan menjadi infrastruktur yang kini Anda operasikan. Pertukaran itu layak dinamai sebelum seseorang menjanjikan tunel akan mencakupnya.

Private API Gateway lebih dekat ke sisi layanan VPC: titik akhir VPC bertipe interface menerbitkan nama host yang jawabannya berupa alamat privat, dan lalu lintas dari lokasi Anda datang melalui tunel atau interkoneksi khusus. Titik akhir harus terhubung dengan API, dan sertifikat beserta nama host harus cocok dengan domain khusus yang dipakai pemanggil.

Tunel Google Cloud VPN terikat pada alamat IP rekan, bukan pada nama. Penerusan DNS dikonfigurasi terpisah, itulah sebabnya tunel bisa sepenuhnya sehat sementara pencarian di zona privat jarak jauh tetap gagal.

Lalu temukan batasnya

Jalankan koneksi yang sama dari VM di dalam VPC. Bila berhasil di sana dan gagal dari klien VPN, celahnya ada di antara jalur klien dan titik akhir layanan: rute, grup keamanan, kebijakan titik akhir, atau nama. Bila kedua percobaan gagal, tidak ada apa pun di jaringan itu yang dapat menjangkau layanan, dan VPN tidak pernah menjadi penghalang.

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

Lakukan pencarian nama dan pemeriksaan port secara terpisah, karena keduanya gagal karena alasan berbeda dan pasangan itu memberi tahu Anda separuh jalur mana yang rusak. Nama yang terurai ke alamat publik memberi tahu Anda bahwa zona DNS privat tidak sedang berlaku.