OpenVPN di GCE: tambahkan alias IP sebelum push rute

Klien menghubungi server OpenVPN di VM Compute Engine, jendela status berkata terhubung, tetapi ping ke host di dalam VPC tetap tidak sampai ke mana pun. Naluri kita adalah menambah satu baris push lagi, dan itu tidak pernah memperbaikinya. Compute Engine memutuskan ke mana paket pergi berdasarkan tabel rutenya sendiri dan alamat yang benar-benar dipegang antarmuka VM, jadi pool tunnel yang tidak dimiliki VM adalah pool yang tidak disampaikan siapa pun.

Ikuti paket yang gagal, bukan file konfigurasi, dan bagian yang hilang akan muncul berurutan.

Mulai dari paket yang mati

SYN meninggalkan klien, masuk ke tunnel, dan mencapai VM sebagai paket terenkapsulasi menuju tujuan di dalam VPC. OpenVPN mendekapsulasinya dan mencoba meneruskannya keluar eth0, tempat fabric mengajukan satu pertanyaan sebelum apa pun: apakah instans ini memiliki alamat tujuan. Pool tunnel yang dipotong dari subnet orang lain gagal pada pertanyaan itu, dan paket dibuang sebelum rute atau aturan firewall apa pun dilihat.

Jadi arah dari klien ke VPC punya dua syarat terpisah, dan tidak satu pun berupa direktif push. VM memerlukan rentang alias yang mencakup pool tunnel, dan itulah yang menjadikannya pemilik sah alamat tersebut. VPC memerlukan rute yang menamai VM sebagai next hop untuk setiap prefix yang dilindungi. Jika salah satu hilang, paket mati di tempat lain, sementara klien melihat kesunyian yang sama.

Baca kegagalan dalam urutan itu, karena dari sisi klien kedua kondisi tampak identik. Tunnel yang melaporkan terhubung sementara tidak ada yang menjawab adalah tanda masalah topologi, bukan cipher yang buruk.

Apakah instans memiliki pool tunnel

Beri VM rentang sekunder di dalam subnet-nya sendiri, lalu buat OpenVPN membagikan alamat tepat dari rentang itu. Pada instans yang alamat utamanya 10.156.0.10/20, alias /28 menjaga pool terpisah dari alamat yang sudah dipegang instans lain:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Direktif server kemudian harus menjelaskan blok yang sama. Alamat pertamanya menjadi gateway tunnel, dan alamat sisanya dibagikan ke klien. Di sini dua angka menjelaskan satu blok, sebuah jaringan dan sebuah netmask, dan itulah sintaks pool yang masih diharapkan OpenVPN.

server 10.156.1.0 255.255.255.240

Pastikan alamat itu benar-benar mendarat di antarmuka, bukan hanya di konfigurasi OpenVPN. Fabric meneruskan apa yang dilaporkan NIC, bukan apa yang diyakini daemon. Satu perintah menyelesaikannya:

ip -4 addr show dev eth0

Alamat sekunder yang tidak pernah mencapai eth0, atau pool yang tumpang tindih dengan subnet lain, muncul kemudian sebagai kehilangan intermiten, bukan sebagai galat saat mulai. Daemon berjalan, klien terhubung, dan hanya sebagian tujuan berperilaku salah. Jaga rentang alias tetap kecil agar pool mudah dikenali di tabel rute. Jangan pernah memotongnya dari subnet yang sudah dipakai instans lain.

Beri next hop pada lalu lintas balik

Balasan dari host di VPC dialamatkan ke alamat klien di pool tunnel, yang tidak termasuk subnet mana pun yang dikenal VPC. Tanpa rute untuk pool itu, balasan berhenti di hop pertama yang tidak menemukan kecocokan, dan permintaan bisa saja sudah berhasil di ujung sana.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Rute yang sama diperlukan untuk setiap prefix yang berada di belakang klien, bukan di dalam VPC. Prefix itu juga memerlukan entri iroute di file ccd klien tersebut. Entri itu adalah pembukuan di sisi server: ia memberi tahu server klien mana yang memiliki prefix, dan tidak memasang apa pun pada klien itu sendiri.

Simpan daftar push untuk sisi klien percakapan, karena daftar itu hanya menambahkan rute ke mesin yang terhubung. Baris push untuk subnet VPC dan rute VPC kembali ke pool adalah dua bagian dari jalur yang sama, dan satu bagian saja menghasilkan tunnel yang membawa permintaan tetapi tidak membawa balasan.

Firewall, penerusan, dan hop di antaranya

Firewall VPC menilai paket yang sudah didekapsulasi, jadi aturan ingress harus mengizinkan pool tunnel dan setiap prefix situs yang mencapai VM lewat jalur itu. Sikap tolak secara default gagal diam-diam di sini: paket dibuang setelah dekapsulasi, dan log OpenVPN menunjukkan sesi yang sehat.

Pada setiap host Linux yang meneruskan alih-alih mengakhiri, periksa apakah net.ipv4.ip_forward aktif. Aturan kepemilikan juga berlaku di sana: mesin yang meneruskan untuk subnet yang tidak dimilikinya membuang paket persis seperti VM. Baca nilainya sebelum menyalahkan tunnel.

Saat tepat satu prefix gagal

Kegagalan sebagian adalah kasus yang paling mudah dibaca, karena semua hal lain di jalur sudah terbukti. Mulai dari daftar rute dan baca rentang tujuan serta next hop entri yang seharusnya mencakup prefix itu, lalu baca deskripsi instans dan bandingkan rentang alias-nya dengan pool yang dibagikan server.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Rute yang hilang tampil sebagai tidak adanya next hop untuk prefix, sedangkan alias yang hilang tampil sebagai paket yang dibuang di antarmuka; dari sisi klien keduanya tampak mirip dan dalam dua keluaran itu sama sekali berbeda. Jika keduanya ada, tersangka yang tersisa adalah iroute ccd milik klien yang mengklaim prefix itu.

Tuliskan empat nilai di samping tunnel: rentang alias, pool server, prefix yang di-push, rute VPC. Alias yang basi merusak setiap alamat pool, rute yang basi merusak satu arah, push yang hilang menyembunyikan prefix dari klien, dan iroute yang salah mengirim prefix ke peer yang salah. Orang berikutnya yang menambah subnet memerlukan keempatnya di satu tempat, dan catatan itu lebih murah daripada malamnya.