L2TP/IPsec melalui NAT: apa yang sebenarnya rosak dan mengapa

Dakwaan bahawa NAT merosakkan L2TP/IPsec hanya separuh benar dan oleh itu tidak berguna. Penterjemahan alamat adalah perkara biasa, traversal NAT wujud semata-mata untuk melaluinya, dan berjuta-juta klien menyambung setiap hari dari belakang penghala. Yang rosak ialah peringkat tertentu bagi pertukaran tertentu: IKE tidak pernah menerima jawapan, terowong yang dikapsulkan dibuang oleh dasar yang hanya membenarkan satu protokol, atau pemetaan penterjemahan tamat tempoh semasa terowong melahu. Sebaik sahaja anda tahu di peringkat mana anda berada, pembaikannya biasanya satu peraturan atau keepalive, bukan reka bentuk VPN baharu.

Mitosnya ialah soalan yang salah

Soalan yang berguna bukanlah “adakah NAT merosakkan ini” tetapi “bahagian mana pertukaran itu diterjemah, dan apa yang dilakukan oleh peranti yang menterjemah dengannya”. L2TP/IPsec ialah protokol berlapis: IKE berunding, ESP melindungi, dan L2TP membawa PPP di dalam perlindungan itu. Penterjemahan alamat berinteraksi secara berbeza dengan setiap lapisan, dan tandatangan kegagalan boleh dibezakan jika anda melihat peringkat rundingan dan bukan dialog ralat.

Penghala yang berjaya melayari web hanya membuktikan bahawa TCP dengan penterjemahan port sumber berfungsi. Ia tidak menyatakan apa-apa tentang UDP 500, UDP 4500 atau protokol 50, dan ketiga-tiga itulah yang menjadi sandaran penggunaan ini.

Peringkat 1: IKE mesti mendapat jawapan langsung

Pertukaran pertama pergi kepada penjawab pada UDP 500. Jika tiada jawapan kembali, tiada apa-apa lagi yang penting: kunci yang dikongsi terlebih dahulu, cadangan dan kelayakan semuanya kekal tidak dibaca. Perhatikan permintaan dan jawapannya dan bukannya membuat kesimpulan daripada tamat masa klien:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Permintaan tanpa jawapan biasanya bermaksud firewall atau pengendali di hulu membuang paket itu, bukan bermaksud pelayan menolaknya. Jawapan dengan muatan pemberitahuan yang menamakan cadangan atau masalah sijil bermaksud paket itu tiba dan rundingan gagal pada kandungan, yang merupakan pembaikan yang sama sekali berbeza.

Apabila kedua-dua pihak berada di belakang penterjemahan, pemula hanya perlu mencapai penjawab, jadi kebanyakan penggunaan di pihak klien berfungsi dari peringkat 1. Pengehosan di pihak pelayan ialah tempat masalah masuk bermula, dan itulah sebabnya kedua-dua keadaan tidak boleh dibincangkan sebagai satu.

Peringkat 2: pengkapsulan mengubah apa yang dilihat oleh firewall

ESP ialah protokol IP, bukan port TCP atau UDP, dan penterjemahan alamat port biasa tidak mempunyai medan port untuk ditulis semula. Itulah sebabnya traversal NAT memindahkan muatan yang dilindungi ke dalam UDP 4500: pengkapsulan memberikan peranti penterjemah sesuatu yang ia tahu cara menterjemah. Sebaik sahaja itu berlaku, peraturan firewall yang ditulis hanya untuk UDP 500 akan membenarkan rundingan dan membuang terowong, yang menghasilkan keputusan mengelirukan apabila log menunjukkan fasa 1 yang berjaya dan tiada trafik.

Pertukaran IKE itu sendiri juga boleh berpindah ke UDP 4500 selepas NAT dikesan, yang mengejutkan mereka yang hanya membenarkan 500. Benarkan kedua-dua port dalam kedua-dua arah pada laluan, dan ingat bahawa firewall berkeadaan hanya mengekalkan aliran selagi ia melihat trafik.

Protokol 50 masih penting pada laluan tanpa penterjemahan, dan pada laluan di mana kotak perantaraan dikonfigurasikan untuk membenarkannya. Jika anda mendiagnosis melalui penyingkiran, matikan hipotesis dan bukannya menambah peraturan secara pukal: benarkan 500, 4500 dan ESP, sahkan terowong naik, kemudian buang apa yang ternyata tidak perlu. Peraturan yang tiada siapa dapat jelaskan ialah peraturan yang tiada siapa akan buang apabila ia menjadi punca gangguan seterusnya. Tulis penyempitan itu dalam rekod perubahan bersama peringkat yang dibaikinya, supaya jurutera seterusnya bermula daripada bukti anda dan bukan daripada peraturan praktikal yang sama.

Peringkat 3: pemetaan tamat tempoh dan terowong mati

Peranti penterjemah menyimpan keadaan bagi aliran yang dihantarnya, dan keadaan itu mempunyai jangka hayat. Terowong L2TP/IPsec membawa sedikit trafik apabila tiada siapa menggunakannya, jadi terowong melahu boleh hidup lebih lama daripada pemetaannya dan berhenti menerima trafik balik. Klien kekal yakin ia bersambung, pelayan tidak melihat apa-apa, dan gejala pertama biasanya tamat masa aplikasi dan bukan ralat VPN.

Pengesanan rakan mati dan keepalive NAT wujud untuk ini, dan kedua-dua hujung mesti bersedia menghantarnya. Jika pelayan anda berada di belakang penterjemahan, syarat di sebelah Windows ialah tetapan registri berdokumen yang membuatkan pelayan menganggap pengkapsulan UDP untuk paket keluarnya sendiri; tanpanya penjawab menghantar ESP yang tidak dapat dipetakan semula oleh peranti penterjemah. Ini isu konfigurasi pelayan, bukan klien.

Perubahan alamat WAN menghasilkan hasil yang sama dari arah lain: pemetaan dibina semula sekitar alamat baharu, dan persatuan keselamatan lama kini menunjuk ke tuple yang tidak lagi wujud. Tingkah laku penyambungan semula tergolong dalam pelaksanaan klien, dan itulah sebabnya “sambung semula selepas penghala dimulakan semula” berfungsi pada satu klien dan memerlukan togol manual pada klien lain.

Pengehosan di belakang NAT gred pembawa ialah masalah yang berbeza

Jika anda ingin mengehos pelayan L2TP/IPsec di rumah dan mencapainya dari luar, keperluannya ialah kebolehcapaian masuk yang tidak diminta, dan itu bukan apa yang disediakan oleh traversal NAT. NAT gred pembawa di hadapan penghala anda bermaksud tiada port yang boleh anda majukan yang akan menjadikan anda boleh dicapai, kerana alamat awam dikongsi dan pemetaan hanya keluar.

Tiada kotak semak IPsec pass-through mengubah itu, dan tiada konfigurasi klien mengimbanginya. Jawapan yang disokong ialah alamat yang benar-benar boleh dicapai, titik akhir yang dihoskan, atau seni bina di mana setiap peserta membuat sambungan keluar. Spesifikasi pengkapsulan UDP menyelesaikan masalah penterjemahan untuk aliran yang wujud; ia tidak mencipta laluan masuk di tempat pengendali tidak menawarkannya.

Jadi bandingkan rangkaian dan bukannya meneka. Bawa peranti dan profil yang sama ke rangkaian lain yang dibenarkan dan lihat peringkat mana yang gagal di sana. Jika ia berfungsi di tempat lain, perbezaannya pada laluan, dan itu menyempitkan carian kepada tiga peringkat di atas dan bukan seluruh konfigurasi.