Mengapa VPN Point-to-Site Azure tidak mengubah IP publik Anda

Saya menghubungkan klien Azure VPN di laptop Windows, membuka halaman gema alamat, dan melihat alamat publik yang sama dengan yang diberikan router rumah. Sementara itu jump box di 10.20.0.4 menjawab dan nama endpoint privat berhasil diselesaikan, jadi tunnel tidak rusak. Gateway point-to-site melakukan persis apa yang dikatakan konfigurasi bawaannya: membawa prefiks privat dan meninggalkan semua yang lain di tautan lokal. Mendapatkan alamat egress milik Azure adalah perubahan desain perutean, bukan perbaikan.

Apa yang diumumkan gateway secara bawaan

Gateway mendorong rute untuk ruang alamat jaringan virtual, ditambah jaringan peer tempat transit gateway diizinkan dan prefiks lokal yang dipelajari melalui koneksi site-to-site atau BGP. Tidak ada 0.0.0.0/0 dalam kumpulan itu. Sistem operasi Anda mempertahankan rute bawaannya di Wi-Fi atau Ethernet, jadi paket ke API publik tidak pernah masuk ke tunnel.

Alamat yang diterima klien di dalam tunnel adalah sewa privat dari kumpulan point-to-site. Alamat itu mengidentifikasi klien kepada sumber daya di VNet; itu bukan alamat yang bisa dilihat internet, dan tidak akan pernah muncul sebagai sumber permintaan keluar ke API SaaS. Entri daftar izin yang dibangun di sekitar sewa itu tidak dapat berfungsi, berapa lama pun Anda menunggu sampai muncul di log vendor.

Split tunnel dan tunneling paksa berdampingan

Hanya baris kedua yang mengubah alamat yang dilihat layanan jarak jauh. Semua hal lain dalam tabel itu adalah biaya dan permukaan operasional yang Anda terima ketika egress harus diperiksa atau diterjemahkan di dalam Azure. Jika seseorang meminta Anda membuat IP publik berubah, mereka meminta seluruh kolom kanan, bukan penyesuaian kecil pada klien.

Ada opsi tengah yang layak disebut sebelum Anda membangun ulang apa pun. VM proxy atau gateway di dalam VNet memberi Anda alamat sumber terkendali untuk aplikasi yang bisa diarahkan ke sana, tanpa memindahkan rute bawaan klien. Itu menjaga penjelajahan normal tetap lokal dan tetap memenuhi mitra yang hanya perlu satu panggilan API datang dari Azure. Opsi ini gagal ketika persyaratannya benar-benar tentang semua lalu lintas, karena apa pun yang mengabaikan pengaturan proxy tetap keluar secara lokal.

Buat tunnel membawa rute bawaan

Pada gateway jaringan virtual, cara yang didukung untuk mengarahkan semua lalu lintas internet klien ke tunnel adalah menambahkan rute kustom ke konfigurasi point-to-site. Dua bagian menutupi seluruh ruang IPv4, dan masing-masing lebih spesifik daripada rute bawaan lokal, jadi klien lebih memilihnya tanpa menghapus apa pun:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Baris itu bersifat ilustratif, bukan lengkap untuk disalin-tempel: ambil dulu objek gateway dengan Get-AzVirtualNetworkGateway dan gantikan GWOBJ dengannya, lalu pastikan SKU dan model penyebaran menerima rute kustom sebelum menjalankannya. Prefiks yang sama muncul di portal pada halaman konfigurasi point-to-site, yang merupakan tempat lebih aman untuk mengaturnya jika Anda belum membuat skrip gateway.

Mengubah prefiks tersebut membuat paket klien tidak valid. Unduh ulang paket klien VPN dan pasang ulang, karena rute ikut di dalam profil. Klien yang menyambung ulang dengan profil lamanya mempertahankan kumpulan rute lama, dan Anda bisa kehilangan satu jam men-debug perubahan yang tidak pernah sampai kepadanya.

Di hub WAN virtual yang aman, padanannya adalah rute bawaan di tabel rute hub yang terkait dengan gateway point-to-site, dengan Azure Firewall di hub mengambil lalu lintasnya. Firewall menerjemahkan koneksi menuju internet ke alamat IP publiknya sendiri, dan dari terjemahan itulah alamat egress baru berasal. Ketika sebuah firewall memiliki beberapa IP publik, salah satunya bisa muncul sebagai sumber, jadi daftar izin harus memuat semuanya.

Kedua desain di atas adalah IPv4. Dua prefiks /1 tidak melakukan apa pun untuk IPv6, dan dukungan IPv6 point-to-site cukup sempit sehingga Anda harus menguji kombinasinya sebelum menjanjikan paritas.

Periksa rutenya, lalu periksa keluarnya

Setelah memasang ulang paket dan menyambung ulang, pastikan klien benar-benar memasang kedua bagiannya. Di Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 dan kueri yang sama untuk 128.0.0.0/1 harus menyebut antarmuka tunnel, dan route print menampilkan keduanya di samping rute bawaan asli Anda. Di Linux, ip route show harus mencantumkan dua prefiks itu; jika tidak, profil tidak pernah membawanya.

Lalu periksa ulang alamat publik dari klien dan baca log firewall untuk koneksi yang sama. Sumbernya seharusnya IP publik firewall dengan port yang diterjemahkan. Klien yang masih keluar secara lokal padahal kedua rute ada berarti paket mencapai Azure dan keluar lewat jalur lain: rute yang ditentukan pengguna di subnet gateway, firewall yang sendiri dipaksa tunnel ke jaringan lokal, atau kebijakan yang menjatuhkan aliran sebelum terjemahan.

Uji ulang satu tujuan privat di sesi yang sama. Host jump yang berhenti menjawab setelah perubahan adalah tanda biasa bahwa prefiks baru menggeser sesuatu, entah rute lokal yang lebih sempit yang sebelumnya diumumkan atau resolusi nama yang kini menuju resolver tanpa penerus untuk zona privat Anda.

Kapan membiarkan split tunnel apa adanya

Jika tujuannya hanya menjangkau API privat, endpoint privat, atau halaman admin internal, perilaku bawaan lebih murah dan lebih tenang. Tunneling paksa menambah jam firewall dan biaya pemrosesan data, jalur lebih panjang, dan satu tempat lagi di mana setiap aliran klien bisa gagal. Itu juga menangkap jauh lebih banyak lalu lintas daripada satu tujuan yang Anda pedulikan.

Gunakan itu ketika persyaratan dinyatakan dalam hal egress: mitra harus melihat alamat Azure tetap, keamanan ingin koneksi dicatat dan diperiksa, atau data harus keluar melalui satu titik terkendali. Bahkan saat itu desain memberi setiap pengguna satu keluaran bersama, jadi akuntabilitas per pengguna harus datang dari identitas di aplikasi, bukan dari alamat sumber.

Sebelum menutup perubahan, pastikan empat hal: paket klien yang terpasang adalah yang baru, kedua rute /1 berada di antarmuka tunnel, tujuan privat masih menjawab, dan log layanan jarak jauh menunjukkan alamat firewall.