Lalu lintas balik Azure P2S VPN hanya berfungsi satu arah

Ikon tunnel hijau, NSG tampak permisif, rute efektif tampak benar, tetapi VM tetap tidak dapat membuka koneksi kembali ke klien yang terhubung. Asumsi umum adalah bahwa tunnel point-to-site yang berfungsi bersifat simetris: jika klien dapat menjangkau VM, VM dapat menjangkau klien. Asumsi itu adalah kesalahan penalaran, bukan kesalahan konfigurasi. Tunnel dapat membawa satu arah dari aliran yang tidak diminta dan menjatuhkan arah lainnya, dan perbaikannya bergantung pada lapisan mana yang menjatuhkannya.

Mitos: tunnel yang terhubung adalah tunnel dua arah

Tunnel VPN adalah jalur kebijakan, bukan kabel. Setiap arah dicocokkan dengan selektor, rute, dan filter, dan salah satunya dapat mengizinkan satu arah sambil memblokir arah lainnya.

Dalam praktiknya asimetri cukup umum sehingga arah masuk ke pengujian pertama, bukan terakhir. Klien yang memulai, gateway melacak aliran, dan balasan mengikuti status yang dibuat. VM yang memulai aliran baru tidak memiliki status seperti itu, jadi bergantung pada jalur balik yang secara eksplisit dapat dirutekan dan diizinkan. Ketika jalur itu tidak ada, upaya koneksi mati sebelum aplikasi mana pun melihatnya.

Uji arah sebelum menguji keterjangkauan

Pilih satu alamat klien, satu alamat VM, dan satu protokol. Hubungkan dari klien dan catat hasilnya; lalu mulai pengujian yang sama dari VM dan catat juga. Jika yang pertama berhasil dan yang kedua gagal, kumpulan klien, asosiasi gateway, dan jalur klien ke VNet semuanya berfungsi.

Langkah berikutnya adalah bukti, bukan aturan tambahan. Periksa NSG pada subnet VM di kedua arah, baca rute efektif pada NIC VM, dan tangkap paket di VM saat klien mengirim lalu lintas. Permintaan yang datang tanpa balasan adalah masalah filter atau rute balik; permintaan yang tidak pernah datang adalah masalah jalur. Jangan anggap ping yang gagal sebagai bukti bahwa VM tidak terjangkau, karena kebijakan ICMP dapat menjatuhkan balasan saat TCP berfungsi.

Jalur balik IKEv2 point-to-site adalah tersangka yang biasa

Dalam laporan Azure di balik artikel ini, klien dapat menjangkau VM melalui IKEv2, tetapi ICMP masuk dari VM ke klien gagal sampai jenis tunnel gateway dialihkan ke OpenVPN. Pelapor menyatakan bahwa Microsoft mengonfirmasi keterbatasan pada jalur IKEv2 point-to-site, di mana lalu lintas balik dari VM ke klien tidak dirutekan secara simetris kecuali klien yang memulai sesi. IKEv2 bergantung pada selektor lalu lintas, dan gateway tidak menghormati arah balik dalam kasus itu.

Itu tidak membuat OpenVPN menjadi jenis tunnel yang lebih baik secara umum. Itu membuat jenis tunnel menjadi variabel dalam matriks pengujian untuk beban kerja ini.

Mengganti jenis tunnel adalah perubahan layanan, bukan sakelar. Setiap klien memerlukan profil yang kompatibel, dan gateway mungkin memerlukan sertifikat atau penyiapan autentikasi yang berbeda. Reproduksi perilaku satu arah dengan satu klien uji dan satu VM uji, ubah jenisnya sesuai jadwal yang disetujui, lalu ulangi pengujian arah yang sama. Jika perilaku itu bertahan setelah pergantian, jenis tunnel bukan penyebabnya dan Anda telah mempersempit masalah tanpa menyentuh produksi.

Mitos: penemuan broadcast melintasi batas VNet

Asumsi kedua gagal karena alasan yang tidak terkait. Jaringan virtual Azure tidak membawa lalu lintas broadcast, sehingga VM tidak dapat menerima frame broadcast dari jaringan lokal melalui koneksi site-to-site atau point-to-site. Aplikasi yang menemukan rekan melalui broadcast, seperti penelusuran file lama atau beberapa protokol penemuan perangkat, tidak akan pernah melihat sisi jauh, tidak peduli bagaimana rutenya ditulis.

Ganti penemuan broadcast dengan nama DNS, layanan direktori, atau daftar rekan yang eksplisit. Jika aplikasi tidak memiliki alternatif unicast, desainnya memerlukan mekanisme penemuan yang berbeda, bukan tunnel yang lebih lebar.

Apa yang harus diubah, dan bagaimana membuktikannya

Jika pengujian arah gagal hanya pada IKEv2, catat jenis tunnel gateway, kumpulan alamat klien, dan pengujian ICMP atau TCP yang tepat, lalu evaluasi profil OpenVPN yang disetujui untuk klien yang terdampak. Jika gagal pada semua jenis tunnel, kerjakan jalur balik: alamat klien harus dapat dirutekan dari subnet VM, setiap rute yang ditentukan pengguna harus menunjuk ke hop berikutnya yang valid, dan firewall klien harus menerima aliran masuk. Lampirkan bukti NSG dan rute ke tiket.

Verifikasi dengan aplikasi, bukan dengan ping. Pertukaran ICMP yang berhasil setelah perubahan tidak mengatakan apa pun tentang port layanan, autentikasinya, atau resolusi namanya. Ulangi pengujian setelah menyambung ulang, karena klien yang menerima alamat kumpulan berbeda dapat mengubah hasilnya. Lalu ulangi sekali lagi setelah klien tidur dan bangun, karena dalam sesi yang dilanjutkan perilaku satu arah sering muncul kembali.