Trafik balik Azure P2S VPN hanya berfungsi satu arah

Ikon tunnel hijau, NSG kelihatan membenarkan, laluan berkesan kelihatan betul, namun VM masih tidak boleh membuka sambungan kembali kepada klien yang disambungkan. Andaian biasa ialah tunnel point-to-site yang berfungsi adalah simetri: jika klien boleh sampai ke VM, VM boleh sampai ke klien. Andaian itulah kesilapan dalam penaakulan, bukan dalam konfigurasi. Tunnel boleh membawa satu arah aliran yang tidak diminta dan menggugurkan arah yang lain, dan pembaikan bergantung pada lapisan mana yang menggugurkannya.

Mitos: tunnel yang bersambung ialah tunnel dua hala

Tunnel VPN ialah laluan dasar, bukan wayar. Setiap arah dipadankan dengan pemilih, laluan dan penapis, dan mana-mana daripadanya boleh membenarkan satu arah sambil menyekat arah yang lain.

Dalam amalan asimetri cukup biasa sehingga arah patut berada dalam ujian pertama, bukan yang terakhir. Klien memulakan, gateway menjejaki aliran, dan balasan mengikut keadaan yang dicipta. VM yang memulakan aliran baharu tiada keadaan sedemikian, jadi ia bergantung pada laluan balik yang boleh dihalakan dan dibenarkan secara jelas. Apabila laluan itu tiada, percubaan sambungan mati sebelum mana-mana aplikasi melihatnya.

Uji arah sebelum menguji kebolehcapaian

Pilih satu alamat klien, satu alamat VM dan satu protokol. Sambung dari klien dan catat hasilnya; kemudian mulakan ujian yang sama dari VM dan catat juga. Jika yang pertama berjaya dan yang kedua gagal, kumpulan klien, perkaitan gateway dan laluan klien ke VNet semuanya berfungsi.

Langkah seterusnya ialah bukti, bukan lebih banyak peraturan. Periksa NSG pada subnet VM dalam kedua-dua arah, baca laluan berkesan pada NIC VM, dan tangkap paket pada VM semasa klien menghantar trafik. Permintaan yang tiba tanpa balasan ialah masalah penapis atau laluan balik; permintaan yang tidak pernah tiba ialah masalah laluan. Jangan anggap ping yang gagal sebagai bukti VM tidak boleh dicapai, kerana dasar ICMP boleh menggugurkan balasan semasa TCP berfungsi.

Laluan balik IKEv2 point-to-site ialah suspek biasa

Dalam laporan Azure di sebalik artikel ini, klien boleh sampai ke VM melalui IKEv2, tetapi ICMP masuk dari VM ke klien gagal sehingga jenis tunnel gateway ditukar kepada OpenVPN. Pelapor menyatakan Microsoft telah mengesahkan had dalam laluan IKEv2 point-to-site, di mana trafik balik dari VM ke klien tidak dihalakan secara simetri melainkan klien memulakan sesi. IKEv2 bergantung pada pemilih trafik, dan gateway tidak menghormati arah balik dalam kes itu.

Itu tidak menjadikan OpenVPN jenis tunnel yang lebih baik secara umum. Ia menjadikan jenis tunnel sebagai pemboleh ubah dalam matriks ujian untuk beban kerja ini.

Menukar jenis tunnel ialah perubahan perkhidmatan, bukan suis. Setiap klien memerlukan profil yang serasi, dan gateway mungkin memerlukan sijil atau persediaan pengesahan yang berbeza. Hasilkan semula tingkah laku satu arah dengan satu klien ujian dan satu VM ujian, tukar jenis mengikut jadual yang diluluskan, dan kemudian ulangi ujian arah yang sama. Jika tingkah laku itu kekal selepas pertukaran, jenis tunnel bukan puncanya dan anda telah menyempitkan masalah tanpa menyentuh pengeluaran.

Mitos: penemuan melalui broadcast melintasi sempadan VNet

Andaian kedua gagal atas sebab yang tidak berkaitan. Rangkaian maya Azure tidak membawa trafik broadcast, jadi VM tidak boleh menerima bingkai broadcast dari rangkaian tempatan melalui sambungan site-to-site atau point-to-site. Aplikasi yang menemui rakan melalui broadcast, seperti pelayaran fail lama atau sesetengah protokol penemuan peranti, tidak akan pernah melihat bahagian jauh, tidak kira bagaimana laluan ditulis.

Gantikan penemuan broadcast dengan nama DNS, perkhidmatan direktori atau senarai rakan yang jelas. Jika aplikasi tiada alternatif unicast, reka bentuk memerlukan mekanisme penemuan yang berbeza, bukan tunnel yang lebih lebar.

Apa yang perlu diubah, dan bagaimana membuktikannya

Jika ujian arah gagal hanya pada IKEv2, catat jenis tunnel gateway, kumpulan alamat klien dan ujian ICMP atau TCP yang tepat, kemudian nilai profil OpenVPN yang diluluskan untuk klien terjejas. Jika ia gagal pada setiap jenis tunnel, kerjakan laluan balik: alamat klien mesti boleh dihalakan dari subnet VM, mana-mana laluan yang ditentukan pengguna mesti menunjuk ke hop seterusnya yang sah, dan firewall klien mesti menerima aliran masuk. Lampirkan bukti NSG dan laluan pada tiket.

Sahkan dengan aplikasi, bukan dengan ping. Pertukaran ICMP yang berjaya selepas perubahan tidak memberitahu apa-apa tentang port perkhidmatan, pengesahannya atau penyelesaian namanya. Ulangi ujian selepas menyambung semula, kerana klien yang menerima alamat kumpulan berbeza boleh mengubah hasilnya. Kemudian ulangi sekali lagi selepas klien tidur dan bangun, kerana dalam sesi yang disambung semula tingkah laku satu arah sering muncul semula.