Nilai registri NAT-T Windows: periksa topologi dahulu

Sambungan VPN Windows gagal, carian mengembalikan nilai registri, dan nilai itu dimasukkan bersama but semula. Urutan itu kadangkala berkesan dan tidak pernah menjelaskan apa-apa. Tetapan yang dimaksudkan menjawab satu soalan tentang di mana pelayan berada berbanding peranti NAT, dan ia tidak bermakna sehingga anda tahu protokol mana yang gagal dan pada peringkat mana.

Apa yang sebenarnya dipilih oleh nilai itu

AssumeUDPEncapsulationContextOnSendRule menentukan sama ada pelaksanaan IPsec Windows akan cuba mewujudkan perkaitan dengan rakan di belakang peranti NAT. Nilai lalai terdokumentasi 0 tidak membenarkan kes itu, 1 membenarkannya apabila pelayan ialah pihak di belakang NAT, dan 2 merangkumi kedua-dua hujung diterjemah. Ini adalah pernyataan topologi tentang siapa berada di mana.

Dibaca sebagai urutan, nombor-nombor itu menggambarkan terjemahan yang semakin banyak, bukan kebolehpercayaan yang semakin tinggi. Menetapkan 2 pada rangkaian yang tiada apa diterjemah tidak menjadikan sambungan lebih pantas atau stabil, dan tidak membaiki kegagalan pengesahan. Panduan NAT Microsoft untuk L2TP/IPsec mendokumenkan dasar dan konteks platform sejarahnya. Bandingkan konteks itu dengan versi dan peranan Windows yang benar-benar anda jalankan, kerana dokumen yang bertahan melalui beberapa keluaran bukan pernyataan tentang setiap binaan semasa.

Padankan topologi sebelum nombor

Lukis laluan dan tandakan titik terjemahan: adakah klien di belakang penghala rumah, adakah pelayan di belakang pengimbang beban atau tembok api yang menulis semula alamat, dan adakah mana-mana hujung berada di belakang terjemahan pembawa yang anda tidak kawal. Hanya selepas lukisan itu anda boleh memutuskan sama ada nilai itu terpakai, dan untuk hujung yang mana.

Dakwaan bahawa versi Windows Server semasa hanya dihantar dengan NAT traversal dimatikan terlalu luas untuk dijadikan asas tindakan. Yang penting ialah dasar pada sistem anda, topologi di hadapannya dan pertukaran yang gagal, dalam susunan itu. Jika kedua-dua hujung mempunyai alamat awam, tetapan itu bukan masalah anda. Lihat cadangan, sijil atau akaun sebaliknya, dan biarkan registri.

Periksa peringkat kegagalan dahulu

L2TP/IPsec menghasilkan sekurang-kurangnya tiga kegagalan berbeza: rakan tidak dapat dicapai, perlindungan IPsec tidak dapat diwujudkan, dan pengesahan pengguna PPP ditolak selepas terowong wujud. Akaun yang ditolak tidak boleh dibaiki dengan menukar dasar NAT, dan ketidakpadanan cadangan tidak boleh dibaiki dengan but semula.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Tamat masa tanpa penjawab menunjukkan kebolehcapaian atau penapisan dan bukan dasar. Penolakan pantas dengan mesej cadangan menunjuk kepada algoritma. Kegagalan selepas terowong naik tergolong dalam peringkat pengesahan, iaitu pemilik lain dan pembaikan lain.

SSTP melalui HTTPS dan IKEv2 asli mempunyai log dan kawalan mereka sendiri. Tiada satu pun menjadi kes NAT-traversal semata-mata kerana ia juga berjalan pada Windows.

Lakukan perubahan dengan jalan kembali

Jika dasar terdokumentasi dan topologi yang diperhatikan kedua-duanya menuntutnya, catat nilai sebelumnya, gunakan perubahan melalui konfigurasi terurus dan bukan skrip setiap profil, dan rancang but semula. Pada pelayan yang menyokong beban kerja lain, ini bukan penyuntingan yang tidak berbahaya.

Peranti NAT masih perlu membawa pengangkutan terkapsul dan trafik balik. Nilai registri tidak mencipta peraturan penghantaran, tidak menyelaraskan cadangan dan tidak mengesahkan identiti, jadi sambungan yang mula berfungsi selepas perubahan mungkin berfungsi atas sebab yang sama sekali berbeza. Uji semula protokol asal dengan topologi asal, kemudian catat peringkat mana yang gagal dan mengapa nilai itu dijangka menanganinya. Ayat itulah yang menjadikan khabar angin internet sebagai konfigurasi yang boleh anda pertahankan.