Nilai registri NAT-T Windows: periksa topologi lebih dulu

Koneksi VPN Windows gagal, pencarian mengembalikan nilai registri, dan nilai itu dimasukkan bersama reboot. Urutan itu kadang berhasil dan tidak pernah menjelaskan apa pun. Setelan yang dimaksud menjawab satu pertanyaan tentang di mana server berada relatif terhadap perangkat NAT, dan tidak bermakna sampai Anda tahu protokol mana yang gagal dan pada tahap apa.

Apa yang sebenarnya dipilih nilai itu

AssumeUDPEncapsulationContextOnSendRule menentukan apakah implementasi IPsec Windows akan mencoba membuat asosiasi dengan peer di balik perangkat NAT. Nilai default terdokumentasi 0 tidak mengizinkan kasus itu, 1 mengizinkannya ketika server adalah sisi di balik NAT, dan 2 mencakup kedua ujung yang diterjemahkan. Itu pernyataan topologi tentang siapa berada di mana.

Dibaca sebagai urutan, angka-angka itu menggambarkan terjemahan yang makin banyak, bukan keandalan yang makin besar. Menyetel 2 pada jaringan yang tidak menerjemahkan apa pun tidak membuat koneksi lebih cepat atau lebih stabil, dan tidak memperbaiki kegagalan autentikasi. Panduan NAT Microsoft untuk L2TP/IPsec mendokumentasikan kebijakan dan konteks platform historisnya. Cocokkan konteks itu dengan versi dan peran Windows yang benar-benar Anda jalankan, karena dokumen yang bertahan melalui beberapa rilis bukan pernyataan tentang setiap build saat ini.

Cocokkan topologi sebelum angkanya

Gambarkan jalurnya dan tandai titik penerjemahan: apakah klien di balik router rumah, apakah server di balik penyeimbang beban atau firewall yang menulis ulang alamat, dan apakah salah satu ujung berada di balik penerjemahan operator yang tidak Anda kendalikan. Hanya setelah gambar itu Anda dapat memutuskan apakah nilai tersebut berlaku, dan untuk ujung yang mana.

Klaim bahwa versi Windows Server saat ini hanya dikirim dengan NAT traversal dimatikan terlalu luas untuk dijadikan dasar tindakan. Yang penting adalah kebijakan pada sistem Anda, topologi di depannya, dan pertukaran yang gagal, dalam urutan itu. Jika kedua ujung memiliki alamat publik, setelan itu bukan masalah Anda. Lihatlah proposal, sertifikat, atau akun sebagai gantinya, dan biarkan registri.

Periksa tahap kegagalan lebih dulu

L2TP/IPsec menghasilkan setidaknya tiga kegagalan berbeda: peer tidak dapat dijangkau, perlindungan IPsec tidak dapat dibangun, dan autentikasi pengguna PPP ditolak setelah tunnel ada. Akun yang ditolak tidak dapat diperbaiki dengan mengubah kebijakan NAT, dan ketidakcocokan proposal tidak dapat diperbaiki dengan reboot.

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

Waktu tunggu tanpa penjawab menunjukkan keterjangkauan atau penyaringan, bukan kebijakan. Penolakan cepat dengan pesan proposal menunjuk ke algoritme. Kegagalan setelah tunnel naik termasuk tahap autentikasi, yang merupakan pemilik lain dan perbaikan lain.

SSTP melalui HTTPS dan IKEv2 asli memiliki log dan kontrolnya sendiri. Tidak ada yang menjadi kasus NAT-traversal hanya karena keduanya juga berjalan di Windows.

Lakukan perubahan dengan jalan kembali

Jika kebijakan terdokumentasi dan topologi yang diamati sama-sama menuntutnya, catat nilai sebelumnya, terapkan perubahan melalui konfigurasi terkelola, bukan skrip per profil, dan rencanakan restart. Pada server yang mendukung beban kerja lain, ini bukan penyuntingan yang tak berbahaya.

Perangkat NAT tetap harus membawa transportasi terenkapsulasi dan lalu lintas balik. Nilai registri tidak membuat aturan penerusan, tidak menyelaraskan proposal, dan tidak memvalidasi identitas, sehingga koneksi yang mulai berfungsi setelah perubahan bisa berfungsi karena alasan yang sama sekali berbeda. Uji ulang protokol asli dengan topologi asli, lalu tuliskan tahap mana yang gagal dan mengapa nilai itu diharapkan mengatasinya. Kalimat itulah yang mengubah desas-desus internet menjadi konfigurasi yang dapat Anda pertahankan.