L2TP tanpa IPsec di Linux: xl2tpd, pppd, dan NAT

L2TP polos adalah PPP di dalam amplop, dan tidak lebih. Ia membawa frame Anda; ia tidak mengenkripsinya dan tidak membuktikan siapa yang duduk di ujung lain, itulah sebabnya hampir setiap penerapan menyelipkan IPsec di bawahnya. Alasan jujur untuk menjalankan versi telanjang masih ada: meja laboratorium, langkah migrasi, atau tautan yang sudah berada di dalam jalur terlindungi lain.

Jika Anda melanjutkan, tulis peringatan itu di catatan desain dan biarkan di sana. Yang berikut adalah jalur operasional yang saya pakai pada host keluarga Debian dan RHEL: file mana yang bertanggung jawab atas apa, MTU yang mencegah macet klasik, dan aturan penerusan yang membuat terowongan itu bernilai.

Tiga file membagi pekerjaan

xl2tpd mengakhiri koneksi kontrol dan menyerahkan setiap sesi ke daemon PPP, sehingga konfigurasi tersebar di dua program yang tidak pernah membaca file satu sama lain. Pendengar berada di /etc/xl2tpd/xl2tpd.conf, di dalam bagian [lns default] yang menamai kumpulan alamat dengan ip range, sisi server dengan local ip, dan penyerahan ke PPP dengan pppoptfile. Nyalakan require authentication = yes, biarkan length bit dan flow bit aktif, dan pilih kumpulan yang belum dipakai hal lain di host.

Kebijakan PPP berada di file yang disebut opsi itu, biasanya /etc/ppp/options.xl2tpd: auth, penolakan untuk pap, chap, dan mschap, require-mschap-v2, MTU dan MRU 1460, serta alamat DNS yang bisa dijangkau klien setelah tautan naik. Kredensial adalah file ketiga lagi, /etc/ppp/chap-secrets, tempat bidang kedua harus cocok dengan nama bagian LNS dan bidang keempat dapat mematok alamat tertentu dari kumpulan.

Mengapa terowongan tersambung lalu macet

Frame Ethernet 1500 byte tidak muat di jalur yang sudah memakai byte untuk header-nya sendiri. Header IPv4 luar memakan 20, UDP 8, dan header L2TP sekitar 12, menyisakan 1460 untuk PPP dan muatannya. Justru mengumumkan angka yang lebih kecil itu di PPP yang mencegah paket besar difragmentasi atau dibuang diam-diam di suatu tempat di tengah.

Gejalanya adalah terowongan yang tampak sehat sampai lalu lintas nyata datang: ping dan pesan kontrol lewat, penyalinan file macet, tidak ada yang menjelaskannya di log. Turunkan MTU dan MRU bersama-sama di kedua ujung. Menyetel hanya klien biasanya mengubah macet keras menjadi macet berkala, yang lebih sulit didiagnosis.

Satu port membawa dua percakapan

UDP 1701 berada di bawah kedua bagian protokol, dan fakta tunggal itu memecahkan lebih banyak aturan firewall daripada bagian mana pun dari penyiapan. Pertama datang permintaan awal koneksi kontrol dan jawabannya; permintaan sesi dan konfirmasi yang menyusul tidak membangun apa pun selain pasangan pengenal. Setelah itu PPP mengambil alih: kontrol tautan, lalu autentikasi, lalu protokol kontrol IP untuk menyepakati alamat. Setiap tahap punya kosakata sendiri di log, dan tak satu pun mengumumkan dirinya sebagai kegagalan L2TP.

Membaca tangkapan tepat dalam urutan itu memberi tahu Anda tahap mana yang gagal, dan kegagalan autentikasi PPP tidak akan diperbaiki dengan menyunting xl2tpd. Port bersama menjelaskan kegagalan umum lainnya: aturan yang hanya mengizinkan paket pertama suatu aliran membiarkan sesi terbentuk lalu memblokir transfer. Izinkan 1701 untuk seluruh percakapan, di kedua arah.

Membuat terowongan berguna: penerusan dan NAT

Sesi sendirian hanya mencapai server. Akses internet klien membutuhkan penerusan, aturan NAT untuk kumpulan di uplink, dan DNS yang benar-benar bisa ditanyakan klien setelah tautan naik. Kumpulan juga harus tetap jauh dari rentang LAN, kalau tidak balasan yang ditujukan ke klien dikirim secara lokal alih-alih didorong kembali ke terowongan.

Di server, aktifkan penerusan dengan sysctl -w net.ipv4.ip_forward=1, terjemahkan kumpulan dengan iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, lalu terima lalu lintas terowongan keluar dengan aturan FORWARD untuk -i ppp0 -o eth0 dan lalu lintas balik dengan aturan cermin plus -m state --state RELATED,ESTABLISHED. Buat aturan itu bertahan setelah reboot, karena server yang kembali tanpa aturan itu tampak persis seperti konfigurasi L2TP yang rusak.

Mencapai LAN server sendiri adalah tugas lain: tambahkan rute balik untuk kumpulan di router LAN, atau proxy ARP di server. Menyembunyikan klien di belakang NAT padahal sesuatu di dalam LAN harus menyapa mereka secara langsung hanya menjadwalkan sesi debugging kedua nanti.

Apa yang tidak dilakukan tumpukan telanjang, dan cara memeriksanya

Tidak ada bagian dari tumpukan ini yang mengenkripsi frame PPP, dan tidak ada yang mengautentikasi ujung jauh sebagai server yang benar-benar Anda pilih. MS-CHAPv2 memang melindungi pertukaran kredensial dari pendengar yang hanya mengamati, tetapi penyerang yang berada di jalur masih bisa mengganggu sesi. Klien asli Windows hanya menawarkan L2TP bersama IPsec, jadi perhitungkan Linux, firmware router, dan klien pihak ketiga sebagai rekan Anda. Perlakukan konfigurasi telanjang sebagai batu pijakan diagnostik, jangan pernah sebagai tempat berhenti.

Verifikasi dalam urutan tetap: jalankan xl2tpd -D di latar depan, amati jurnal untuk tahap PPP, baca alamat yang diberikan dari ip addr di kedua ujung, lalu tangkap UDP 1701 untuk memastikan data mengalir setelah sesi naik. Jika keempatnya cocok dan lalu lintas tetap gagal, kesalahannya ada pada perutean, NAT, atau MTU, bukan pada L2TP itu sendiri.