Konsol Anda menampilkan tunnel hijau, pemantauan di lokasi masih tidak dapat menjangkau satu instans pun, dan membangun ulang tunnel tampak seperti perbaikan yang jelas. Jarang sekali demikian. Tunnel yang terbentuk hanya membuktikan bahwa dua gateway menyelesaikan pertukaran IKE. Itu tidak mengatakan apa pun tentang apakah sebuah paket pernah diizinkan masuk ke VPC Anda.

Empat keputusan berdiri di antara ikon hijau itu dan sebuah balasan, dan semuanya gagal dalam urutan yang dapat diprediksi. Kerjakan dari yang paling murah.

Tiga objek, dan hanya satu di antaranya mengenkripsi

Gateway VPN memiliki alamat eksternal yang menjadi tujuan enkripsi peer Anda. Di konsol Anda tidak pernah membuatnya secara manual: pilih atau pesan alamat di dalam formulir koneksi dan gateway muncul bersamanya. Gateway HA mengambil dua alamat pada dua antarmuka, yang penting pada pemeriksaan kuota nanti.

Tunnel adalah pasangan antara gateway itu dan peer. Ia membawa rahasia bersama dan selector lalu lintas yang dijanjikan untuk dilindungi. Di selector itulah sebagian besar kegagalan senyap dimulai. Tunnel yang selector lokalnya mencakup 10.0.0.0/24 tidak akan mengirimkan 10.0.1.0/24, seberapa sehat pun statusnya terlihat.

Ujung jauh menyimpan daftarnya sendiri, biasanya disebut domain enkripsi, dan perangkat keras terminasi membandingkannya dengan daftar Anda. Tidak ada pihak yang menegosiasikan selector yang tidak pernah diberikan kepadanya.

Tipe routing menentukan apa yang mencapai tabel rute

Cloud VPN menawarkan tiga bentuk routing dan ketiganya tidak bercampur dengan bersih. Routing berbasis kebijakan mempertahankan pasangan selector statis, routing berbasis rute mengharapkan Anda menambahkan rute statis sendiri, dan routing dinamis mengumumkan prefiks melalui Cloud Router lewat BGP. Pilih satu dengan sengaja.

Tunnel dinamis dengan rute statis yang ditulis tangan di sampingnya menghasilkan tabel rute yang kosong setiap kali sesi BGP bergoyang.

Dinamis adalah satu-satunya bentuk yang memungkinkan prefiks terlindungi berubah tanpa membangun ulang tunnel, dan itu menyeret Cloud Router ke dalam kumpulan objek yang harus Anda verifikasi. Selector statis tetap bisa dipakai ketika peer adalah firewall perangkat keras yang tidak bisa berbicara BGP. Saat itu kedua ujung memerlukan rentang yang sama, dan entri yang lebih spesifik harus menang di keduanya. Pasangan yang berbeda satu subnet akan terbentuk lalu membawa separuh lalu lintas Anda.

Penolakan implisit berada di belakang tunnel

Lalu lintas masuk dievaluasi terhadap penolakan implisit pada prioritas terendah, dan aturan itu tidak peduli bahwa paket datang terenkripsi. Sampai aturan firewall menyebut rentang di lokasi dan port yang dipakai, paket didekripsi, diperiksa, dan dibuang. Log VPN tetap bersih sepanjang waktu, karena tunnel melakukan tepat seperti yang dijanjikan.

Bacalah log penolakan firewall sebagai gantinya ketika tunnel aktif dan probe kehabisan waktu, lalu batasi aturan pada rentang sumber dan port yang Anda butuhkan:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Satu arah yang berfungsi adalah petunjuk firewall

Lalu lintas keluar berperilaku berbeda, karena aturan izin implisit membiarkan instans mengirim ke mana saja. Pusat data yang tidak dapat menjangkau VM sering berada di balik jalur keluar yang berfungsi sempurna di arah lain. Asimetri itu memisahkan kelalaian firewall dari kesalahan routing, sebab kesalahan routing memutus kedua arah sekaligus. Uji arah sebaliknya sebelum Anda menyunting satu aturan lagi.

Pembuatan alamat juga merupakan operasi kuota. Proyek yang mendekati batas alamat eksternal yang dipakai menolak koneksi dengan galat yang terbaca seperti kegagalan izin.

Selector, kuota, lalu empat pemeriksaan

Tunnel yang dibuat di konsol kadang mengembalikan selector lalu lintas jarak jauh yang kosong dari gcloud compute vpn-tunnels describe sementara rute yang dihasilkan membawa lalu lintas dengan benar. Bandingkan apa yang dicatat API dengan rentang yang benar-benar Anda lindungi sebelum memutuskan tunnel itu salah. Membuatnya melalui API atau SDK menjaga selector tetap eksplisit.

Kuota adalah kelalaian mudah lainnya. Minta peningkatan sebelum jendela pemeliharaan, bukan selama jendela itu, dan periksa jumlah alamat di proyek yang sama dengan gateway.

Bekerjalah dari luar ke dalam: status peer, kedua daftar selector, rute untuk tiap sisi, aturan masuk untuk rentang sumber dan port, lalu tangkapan paket. Tuliskan alamat gateway, kedua daftar selector, dan tipe routing ke tiket perubahan selagi tunnel masih baru, karena insinyur berikutnya yang menambahkan subnet akan memerlukan ketiganya.

Artikel terkait