L2TP/IPsec melalui NAT: apa yang sebenarnya rusak dan mengapa
Traversal NAT memindahkan ESP ke dalam UDP, dan pemetaan, firewall, serta operator gagal dengan cara masing-masing. Identifikasi tahapnya sebelum menyalahkan klien.
Klaim bahwa NAT merusak L2TP/IPsec hanya setengah benar dan karena itu tidak berguna. Penerjemahan alamat adalah hal normal, traversal NAT ada justru untuk bertahan darinya, dan jutaan klien terhubung setiap hari dari belakang router. Yang rusak adalah tahap tertentu dari pertukaran tertentu: IKE tidak pernah mendapat jawaban, terowongan yang dienkapsulasi dibuang oleh kebijakan yang hanya mengizinkan satu protokol, atau pemetaan penerjemahan kedaluwarsa saat terowongan menganggur. Setelah tahu di tahap mana Anda berada, perbaikannya biasanya satu aturan atau keepalive, bukan desain VPN baru.
Mitosnya adalah pertanyaan yang salah
Pertanyaan yang berguna bukan «apakah NAT merusak ini» melainkan «bagian mana dari pertukaran yang diterjemahkan, dan apa yang dilakukan perangkat yang menerjemahkan dengannya». L2TP/IPsec adalah protokol berlapis: IKE bernegosiasi, ESP melindungi, dan L2TP membawa PPP di dalam perlindungan itu. Penerjemahan alamat berinteraksi berbeda dengan setiap lapisan, dan tanda kegagalannya bisa dibedakan jika Anda melihat tahap negosiasi bukan dialog galat.
Router yang berhasil menjelajah web hanya membuktikan bahwa TCP dengan penerjemahan port sumber berfungsi. Itu tidak mengatakan apa pun tentang UDP 500, UDP 4500, atau protokol 50, dan justru ketiganya yang menjadi sandaran penerapan ini.
Tahap 1: IKE harus mendapat jawaban sama sekali
Pertukaran pertama menuju responder pada UDP 500. Jika tidak ada jawaban yang kembali, tidak ada hal lain yang penting: kunci yang dibagi sebelumnya, proposal, dan kredensial semuanya tetap tidak terbaca. Amati permintaan dan jawabannya alih-alih menyimpulkan dari timeout klien:
sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas
Permintaan tanpa jawaban biasanya berarti firewall atau operator di hulu membuang paket, bukan berarti server menolaknya. Jawaban dengan muatan notifikasi yang menyebut proposal atau masalah sertifikat berarti paket tiba dan negosiasi gagal karena isi, yang merupakan perbaikan sama sekali berbeda.
Ketika kedua pihak berada di belakang penerjemahan, inisiator hanya perlu mencapai responder, sehingga sebagian besar penerapan sisi klien berfungsi sejak tahap 1. Hosting sisi server adalah tempat masalah masuk dimulai, dan itulah sebabnya kedua situasi tidak boleh dibahas sebagai satu.
Tahap 2: enkapsulasi mengubah apa yang dilihat firewall
ESP adalah protokol IP, bukan port TCP atau UDP, dan penerjemahan alamat port biasa tidak memiliki bidang port untuk ditulis ulang. Itulah sebabnya traversal NAT memindahkan muatan yang dilindungi ke UDP 4500: enkapsulasi memberi perangkat penerjemah sesuatu yang ia tahu cara menerjemahkannya. Begitu itu terjadi, aturan firewall yang ditulis hanya untuk UDP 500 mengizinkan negosiasi dan membuang terowongan, yang menghasilkan hasil membingungkan ketika log menunjukkan fase 1 berhasil dan tidak ada lalu lintas.
Pertukaran IKE itu sendiri juga bisa pindah ke UDP 4500 setelah NAT terdeteksi, yang mengejutkan mereka yang hanya mengizinkan 500. Izinkan kedua port di kedua arah pada jalur, dan ingat bahwa firewall stateful hanya dapat mempertahankan aliran selama ia melihat lalu lintas.
Protokol 50 masih penting pada jalur tanpa penerjemahan, dan pada jalur di mana kotak perantara dikonfigurasi untuk mengizinkannya. Jika Anda mendiagnosis dengan eliminasi, matikan hipotesis alih-alih menambahkan aturan secara massal: izinkan 500, 4500, dan ESP, pastikan terowongan naik, lalu hapus yang ternyata tidak perlu. Aturan yang tidak dapat dijelaskan siapa pun adalah aturan yang tidak akan dihapus siapa pun ketika menjadi penyebab gangguan berikutnya. Tulis penyempitan ke catatan perubahan bersama tahap yang diperbaikinya, agar insinyur berikutnya mulai dari bukti Anda, bukan dari aturan praktis yang sama.
Tahap 3: pemetaan kedaluwarsa dan terowongan mati
Perangkat penerjemah menyimpan status untuk aliran yang diteruskannya, dan status itu memiliki masa hidup. Terowongan L2TP/IPsec membawa sedikit lalu lintas saat tidak ada yang memakainya, sehingga terowongan yang menganggur bisa hidup lebih lama dari pemetaannya dan berhenti menerima lalu lintas balik. Klien tetap yakin terhubung, server tidak melihat apa pun, dan gejala pertamanya biasanya timeout aplikasi bukan galat VPN.
Deteksi peer mati dan keepalive NAT ada untuk ini, dan kedua ujung harus bersedia mengirimnya. Jika server Anda berada di belakang penerjemahan, syarat di sisi Windows adalah pengaturan registri terdokumentasi yang membuat server mengasumsikan enkapsulasi UDP untuk paket keluarnya sendiri; tanpanya responder mengirim ESP yang tidak dapat dipetakan balik oleh perangkat penerjemah. Ini masalah konfigurasi server, bukan klien.
Perubahan alamat WAN menghasilkan hasil yang sama dari arah lain: pemetaan dibangun ulang di sekitar alamat baru, dan asosiasi keamanan lama sekarang menunjuk ke tuple yang tidak lagi ada. Perilaku penyambungan ulang milik implementasi klien, dan itulah sebabnya «sambung ulang setelah router reboot» berfungsi pada satu klien dan memerlukan tombol manual pada klien lain.
Hosting di belakang NAT tingkat operator adalah masalah berbeda
Jika Anda ingin menghosting server L2TP/IPsec di rumah dan mencapainya dari luar, syaratnya adalah keterjangkauan masuk yang tidak diminta, dan itu bukan yang disediakan traversal NAT. NAT tingkat operator di depan router Anda berarti tidak ada port yang dapat diteruskan yang membuat Anda terjangkau, karena alamat publik dibagi dan pemetaannya hanya keluar.
Tidak ada kotak centang IPsec pass-through yang mengubah itu, dan tidak ada konfigurasi klien yang mengimbanginya. Jawaban yang didukung adalah alamat yang benar-benar terjangkau, endpoint yang dihosting, atau arsitektur di mana setiap peserta membuat koneksi keluar. Spesifikasi enkapsulasi UDP memecahkan masalah penerjemahan untuk aliran yang ada; ia tidak menciptakan jalur masuk di tempat operator tidak menawarkannya.
Jadi bandingkan jaringan alih-alih menebak. Bawa perangkat dan profil yang sama ke jaringan lain yang diizinkan dan lihat tahap mana yang gagal di sana. Jika berfungsi di tempat lain, perbedaannya ada di jalur, dan itu menyempitkan pencarian ke tiga tahap di atas alih-alih seluruh konfigurasi.