Klien mendail pelayan OpenVPN pada VM Compute Engine, tetingkap status berkata bersambung, tetapi ping ke hos di dalam VPC masih tidak sampai ke mana-mana. Naluri ialah menambah satu lagi baris push, dan itu tidak pernah membaikinya. Compute Engine memutuskan ke mana paket pergi berdasarkan jadual laluannya sendiri dan alamat yang benar-benar dipegang antara muka VM, jadi pool terowong yang tidak dimiliki VM ialah pool yang tiada siapa menyampaikan kepadanya.

Ikut paket yang gagal dan bukan fail konfigurasi, dan bahagian yang hilang akan muncul mengikut urutan.

Mulakan dengan paket yang mati

SYN meninggalkan klien, masuk ke terowong dan sampai ke VM sebagai paket berkapsul menuju destinasi di dalam VPC. OpenVPN menyahkapsulnya dan cuba menyalurkannya keluar melalui eth0, di mana fabric mengemukakan satu soalan sebelum apa-apa lagi: adakah instans ini memiliki alamat destinasi itu. Pool terowong yang dipotong daripada subnet orang lain gagal pada soalan itu, dan paket itu dibuang sebelum mana-mana laluan atau peraturan firewall dilihat.

Jadi arah dari klien ke VPC mempunyai dua keperluan berasingan, dan tiada satu pun merupakan arahan push. VM memerlukan julat alias yang meliputi pool terowong, dan itulah yang menjadikannya pemilik sah alamat tersebut. VPC memerlukan laluan yang menamakan VM sebagai next hop bagi setiap awalan yang dilindungi. Jika satu hilang, paket mati di tempat lain, sementara klien melihat kesunyian yang sama.

Baca kegagalan mengikut urutan itu, kerana dari sisi klien kedua-dua syarat kelihatan serupa. Terowong yang melaporkan bersambung sedangkan tiada apa menjawab ialah tanda masalah topologi, bukan cipher yang buruk.

Adakah instans memiliki pool terowong

Beri VM julat sekunder di dalam subnetnya sendiri, kemudian biarkan OpenVPN mengagihkan alamat tepat daripada julat itu. Pada instans yang alamat utamanya 10.156.0.10/20, alias /28 memisahkan pool daripada 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

Arahan server kemudian mesti menerangkan blok yang sama. Alamat pertamanya menjadi gateway terowong, dan alamat selebihnya diagihkan kepada klien. Di sini dua nombor menerangkan satu blok, satu rangkaian dan satu netmask, dan itulah sintaks pool yang masih dijangka OpenVPN.

server 10.156.1.0 255.255.255.240

Sahkan bahawa alamat itu benar-benar mendarat pada antara muka dan bukan hanya dalam konfigurasi OpenVPN. Fabric menyalurkan apa yang dilaporkan NIC, bukan apa yang dipercayai daemon. Satu arahan menyelesaikannya:

ip -4 addr show dev eth0

Alamat sekunder yang tidak pernah sampai ke eth0, atau pool yang bertindih dengan subnet lain, muncul kemudian sebagai kehilangan berselang-seli dan bukan sebagai ralat permulaan. Daemon bermula, klien bersambung, dan hanya sesetengah destinasi berkelakuan salah. Kekalkan julat alias kecil supaya pool mudah dikenali dalam jadual laluan. Jangan sekali-kali memotongnya daripada subnet yang sudah digunakan instans lain.

Beri next hop kepada trafik balik

Balasan daripada hos dalam VPC dialamatkan kepada alamat klien dalam pool terowong, yang tidak tergolong dalam mana-mana subnet yang dikenali VPC. Tanpa laluan untuk pool itu, balasan berhenti pada hop pertama yang tiada padanan, dan permintaan itu mungkin sudah berjaya di hujung 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

Laluan yang sama diperlukan untuk setiap awalan yang terletak di belakang klien dan bukan di dalam VPC. Awalan itu juga memerlukan entri iroute dalam fail ccd klien berkenaan. Entri itu ialah perakaunan di sisi pelayan: ia memberitahu pelayan klien mana yang memiliki awalan itu, dan ia tidak memasang apa-apa pada klien itu sendiri.

Simpan senarai push untuk sisi klien perbualan, kerana ia hanya menambah laluan pada mesin yang bersambung. Baris push untuk subnet VPC dan laluan VPC kembali ke pool ialah dua separuh daripada laluan yang sama, dan mana-mana separuh sahaja menghasilkan terowong yang membawa permintaan tetapi bukan balasan.

Firewall, penghantaran dan hop di antaranya

Firewall VPC menilai paket yang telah dinyahkapsul, jadi peraturan ingress mesti membenarkan pool terowong dan mana-mana awalan tapak yang sampai ke VM melalui jalan itu. Sikap tolak secara lalai gagal secara senyap di sini: paket dibuang selepas dinyahkapsul, dan log OpenVPN menunjukkan sesi yang sihat.

Pada mana-mana hos Linux yang menyalurkan dan bukan menamatkan, semak sama ada net.ipv4.ip_forward diaktifkan. Peraturan pemilikan juga terpakai di sana: mesin yang menyalurkan untuk subnet yang tidak dimilikinya membuang paket sama seperti VM. Baca nilainya sebelum menyalahkan terowong.

Apabila tepat satu awalan gagal

Kegagalan separa ialah kes yang paling mudah dibaca, kerana segala-galanya di laluan sudah terbukti. Mulakan dengan senarai laluan dan baca julat destinasi serta next hop entri yang sepatutnya meliputi awalan itu, kemudian baca keterangan instans dan bandingkan julat aliasnya dengan pool yang diagihkan pelayan.

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

Laluan yang hilang muncul sebagai tiada next hop untuk awalan itu, manakala alias yang hilang muncul sebagai paket yang dibuang pada antara muka; dari sisi klien kedua-duanya kelihatan serupa dan dalam dua keluaran itu sama sekali berbeza. Jika kedua-duanya ada, suspek yang tinggal ialah iroute ccd klien yang menuntut awalan itu.

Tuliskan empat nilai di sebelah terowong: julat alias, pool pelayan, awalan yang di-push, laluan VPC. Alias yang lapuk merosakkan setiap alamat pool, laluan yang lapuk merosakkan satu arah, push yang hilang menyembunyikan awalan daripada klien, dan iroute yang salah menghantar awalan kepada peer yang salah. Orang seterusnya yang menambah subnet memerlukan keempat-empatnya di satu tempat, dan nota itu lebih murah daripada malam itu.

Artikel berkaitan