Mengapa VPN Point-to-Site Azure tidak menukar IP awam anda

Saya menyambungkan klien Azure VPN pada komputer riba Windows, membuka halaman gema alamat dan melihat alamat awam yang sama yang diberikan oleh penghala rumah saya. Sementara itu kotak lompat di 10.20.0.4 menjawab dan nama titik akhir peribadi diselesaikan, jadi terowong tidak rosak. Gateway point-to-site melakukan tepat apa yang dikatakan konfigurasi lalainya: membawa awalan peribadi dan meninggalkan segala-galanya pada pautan setempat. Mendapatkan alamat keluar milik Azure ialah perubahan reka bentuk penghalaan, bukan pembaikan.

Apa yang gateway umumkan secara lalai

Gateway menolak laluan untuk ruang alamat rangkaian maya, serta rangkaian rakan setara di mana transit gateway dibenarkan dan awalan setempat yang dipelajari melalui sambungan situs-ke-situs atau BGP. Tiada 0.0.0.0/0 dalam set itu. Sistem pengendalian anda menyimpan laluan lalainya pada Wi-Fi atau Ethernet, jadi paket ke API awam tidak pernah masuk ke terowong.

Alamat yang diterima klien di dalam terowong ialah pajakan peribadi daripada kumpulan point-to-site. Ia mengenal pasti klien kepada sumber dalam VNet; ia bukan alamat yang boleh dilihat internet, dan ia tidak akan muncul sebagai sumber permintaan keluar ke API SaaS. Entri senarai benarkan yang dibina di sekitar pajakan itu tidak boleh berfungsi, walau berapa lama anda menunggu ia muncul dalam log vendor.

Terowong berpecah dan terowong paksa bersebelahan

Hanya baris kedua menukar alamat yang dilihat oleh perkhidmatan jauh. Semua yang lain dalam jadual itu ialah kos dan permukaan operasi yang anda terima apabila egress perlu diperiksa atau diterjemah di dalam Azure. Jika seseorang meminta anda menukar IP awam, dia meminta seluruh lajur kanan, bukan pelarasan kecil pada klien.

Terdapat pilihan pertengahan yang wajar dinamakan sebelum anda membina semula apa-apa. VM proksi atau gateway di dalam VNet memberikan alamat sumber terkawal untuk aplikasi yang boleh dihalakan ke sana, tanpa memindahkan laluan lalai klien. Ini mengekalkan pelayaran biasa secara setempat dan masih memenuhi rakan kongsi yang hanya memerlukan satu panggilan API datang dari Azure. Ia gagal apabila keperluan itu benar-benar tentang semua trafik, kerana apa-apa yang mengabaikan tetapan proksi tetap keluar secara setempat.

Jadikan terowong membawa laluan lalai

Pada gateway rangkaian maya, cara yang disokong untuk menghalakan semua trafik internet klien ke terowong ialah menambah laluan tersuai pada konfigurasi point-to-site. Dua separuh meliputi seluruh ruang IPv4, dan setiap satu lebih spesifik daripada laluan lalai setempat, jadi klien lebih mengutamakannya tanpa memadam apa-apa:

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

Baris itu bersifat ilustrasi dan bukan lengkap untuk disalin tampal: dapatkan objek gateway dahulu dengan Get-AzVirtualNetworkGateway dan gantikan GWOBJ dengannya, dan sahkan SKU serta model penggunaan menerima laluan tersuai sebelum menjalankannya. Awalan yang sama muncul dalam portal pada halaman konfigurasi point-to-site, iaitu tempat yang lebih selamat untuk menetapkannya jika anda belum lagi menskrip gateway.

Menukar awalan tersebut menjadikan pakej klien tidak sah. Muat turun semula pakej klien VPN dan pasang semula, kerana laluan bergerak di dalam profil. Klien yang menyambung semula dengan profil lamanya mengekalkan set laluan lama, dan anda boleh kehilangan satu jam menyahpepijat perubahan yang tidak pernah sampai kepadanya.

Dalam hab WAN maya yang selamat, yang setara ialah laluan lalai dalam jadual laluan hab yang dikaitkan dengan gateway point-to-site, dengan Azure Firewall di hab mengambil trafik. Tembok api menterjemah sambungan ke arah internet kepada alamat IP awamnya sendiri, dan daripada terjemahan itulah alamat keluar baharu datang. Apabila tembok api mempunyai beberapa IP awam, mana-mana daripadanya boleh muncul sebagai sumber, jadi senarai benarkan mesti mengandungi semuanya.

Kedua-dua reka bentuk di atas ialah IPv4. Dua awalan /1 tidak melakukan apa-apa untuk IPv6, dan sokongan IPv6 point-to-site cukup sempit sehingga anda perlu menguji gabungan itu sebelum menjanjikan pariti.

Semak laluan, kemudian semak jalan keluar

Selepas memasang semula pakej dan menyambung semula, sahkan klien benar-benar memasang kedua-dua separuh. Pada Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 dan pertanyaan yang sama untuk 128.0.0.0/1 sepatutnya menamakan antara muka terowong, dan route print menunjukkan kedua-duanya di sebelah laluan lalai asal anda. Pada Linux, ip route show mesti menyenaraikan dua awalan itu; jika tidak, profil tidak pernah membawanya.

Kemudian semak semula alamat awam dari klien dan baca log tembok api untuk sambungan yang sama. Sumbernya sepatutnya IP awam tembok api dengan port yang diterjemah. Klien yang masih keluar secara setempat sedangkan kedua-dua laluan wujud bermakna paket sampai ke Azure dan keluar melalui laluan lain: laluan yang ditentukan pengguna pada subnet gateway, tembok api yang sendiri dipaksa terowong ke rangkaian setempat, atau dasar yang menggugurkan aliran sebelum terjemahan.

Uji semula satu destinasi peribadi dalam sesi yang sama. Hos lompat yang berhenti menjawab selepas perubahan ialah tanda biasa bahawa awalan baharu telah menolak sesuatu, sama ada laluan setempat yang lebih sempit yang diumumkan sebelum ini atau penyelesaian nama yang kini pergi ke penyelesai tanpa pemaju untuk zon peribadi anda.

Bila perlu membiarkan terowong berpecah

Jika matlamatnya hanya untuk mencapai API peribadi, titik akhir peribadi atau halaman admin dalaman, tingkah laku lalai lebih murah dan lebih senyap. Terowong paksa menambah jam tembok api dan caj pemprosesan data, laluan yang lebih panjang, dan satu lagi tempat di mana setiap aliran klien boleh gagal. Ia juga menangkap lebih banyak trafik daripada satu destinasi yang anda pedulikan.

Gunakannya apabila keperluan dinyatakan dari segi egress: rakan kongsi mesti melihat alamat Azure yang tetap, keselamatan mahu sambungan dilog dan diperiksa, atau data mesti keluar melalui satu titik terkawal. Walaupun begitu reka bentuk memberi setiap pengguna jalan keluar yang dikongsi, jadi akauntabiliti setiap pengguna mesti datang daripada identiti dalam aplikasi, bukan daripada alamat sumber.

Sebelum menutup perubahan, sahkan empat perkara: pakej klien yang dipasang ialah yang baharu, dua laluan /1 berada pada antara muka terowong, destinasi peribadi masih menjawab, dan log perkhidmatan jauh menunjukkan alamat tembok api.