L2TP terhubung tetapi negosiasi PPP gagal: fase mana?

Tunnel IPsec terbentuk, klien menampilkan peer terlindungi, lalu koneksi mati sebelum apa pun mencapai subnet privat. Celah itu adalah PPP yang mengerjakan tugasnya sendiri: opsi tautan, autentikasi pengguna, dan penetapan alamat semuanya terjadi setelah tunnel terenkripsi ada. Tidak ada yang dari pertukaran fase satu yang berhasil menyediakan kata sandi atau alamat dalam. Baca fase-fasenya berurutan dan kegagalan biasanya menamai dirinya sendiri.

Tunnel hanya lapisan pertama

L2TP membawa bingkai PPP di dalam tunnel yang dilindungi IPsec, yang berarti dua negosiasi independen harus berhasil sebelum sebuah paket dapat dirutekan. Yang luar membuktikan kedua ujung sepakat soal kunci dan identitas. Yang dalam menentukan parameter tautan, apakah pengguna terautentikasi, dan alamat apa yang diterima klien.

Kegagalan di dalam PPP tampak seperti tunnel rusak pada setiap klien yang hanya menampilkan satu lampu status. Memperlakukannya sebagai masalah tunnel berujung pada pembuatan ulang kunci, memulai ulang layanan, dan akhirnya mengganti rahasia bersama yang tidak pernah salah. Pembedaan yang berguna itu murah: jika pertukaran dengan peer selesai dan klien beralih ke permintaan nama pengguna atau tahap autentikasi, tunnel baik-baik saja. Semua yang setelah titik itu milik PPP.

Baca fase terakhir yang berhasil

Telusuri log ke depan dan berhenti pada fase pertama yang tidak selesai. LCP lebih dulu, lalu autentikasi, lalu IPCP untuk parameter IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Batas waktu LCP berarti kedua ujung tidak pernah sepakat soal opsi tautan dasar, yang merupakan ketidakcocokan profil atau protokol dalam yang diblokir, bukan kata sandi buruk. Penolakan autentikasi yang eksplisit adalah kasus sebaliknya: tautan naik dan satu sisi menolak kredensial. Batas waktu IPCP setelah autentikasi berhasil menunjuk ke kumpulan alamat atau kebijakan server. Masing-masing punya pemilik berbeda dan perbaikan berbeda, karena itu fasenya lebih penting daripada teks galat terakhir.

Simpan potongan log bersama nama fase di tiket. Ekor yang ditempel tanpa batas fase mengundang pembaca berikutnya menebak, dan menebak di sini memakan waktu satu jam.

Kesepakatan antara klien dan server

Kedua ujung harus menerima metode autentikasi yang sama, dan profil tersimpan dapat meminta metode yang sudah dipensiunkan server kuartal lalu. Penerapan terkelola juga menyembunyikan sisi server, tempat alasan penolakan biasanya dicatat atas nama pengguna, bukan perangkat.

Aktifkan satu metode yang didukung alih-alih setiap opsi lama, karena klien yang menawarkan lima metode mengaburkan mana yang gagal. Mintalah kebijakan sisi server dan penolakan yang tepat kepada administrator, yang tidak menuntut siapa pun menerbitkan kata sandi. Metode lama yang diaktifkan untuk menyelamatkan satu klien cenderung menyebar ke setiap profil yang menyalin berkas itu.

Verifikasi alamatnya, bukan loginnya

Login yang selesai bukan sesi yang dapat dipakai. IPCP menegosiasikan alamat dalam, dan kumpulan yang habis atau kebijakan yang menolak klien masih dapat meninggalkan tunnel tersambung tanpa apa pun untuk dirutekan.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Periksa alamat dalam lebih dulu, lalu rute dan resolver untuk sumber daya yang benar-benar Anda butuhkan. Alamat dalam bukan jalan keluar publik yang dilaporkan sebuah situs web, dan mencampur keduanya membuat orang berburu kebocoran yang tidak ada. Uji sumber daya privat lewat alamat sebelum lewat nama, agar kegagalan DNS tidak disalahartikan sebagai kegagalan perutean.

Tuliskan fase, metode, dan alamat dalam satu catatan dan beri tanggal. Jika akun yang sama gagal lagi dalam sebulan, catatan itu adalah pembeda antara pemeriksaan lima menit dan penyelidikan baru. Kegagalan pada fase berbeda adalah insiden berbeda, meskipun klien menampilkan satu dialog.