SSTP dan IKEv2 menggunakan kawalan sijil RRAS yang berbeza

Jika anda menggantikan «sijil VPN», anda mungkin menukar perkhidmatan yang salah. RRAS menyimpan sekurang-kurangnya tiga kawalan sijil, setiap satu milik protokol dan peranan sambungan yang berbeza. Menamakan protokol dahulu mengubah tekaan berisiko menjadi satu perubahan ikatan tunggal yang boleh diterbalikkan. Semua di bawah bergantung pada ayat tunggal itu.

Namakan protokol sebelum sijil

Pendengar SSTP membentangkan sijil TLS kepada klien yang berkelakuan seperti HTTPS. Sambungan IKEv2 tapak-ke-tapak masuk mengumumkan identiti pelayan dan mengesahkan sijil rakan terhadap akar yang dipercayai. Definisi tapak-ke-tapak setiap antara muka membawa identiti mesin tersendiri.

Itu tiga kawalan dengan tiga skop. Mencampuradukkannya menghasilkan perubahan yang kelihatan berjaya pada satu protokol dan tiada kesan pada protokol yang lain, yang lebih teruk daripada kegagalan yang jelas. Catat protokol mana yang gagal, pihak mana yang membentangkan sijil dan pihak mana yang menolaknya sebelum anda menyentuh apa-apa.

SSTP ialah ikatan HTTPS

Untuk penggunaan Remote Access yang disokong, Set-RemoteAccess mendedahkan parameter SslCertificate yang digunakan untuk kesambungan SSTP dan untuk peranan DirectAccess berkaitan HTTPS.

Skop pengesahan dan penggunaannya mengikut konfigurasi Remote Access, jadi satu perubahan ikatan boleh mencapai lebih daripada satu sambungan atau nod. Dalam penggunaan dengan pengimbangan beban, skop itu merangkumi setiap nod yang diliputi konfigurasi. Menukar satu nod dan menguji satu klien membiarkan yang lain membentangkan daun lama, dan inilah jenis perubahan separuh siap yang bertahan melepasi tetingkap penyelenggaraan.

Sebelum kemas kini, sahkan nama perkhidmatan yang dijangka, rantaian, kesahan, kegunaan yang dimaksudkan dan ketersediaan kunci peribadi. Sijil mesti sepadan dengan nama yang akan diperiksa klien, dan label penyesuai bukanlah nama itu.

IKEv2 masuk mempunyai parameternya sendiri

Set-VpnAuthProtocol mengkonfigurasi pengesahan IKEv2 tapak-ke-tapak masuk, dan CertificateAdvertised membekalkan sijil apabila mod pengesahan terowong menggunakannya. Ini bukan arahan umum untuk memilih mana-mana sijil pelayan pada hos.

Pisahkan dua objek: daun yang dibentangkan pelayan sebagai identitinya sendiri, dan akar yang digunakan untuk menerima sijil rakan. Memilih pengeluar mana yang anda percayai tidak menyatakan apa-apa tentang daun yang dibentangkan pelayan.

Identiti satu antara muka tapak-ke-tapak ditetapkan melalui Set-VpnS2SInterface. Ia bukan secara automatik sijil SSTP, walaupun kedua-duanya berada dalam stor yang sama pada mesin yang sama.

Periksa calon terlebih dahulu

Paparan tertumpu stor mesin setempat menunjukkan metadata awam tanpa mengeksport apa-apa yang peribadi:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Senarai itu ialah titik permulaan, bukan ujian kesesuaian. Periksa entri SAN, kegunaan kunci lanjutan, rantaian dan akses akaun perkhidmatan kepada kunci peribadi untuk protokol yang anda konfigurasikan.

Sijil yang dipasang untuk identiti klien awan yang tidak berkaitan tidak sesuai hanya kerana ia muncul dalam stor yang sama. Keterlihatan bukan kesesuaian, dan cap jari dalam tangkapan skrin tidak membuktikan apa-apa tentang sama ada akaun perkhidmatan boleh membaca kunci itu. Periksa akses itu secara eksplisit, kerana keizinan kunci yang tiada hanya gagal apabila perkhidmatan dimulakan semula dan cuba menggunakan sijil.

Catat ikatan semasa dan pastikan anda masih boleh mencapai hos dengan cara lain sebelum menukarnya. Laluan pemulihan ialah sebahagian daripada perubahan, bukan sebahagian daripada insiden yang menyusul.

Pembaharuan bukan pengaktifan

Mengeluarkan semula sijil ialah tindakan berbeza daripada memilihnya untuk perkhidmatan yang sedang berjalan. Daun baharu boleh mengekalkan identiti DNS yang dimaksudkan dan masih membawa cap jari berbeza, jadi tiada apa menunjuk kepadanya sehingga ikatan dikemas kini. Pembaharuan mengubah objek; pengaktifan mengubah rujukan kepadanya. Mencampuradukkan kedua-duanya ialah sebab sijil yang diperbaharui dengan betul boleh tidak digunakan selama berminggu-minggu.

Gunakan perubahan yang disokong dalam tetingkap yang sesuai, termasuk sebarang permulaan semula yang didokumenkan, kemudian periksa sijil daripada sambungan baharu protokol yang dimaksudkan. Sesi klien yang dicache mungkin masih memaparkan daun lama dan membuat perubahan yang betul kelihatan rosak.

Hentikan penggunaan sijil sebelumnya melalui proses biasa hanya selepas pemeriksaan itu lulus. Rujukan Set-RemoteAccess mendokumenkan skop parameter SSL, termasuk kesannya dalam penggunaan dengan pengimbangan beban, dan itulah bahagian yang wajar dibaca sebelum perubahan ikatan.