L2TP/IPsec gagal: pisahkan IPsec, autentikasi tunnel, atau login PPP

Tiga hal melakukan autentikasi di dalam satu koneksi L2TP/IPsec, dan hanya satu di antaranya melibatkan orang yang menekan tombol panggil. IPsec membuktikan titik ujung tunnel, koneksi kontrol L2TP dapat membuktikan ulang para peer dengan rahasianya sendiri, lalu PPP membuktikan akun pengguna di dalam sesi. Kegagalan pada tahap mana pun tampak seperti kesalahan login generik di dialog klien dan tampak sangat berbeda di log server. Telusuri tahap secara berurutan dan berhenti di tahap pertama yang gagal, karena setiap tahap di bawah tahap yang belum diuji juga belum diuji.

Tiga tahap autentikasi, tiga identitas berbeda

IPsec membuktikan siapa pemilik titik ujung, menggunakan kunci yang dibagi sebelumnya atau sertifikat. Identitas itu milik mesin atau gateway, bukan manusia di depan papan ketik. Saat peer tidak bisa sepakat pada tahap ini, tidak ada paket L2TP yang dipertukarkan sama sekali.

Koneksi kontrol L2TP dapat menambahkan pertukaran tantangan-jawaban kedua yang terpisah, yang digerakkan oleh rahasia bersama yang harus dimiliki kedua ujung.

RFC 2661 menjadikan autentikasi koneksi kontrol itu opsional, yang menjelaskan mengapa kesalahan yang sama menghasilkan gejala berbeda pada dua server. Penerapan yang tidak pernah mengonfigurasi rahasia tunnel melewati tahap ini sepenuhnya; yang mengonfigurasinya hanya di satu sisi gagal sebelum PPP ditawarkan. PPP kemudian mengautentikasi pengguna dengan PAP, CHAP, atau MSCHAPv2 dan menyerahkan nama ke penyimpanan akun yang mungkin lokal, di chap-secrets, atau di RADIUS. Kata sandi yang salah pada titik itu tetap meninggalkan Anda dengan tunnel yang bekerja dan sesi yang gagal.

Baca titik henti sebelum mengedit konfigurasi

Mulailah dengan ipsec --version agar Anda tahu apakah keluaran status milik strongSwan atau Libreswan. Lalu baca log server, bukan dialog klien, karena server mencatat tahap mana yang menolak.

Satu baris biasanya menyelesaikan tiket: keluhan IKE atau proposal adalah tahap satu, pesan koneksi kontrol adalah tahap dua, dan penolakan metode PPP atau akun adalah tahap tiga. Salin baris itu ke tiket beserta stempel waktunya. Menebak dari sisi klien membuang satu-satunya bukti yang sudah Anda miliki.

Jauhkan materi kunci dan kata sandi dari tempelan itu; nama tahap mengarahkan pekerjaan, dan kunci yang dibagi sebelumnya yang bocor membuka kembali tiket dengan akibat yang lebih buruk.

Tahap satu: apakah IPsec memiliki asosiasi?

Jalankan ipsec statusall di strongSwan atau ipsec whack --status di Libreswan dan cari asosiasi anak yang terbentuk dengan penghitung bukan nol. ip xfrm state menampilkan pandangan kernel pada keduanya. Sepasang SA yang terpasang dengan penghitung naik berarti tahap satu selesai dan Anda bisa melanjutkan.

Tidak adanya asosiasi sama sekali menunjuk ke alamat peer, kumpulan proposal, atau kunci yang dibagi sebelumnya, dan kadang ke perangkat yang menulis ulang UDP 500 sambil menjatuhkan UDP 4500. Asosiasi yang terbentuk lalu hilang setelah beberapa detik biasanya ketidakcocokan masa berlaku antara kedua ujung, bukan masalah kredensial. Periksa apakah kedua sisi mencantumkan proposal enkripsi dan hash yang sama sebelum Anda mengetik ulang apa pun. Jika tidak, tidak ada kunci yang akan pernah bekerja.

Berhentilah selama asosiasi masih hilang. Mengedit opsi PPP pada titik itu tidak mengubah apa pun dan menyembunyikan kesalahan sebenarnya dari orang berikutnya.

Tahap dua: apakah koneksi kontrol L2TP berhasil diautentikasi?

Setelah IPsec aktif, perhatikan daemon L2TP untuk koneksi kontrol yang mencapai status terbentuk, karena PPP tidak dapat dimulai sebelum itu. Penolakan pada koneksi kontrol berarti rahasia tunnel berbeda antarujung, atau satu ujung menuntut rahasia yang tidak pernah dikirim ujung lain. Klien sering menampilkan satu kolom berlabel shared secret, dan kolom itu biasanya milik IPsec, bukan L2TP. Mengisinya tidak mengonfigurasi rahasia tunnel, dan menghapusnya tidak menonaktifkannya.

Jika tidak ada pihak yang mengonfigurasi rahasia tunnel, lewati tahap ini dan perlakukan kegagalan koneksi kontrol sebagai masalah keterjangkauan. Pastikan UDP 1701 mencapai daemon dan kedua ujung sepakat pada enkapsulasi yang sama. Aturan firewall yang ditulis untuk salah satu dari dua syarat itu adalah penyebab umum koneksi yang hanya terbuka separuh.

Hanya sesi yang mulai menegosiasikan PPP yang benar-benar telah melewati tahap tunnel.

Tahap tiga: apakah PPP menolak akun?

Kegagalan PPP terlihat berbeda dari luar: tunnel terbentuk, sesi dimulai, dan daemon mencatat kegagalan metode autentikasi atau penolakan akun. Baca metode yang disebut dalam pesan itu. PAP dan CHAP gagal karena alasan berbeda, dan server yang menolak salah satunya akan menolak klien yang hanya menawarkan metode itu.

Di server Linux, periksa berkas opsi yang diteruskan daemon ke PPP, biasanya /etc/ppp/options.xl2tpd, dan pastikan metode mana yang diterima dan di mana akun diselesaikan. Nama yang ada di RADIUS tetapi tidak di berkas rahasia lokal gagal dengan bersih dan tampak seperti kata sandi salah. Lalu periksa bahwa klien menawarkan metode yang diterima server, bukan metode lebih kuat yang ditolak server untuk dinegosiasikan. Mengubah kunci yang dibagi sebelumnya untuk memperbaiki tahap ini membuang satu sore dan tidak mengubah apa pun.

Saat sesi akhirnya aktif, penetapan alamat, DNS, dan rute masih belum diperiksa, dan masing-masing gagal diam-diam dengan caranya sendiri. Jaga ketiga lapisan tetap terpisah dalam catatan Anda: kunci yang benar dengan akun yang salah selalu gagal, dan memperbaiki satu lapisan tidak pernah memperbaiki lapisan lain.