IP statik dalam Azure P2S VPN: mengapa alamat klien berubah

Setiap klien Azure point-to-site menerima alamat daripada kumpulan apabila ia mengesahkan identiti, dan menyimpannya hanya sepanjang hayat sambungan itu. Tiada jadual tempahan, tiada pemetaan setiap pengguna, dan tiada tetapan gerbang yang bermaksud “selalu beri orang ini 172.16.0.10”. Mekanisme tunggal itulah yang menjelaskan kedua-dua gejala yang orang temui kemudian: peraturan NSG yang berhenti sepadan dengan pengguna yang pernah sepadan, dan senarai kebenaran yang senyap meluluskan mesin yang tiada siapa tambah dengan sengaja. Menggantikan peraturan itu dengan peraturan IP yang lebih pintar tidak membaiki kedua-duanya, kerana perkara yang dinamakan oleh peraturan itu diperuntukkan semula mengikut jadual yang anda tidak kawal.

Kumpulan itu kapasiti, bukan identiti. Ia wujud supaya terowong serentak mendapat alamat unik, dan ia mengitar semula alamat itu pada saat pajakan tamat. Apabila itu jelas, soalan yang berguna berhenti menjadi “bagaimana saya menyemat klien ini” dan menjadi “terhadap apa saya boleh menulis peraturan yang tidak akan dikitar semula oleh gerbang”.

Apa yang sebenarnya dilakukan gerbang apabila klien bersambung

Gerbang menyimpan kumpulan alamat klien yang dikonfigurasikan dan menganggapnya sebagai jadual pajakan. Semasa bersambung ia mengambil alamat bebas seterusnya, dalam praktiknya yang terendah tersedia, dan menetapkannya kepada penyesuai terowong sehingga klien terputus atau pajakan tamat. Urutan yang menentukan, bukan identiti: sesiapa yang bersambung semula dahulu selepas tempoh tenang mendapat alamat terendah yang kebetulan bebas pada masa itu.

Saiz kumpulan menyembunyikan tingkah laku itu. Kumpulan makmal yang satu atau dua alamat lebih besar daripada bilangan penguji kelihatan deterministik, kerana komputer riba yang sama cenderung bersambung semula dalam urutan yang sama setiap pagi. Tambah mesin ketiga, ubah saiz kumpulan, atau biarkan sesi bersambung sepanjang makan tengah hari, dan corak itu pecah. Alamat itu tidak pernah stabil; baris gilir yang stabil.

Sebarang perubahan pada konfigurasi point-to-site juga menetapkan semula ruang pajakan. Jenis pengesahan yang berbeza, kumpulan yang diubah saiznya, julat kumpulan baharu, atau gerbang yang dirobohkan dan dibina semula semuanya menghantar klien kembali ke kumpulan yang tidak lagi sepadan dengan alamat lama mereka. Tiada apa dalam perubahan itu menyentuh NSG anda, sebab itulah kerosakan kelihatan spontan.

Anda boleh melihatnya berlaku dalam kira-kira seminit. Sambung, catat alamat terowong dalam butiran sambungan klien, putuskan, sambungkan mesin kedua, kemudian sambung semula yang pertama. Alamat yang anda dapat kembali bergantung pada apa yang dipegang oleh mesin kedua, dan tiada tetapan portal akan memulihkan yang sebelumnya atas permintaan.

NSG yang berkunci pada IP klien sebenarnya ialah peraturan tentang urutan sambungan

Peraturan yang orang tulis dahulu ialah yang jelas: peraturan masuk pada NIC VM pengurusan atau pada subnya, dengan alamat dalaman klien VPN sebagai sumber. Ia pendek, ia lulus ujian pada hari ia ditulis, dan ia gagal sebaik sahaja kumpulan mempunyai lebih daripada satu alamat bebas.

Daripada itu timbul dua mod kegagalan, dan hanya satu kelihatan seperti pepijat. Pengguna sah ditolak kerana orang lain sedang memegang alamat yang dinamakan oleh peraturan itu, dan itu tiba sebagai tiket sokongan yang menjengkelkan. Atau pengguna yang tidak dimaksudkan diluluskan kerana dia mewarisi alamat yang masih dipercayai oleh peraturan itu, dan itu tidak tiba sebagai apa-apa sehingga seseorang mengaudit akses.

Kerana peraturan mengikut pajakan, dasar berkesan berbunyi “orang pertama yang bersambung mendapat akses pengurusan”. Itu huraian urutan sambungan yang berpakaian niat, dan tiada kebersihan peraturan menjadikannya ungkapan niat.

Pajakan klien dan alamat gerbang ialah objek yang berbeza

Sebahagian besar kekeliruan datang daripada satu perkataan. Gerbang mempunyai IP awam yang agak stabil; klien mempunyai alamat peribadi daripada kumpulan yang tidak stabil. Bagi gerbang VPN yang tidak berlebihan zon, IP awam diperuntukkan secara dinamik, tetapi ia bertahan melalui perubahan saiz, set semula dan penyelenggaraan rutin — ia berubah apabila gerbang itu sendiri dipadam dan dicipta semula. SKU gerbang berlebihan zon dan zon menggunakan IP awam SKU Standard, dan peruntukan itu mesti statik.

Kestabilan itulah yang diperlukan oleh rakan setara di premis dalam konfigurasinya, dan ia tidak berkata apa-apa tentang mengenal pasti klien individu. Apabila rakan kongsi bertanya alamat mana yang akan mereka lihat, jawapannya ialah IP awam gerbang di bawah site-to-site, atau julat NAT dikongsi — tidak pernah pajakan terowong komputer riba.

Kumpulan kumpulan memberi anda julat yang berbaloi untuk ditulis peraturan

Virtual WAN point-to-site menyokong kumpulan pengguna, dan setiap kumpulan boleh diberi kumpulan alamat kliennya sendiri. Keahlian ditentukan oleh identiti, jadi julat tempat klien mendarat menjadi boleh diramal: operasi dalam satu julat, kontraktor dalam julat lain, dan julat itu sesuatu yang boleh dinamakan oleh peraturan tembok api atau NSG tanpa meneka.

Set peraturan yang terhasil mempunyai bentuk yang boleh anda semak:

• satu kumpulan bagi setiap khalayak, bersaiz untuk puncak sesi serentak dan bukan bilangan orang;
• keahlian kumpulan dikendalikan melalui identiti, bukan dengan menyunting peraturan setiap kali seseorang menyertai;
• peraturan NSG atau Azure Firewall ditulis terhadap julat kumpulan, tidak pernah terhadap pajakan individu;
• hab atau gerbang berasingan untuk khalayak yang tidak boleh berkongsi julat.

Meletakkan seluruh kumpulan dalam senarai kebenaran adalah jujur tetapi kasar: setiap klien bersambung dalam julat itu mendapat akses yang sama. Itu keputusan dasar yang wajar diucapkan dengan lantang dan bukan ditemui semasa semakan. Apa-apa yang masih memerlukan jawapan setiap orang tergolong pada sumber melalui penetapan peranan, bukan pada penapis paket.

Apabila penggunaan tidak boleh beralih ke Virtual WAN

Banyak gerbang kekal sebagai gerbang VPN biasa, dan beralih ke Virtual WAN bukan perubahan kecil. Jawapan praktikalnya ialah memindahkan keputusan setiap pengguna daripada penapis paket kepada sesuatu yang sudah tahu siapa pengguna itu.

Identiti pada peringkat sumber ialah versi paling murah. Storage, SQL dan Key Vault semuanya menyokong pengesahan Entra ID dengan penetapan peranan setiap pengguna atau setiap kumpulan, jadi VPN hanya perlu membuktikan kebolehcapaian rangkaian. Hos lompat dengan akaun bernama melakukan kerja yang sama untuk tugas pentadbiran, kerana hos merekodkan manusia dan terowong hanya membawa paket. Mendaftarkan klien dalam DNS dan membenarkan nama dan bukan nombor mengangkat peraturan satu lapisan. Identiti lapisan aplikasi — subjek sijil, tuntutan token, keahlian kumpulan — berfungsi apabila aplikasi, bukan rangkaian, yang diminta membuat keputusan.

Bagi rakan kongsi yang berkeras pada alamat sumber tetap, jawapannya ialah site-to-site atau ExpressRoute dengan awalan rakan setara yang ditentukan. Mereka membenarkan awalan itu, alamat yang muncul di sebelah mereka milik gerbang, dan ia tidak berubah apabila seseorang memulakan semula komputer riba.

Periksa kumpulan sebelum anda menyunting senarai kebenaran yang lain

Dua sifat kumpulan menyebabkan sebahagian besar tingkah laku yang orang salahkan pada klien. Kumpulan yang terlalu kecil mengitar semula pajakan dengan cepat, jadi alamat kelihatan sentiasa bergerak dan mana-mana peraturan berasaskan alamat kelihatan tidak stabil secara reka bentuk. Kumpulan yang bertindih dengan julat di premis atau ruang alamat rangkaian maya mencipta kekaburan penghalaan yang tidak dibaiki oleh mana-mana peraturan tembok api.

Letakkan tiga perkara pada satu halaman sebelum menyentuh peraturan: kumpulan point-to-site, ruang alamat rangkaian maya dan julat di premis. Ia tidak boleh bertindih, dan kumpulan memerlukan ruang untuk setiap klien serentak serta margin untuk sambungan semula.

Kemudian tutup gelung dalam urutan ini:

• Sambung daripada dua mesin dalam kedua-dua urutan dan bandingkan alamatnya; jika ia boleh bertukar, tiada peraturan berasaskan alamat yang selamat.
• Periksa sama ada gerbang itu Virtual WAN; jika ya, gunakan kumpulan kumpulan dan bukan peraturan setiap alamat.
• Tanya apa yang berlaku apabila peraturan mengenai orang yang salah; jika jawapannya ialah insiden akses, pindahkan kawalan kepada identiti.
• Catat julat mana milik kumpulan mana dalam repositori yang sama dengan takrif NSG.
• Uji semula selepas setiap perubahan kumpulan, pengesahan atau gerbang, kerana perubahan itu menulis semula pemetaan tanpa mengumumkannya.