Dua IP publik pada satu VM VPN Azure: mana yang melakukan apa

Dua IP publik pada satu VM VPN Azure menciptakan harapan yang jarang terpenuhi: alamat yang dihubungi klien juga akan menjadi alamat yang dilihat situs web. Tiga keputusan independen menghasilkan hasil itu, dan hanya yang pertama menyangkut pendengar tunnel. Yang kedua adalah sumber tamu yang dipakai untuk lalu lintas klien yang diteruskan, dan yang ketiga adalah metode keluar Azure yang berlaku untuk sumber itu. Ubah satu dan dua lainnya tetap di tempatnya, jadi putuskan masing-masing secara eksplisit.

Keputusan 1: di mana tunnel berakhir

IP publik Azure dikaitkan dengan konfigurasi IP privat pada NIC; itu bukan alamat yang Anda tambahkan di dalam sistem operasi tamu. Baca pemetaannya alih-alih mengasumsikannya: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Alamat privat apa pun yang dikembalikan kueri itu adalah yang harus benar-benar dipegang tamu.

Satu NIC dapat membawa beberapa konfigurasi IP, jadi dua alamat publik tidak memerlukan dua NIC. Jika desain memang memakai dua NIC, masing-masing membawa rute tamu dan hop berikutnya sendiri, dan Anda telah menambahkan keputusan routing alih-alih menyederhanakannya.

Untuk layanan dengan pengikatan lokal eksplisit, ikat ke alamat privat tamu yang sebenarnya, jangan pernah ke placeholder publik. Pendengar yang menerima semua alamat menerima lalu lintas melalui setiap konfigurasi IP yang mencapainya, jadi batasi masuk dengan grup keamanan jaringan dan firewall host alih-alih berharap urutan pengikatan yang menentukan.

Keputusan 2: sumber mana yang dipakai klien yang diteruskan

Setelah gateway mendekripsi permintaan klien, paket yang diteruskannya berbeda dari paket yang tiba di pendengar VPN. Tamu memerlukan penerusan aktif, kebijakan firewall yang mengizinkan aliran, dan alamat sumber yang diizinkan desain cloud. Jika Anda menerjemahkan alamat internal klien, sumber terjemahan itulah yang dievaluasi Azure, bukan alamat internal klien.

Aturan SNAT yang sempit dapat memilih sumber privat tamu, tetapi tidak dapat mengalahkan terjemahan Azure di hilir. Pilih SNAT saat Anda memerlukan akuntabilitas per klien di dalam VM; lewati saat desain keluar subnet sudah menyediakan sumber publik yang stabil dan terjemahan kedua hanya akan menambah status.

Keputusan 3: metode keluar Azure mana yang menang

Microsoft mendokumentasikanurutan prioritas keluar: rute yang berlaku ke perangkat atau gateway diprioritaskan, dan konektivitas subnet melalui NAT Gateway diprioritaskan di atas IP publik tingkat instans pada jalur yang relevan. Urutan itulah sebabnya menerjemahkan ke 10.20.0.5 tidak membuktikan bahwa situs web akan melihat 198.51.100.20. Baca tabel rute efektif, asosiasi NAT Gateway, dan IP publik NIC bersama-sama sebelum menerima desain keluar.

Pisahkanpengaturan penerusan NIC Azuredari penerusan Linux. Bendera cloud mengizinkan paket yang sumber atau tujuannya tidak ditetapkan ke NIC; itu tidak mengaktifkan net.ipv4.ip_forward, dan pengaturan tamu tidak memberikan izin cloud.

Socket tunnel punya keputusan sumbernya sendiri

Address WireGuard di bawah wg-quick menetapkan alamat ke antarmuka WireGuard; itu bukan instruksi pengikatan UDP luar. Sumber socket terenkripsi mengikuti tabel rute, jadi rute kebijakan atau rute default kedua dapat memindahkannya tanpa menyentuh alamat antarmuka.OpenVPN: opsi local dan UDP multihome berperilaku sama: keduanya menyangkut pendengar dan balasannya, bukan sumber internet setiap klien yang diteruskan.

Pertahankan rute lapisan bawah yang membawa tunnel, dan pastikan klien masih menerima balasan terautentikasi dari susunan masuk yang diharapkan. Jangan mengandalkan urutan daftar alamat sebagai kebijakan pemilihan sumber permanen, karena alamat berikutnya yang ditambahkan ke NIC dapat mengubah mana yang menang.

Apa yang harus diterima, dan dalam urutan apa

Terima tiga hasil secara terpisah. Pertama, klien eksternal mencapai masuk VPN yang dimaksud. Kedua, permintaan baru yang diizinkan dari klien VPN itu keluar melalui keluar internet yang terdokumentasi. Ketiga, jalur pendengar dan penerusan yang tidak diinginkan tetap ditolak. Catat pemetaan publik-ke-privat dan pemilik tamu serta cloud dari setiap keputusan di tempat yang sama.

Tunnel yang berhasil hanya membuktikan bagian pertama. Uji keluar dengan aliran baru, karena koneksi yang di-cache dapat terus memakai sumber lama jauh setelah rute berubah.