Mengapa L2TP/IPsec Memerlukan UDP 1701 Selain IPsec

Firewall yang mengizinkan IKE dan ESP tetapi tidak UDP 1701 memutus koneksi L2TP dengan cara yang tampak seperti masalah kredensial. Penyebabnya adalah L2TP merupakan protokol kedua yang berjalan di dalam protokol pertama. IPsec mengangkut dan mengautentikasi pertukaran, dan L2TP menjalankan terowongannya sendiri di atas UDP 1701, yang tetap harus dikirimkan oleh tumpukan lokal. Mengetahui di mana setiap header muncul menjelaskan perangkat mana yang memerlukan aturan mana.

Dua protokol, dua set port

Koneksi L2TP/IPsec memakai IKE pada UDP 500, penembusan NAT pada UDP 4500 bila ada penerjemahan, dan ESP sebagai protokol IP 50 bila tidak ada. L2TP sendiri adalah protokol terowongan pada UDP 1701, dan berjalan setelah IPsec mengautentikasi peer. Kedua paruhnya gagal dengan cara berbeda, dan baris log yang melaporkannya berasal dari komponen berbeda. Himpunan aturan yang hanya mencakup paruh pertama menghasilkan koneksi yang bernegosiasi lalu mati pada tahap terowongan.

Nomor port menjelaskan titik ujung transportasi, dan ESP sama sekali bukan port. Itulah sebabnya antarmuka firewall yang hanya menyediakan aturan TCP dan UDP tidak dapat menyatakan kebijakan IPsec secara lengkap. Protokol 50 harus diizinkan sebagai protokol, dan aturan yang hanya menyebut UDP tidak akan pernah mencocokinya.

Pembungkus menjelaskan port tersebut

Di jaringan, koneksi L2TP/IPsec biasanya menunjukkan IKE pada 500 dan ESP terbungkus pada 4500. Header UDP 1701 berada di dalam muatan terlindungi, itulah sebabnya penangkapan pada antarmuka luar tidak menampilkannya. Host lokal tetap harus mengirimkan datagram itu ke daemon L2TP, dan pengiriman terjadi setelah dekapsulasi. Karena itu aturan 1701 berada pada firewall endpoint itu sendiri, bahkan ketika tidak ada perangkat tengah yang pernah melihat port tersebut.

Urutan pemrosesan menjelaskan sebagian besar kebingungan. Jika tumpukan menerapkan kebijakan IPsec sebelum filter host, paket L2TP yang sudah didekapsulasi dicocokkan sebagai UDP 1701; jika urutannya dibalik, port luar-lah yang dilihat himpunan aturan. Kedua perilaku ada dalam praktik, karena itu himpunan aturan yang sama tampak bekerja pada satu platform dan gagal pada platform lain.

Periksa jalur secara berurutan

Tangkap antarmuka luar terlebih dahulu dan pastikan IKE serta ESP terbungkus bergerak di kedua arah. Lalu periksa penghitung firewall lokal untuk lalu lintas yang telah didekapsulasi. Urutannya penting, karena penangkapan yang tidak menunjukkan apa pun berarti masalahnya berada di hulu host.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Penangkapan menegaskan paruh pertama pertukaran dan menunjukkan apakah peer menjawab. Daftar aturan menunjukkan apakah ada aturan 1701 dan di mana posisinya terhadap kebijakan pembuangan apa pun. Daftar soket menegaskan bahwa daemon L2TP terikat dan mendengarkan, yang menyingkirkan layanan yang tidak pernah dimulai. Baca ketiganya sebelum mengubah aturan, karena pendengar yang tidak ada dan port yang tersaring menghasilkan keluhan yang sama dari pengguna.

Apa yang tidak dapat ditunjukkan pemindaian port

Pemindaian eksternal UDP 1701 terhadap peladen yang dikonfigurasi benar biasanya tidak melaporkan apa pun, dan itulah hasil yang diharapkan. Port tersebut tidak terekspos ke internet; port itu dicapai hanya setelah IPsec mengautentikasi peer. Memperlakukan hasil tertutup sebagai kesalahan akan membuka port yang seharusnya tetap tertutup. Pemindaian tidak dapat melihat ke dalam terowongan lebih dari ia dapat melihat lalu lintas aplikasi.

Ujilah dengan klien sungguhan sebagai gantinya, dan baca tahap yang dicapainya. Jika koneksi bernegosiasi lalu macet, tersangka adalah daemon L2TP atau filter lokal; jika tidak pernah bernegosiasi, port luarlah penyebabnya. Pemisahan tunggal itu menghilangkan sebagian besar dugaan tentang aturan mana yang harus ditambahkan, dan pelapisan protokol membuatnya dapat diprediksi alih-alih misterius.