Dua IP awam pada satu VM VPN Azure: mana buat apa

Dua IP awam pada satu VM VPN Azure mencipta jangkaan yang jarang menjadi kenyataan: alamat yang disambungkan oleh klien juga akan menjadi alamat yang dilihat oleh laman web. Tiga keputusan bebas menghasilkan keputusan itu, dan hanya yang pertama berkaitan pendengar terowong. Yang kedua ialah sumber tetamu yang digunakan untuk trafik klien yang dipacu, dan yang ketiga ialah kaedah keluar Azure yang terpakai pada sumber itu. Tukar satu dan dua yang lain kekal di tempatnya, jadi tentukan setiap satu secara jelas.

Keputusan 1: di mana terowong berakhir

IP awam Azure dikaitkan dengan konfigurasi IP peribadi pada NIC; ia bukan alamat yang anda tambah di dalam sistem pengendalian tetamu. Baca pemetaan itu dan bukannya menganggapnya: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Alamat peribadi apa pun yang dikembalikan oleh pertanyaan itu ialah yang sebenarnya perlu dipegang oleh tetamu.

Satu NIC boleh membawa beberapa konfigurasi IP, jadi dua alamat awam tidak memerlukan dua NIC. Jika reka bentuk memang menggunakan dua NIC, setiap satu membawa laluan tetamu dan hop seterusnya sendiri, dan anda telah menambah keputusan penghalaan dan bukannya memudahkannya.

Untuk perkhidmatan dengan pengikatan setempat yang jelas, ikat pada alamat peribadi tetamu yang sebenar, tidak pernah pada pemegang tempat awam. Pendengar yang menerima semua alamat menerima trafik melalui setiap konfigurasi IP yang mencapainya, jadi hadkan kemasukan dengan kumpulan keselamatan rangkaian dan tembok api hos dan bukannya berharap urutan pengikatan yang menentukan.

Keputusan 2: sumber mana yang digunakan oleh klien yang dipacu

Selepas gerbang menyahsulit permintaan klien, paket yang dipacunya berbeza daripada paket yang tiba di pendengar VPN. Tetamu memerlukan pemacuan diaktifkan, dasar tembok api yang membenarkan aliran, dan alamat sumber yang dibenarkan oleh reka bentuk awan. Jika anda menterjemah alamat dalaman klien, sumber terjemahan itulah yang akan dinilai oleh Azure, bukan alamat dalaman klien.

Peraturan SNAT yang sempit boleh memilih sumber peribadi tetamu, tetapi ia tidak boleh mengatasi terjemahan Azure di hilir. Pilih SNAT apabila anda memerlukan akauntabiliti bagi setiap klien di dalam VM; langkauinya apabila reka bentuk keluar subnet sudah menyediakan sumber awam yang stabil dan terjemahan kedua hanya akan menambah keadaan.

Keputusan 3: kaedah keluar Azure mana yang menang

Microsoft mendokumenkanurutan keutamaan keluar: laluan yang terpakai ke perkakas atau gerbang diberi keutamaan, dan kesambungan subnet melalui NAT Gateway diberi keutamaan berbanding IP awam pada peringkat instans pada laluan berkenaan. Urutan inilah sebabnya menterjemah ke 10.20.0.5 tidak membuktikan bahawa laman web akan melihat 198.51.100.20. Baca jadual laluan berkesan, persatuan NAT Gateway dan IP awam NIC bersama-sama sebelum menerima reka bentuk keluar.

Pisahkantetapan pemacuan NIC Azuredaripada pemacuan Linux. Bendera awan membenarkan paket yang sumber atau destinasinya tidak diberikan kepada NIC; ia tidak mengaktifkan net.ipv4.ip_forward, dan tetapan tetamu tidak memberikan kebenaran awan.

Soket terowong mempunyai keputusan sumbernya sendiri

Address WireGuard di bawah wg-quick memberikan alamat kepada antara muka WireGuard; ia bukan arahan pengikatan UDP luar. Sumber soket yang disulitkan mengikut jadual laluan, jadi laluan dasar atau laluan lalai kedua boleh mengalihkannya tanpa menyentuh alamat antara muka.OpenVPN: pilihan local dan UDP multihome berkelakuan sama: ia berkaitan pendengar dan balasannya, bukan sumber internet setiap klien yang dipacu.

Kekalkan laluan lapisan bawah yang membawa terowong, dan sahkan klien masih menerima balasan yang disahkan daripada susunan masuk yang dijangka. Jangan bergantung pada urutan senarai alamat sebagai dasar pemilihan sumber kekal, kerana alamat seterusnya yang ditambah pada NIC boleh mengubah mana yang menang.

Apa yang perlu diterima, dan dalam urutan apa

Terima tiga keputusan secara berasingan. Pertama, klien luaran mencapai masuk VPN yang dimaksudkan. Kedua, permintaan baru yang dibenarkan daripada klien VPN itu keluar melalui keluar internet yang didokumenkan. Ketiga, laluan pendengar dan pemacuan yang tidak diniatkan kekal ditolak. Catat pemetaan awam-ke-peribadi dan pemilik tetamu serta awan bagi setiap keputusan di tempat yang sama.

Terowong yang berjaya hanya membuktikan bahagian pertama. Uji keluar dengan aliran baru, kerana sambungan yang dicache boleh terus menggunakan sumber lama lama selepas laluan berubah.