L2TP/IPsec gagal: asingkan IPsec, pengesahan terowong atau log masuk PPP

Tiga perkara mengesahkan diri dalam satu sambungan L2TP/IPsec, dan hanya satu daripadanya melibatkan orang yang mendail. IPsec membuktikan titik hujung terowong, sambungan kawalan L2TP mungkin membuktikan rakan semula dengan rahsianya sendiri, dan kemudian PPP membuktikan akaun pengguna di dalam sesi. Kegagalan pada mana-mana peringkat kelihatan seperti ralat log masuk generik dalam dialog klien dan kelihatan sangat berbeza dalam log pelayan. Lalui peringkat mengikut urutan dan berhenti pada yang pertama gagal, kerana setiap peringkat di bawah peringkat yang belum diuji juga belum diuji.

Tiga peringkat pengesahan, tiga identiti berbeza

IPsec membuktikan siapa pemilik titik hujung, menggunakan kunci pratkongsi atau sijil. Identiti itu milik mesin atau gerbang, tidak pernah milik manusia di papan kekunci. Apabila rakan tidak dapat bersetuju pada peringkat ini, tiada paket L2TP ditukar sama sekali.

Sambungan kawalan L2TP boleh menambah pertukaran cabaran-jawapan kedua yang berasingan, dipacu oleh rahsia bersama yang mesti dimiliki kedua-dua hujung.

RFC 2661 menjadikan pengesahan sambungan kawalan itu pilihan, yang menjelaskan mengapa kesilapan yang sama menghasilkan gejala berbeza pada dua pelayan. Pelaksanaan yang tidak pernah mengkonfigurasi rahsia terowong melangkau peringkat ini sepenuhnya; yang mengkonfigurasinya hanya pada satu pihak gagal sebelum PPP ditawarkan. PPP kemudian mengesahkan pengguna dengan PAP, CHAP atau MSCHAPv2 dan menyerahkan nama kepada stor akaun yang mungkin setempat, dalam chap-secrets atau pada RADIUS. Kata laluan yang salah pada ketika itu masih meninggalkan anda dengan terowong yang berfungsi dan sesi yang gagal.

Baca titik berhenti sebelum mengedit konfigurasi

Mulakan dengan ipsec --version supaya anda tahu sama ada output status milik strongSwan atau Libreswan. Kemudian baca log pelayan, bukan dialog klien, kerana pelayan merekodkan peringkat mana yang menolak.

Satu baris biasanya menyelesaikan tiket: aduan IKE atau cadangan ialah peringkat satu, mesej sambungan kawalan ialah peringkat dua, dan penolakan kaedah PPP atau akaun ialah peringkat tiga. Salin baris itu ke dalam tiket dengan cap masa. Meneka dari pihak klien membazirkan satu-satunya bukti yang anda sudah ada.

Jauhkan bahan kunci dan kata laluan daripada tampalan itu; nama peringkat mengarahkan kerja, dan kunci pratkongsi yang bocor membuka semula tiket dengan akibat yang lebih buruk.

Peringkat satu: adakah IPsec mempunyai persatuan?

Jalankan ipsec statusall pada strongSwan atau ipsec whack --status pada Libreswan dan cari persatuan anak yang terbentuk dengan pembilang bukan sifar. ip xfrm state menunjukkan pandangan kernel pada kedua-duanya. Pasangan SA yang dipasang dengan pembilang meningkat bermakna peringkat satu selesai dan anda boleh meneruskan.

Tiada persatuan sama sekali menunjuk kepada alamat rakan, set cadangan atau kunci pratkongsi, dan kadangkala kepada peranti yang menulis semula UDP 500 sambil menggugurkan UDP 4500. Persatuan yang terbentuk dan kemudian hilang selepas beberapa saat biasanya ketidakpadanan jangka hayat antara kedua hujung dan bukan masalah kelayakan. Periksa sama ada kedua pihak menyenaraikan cadangan penyulitan dan hash yang sama sebelum anda menaip semula apa-apa. Jika tidak, tiada kunci akan berfungsi.

Berhenti selagi persatuan masih tiada. Mengedit pilihan PPP pada ketika itu tidak mengubah apa-apa dan menyembunyikan kerosakan sebenar daripada orang seterusnya.

Peringkat dua: adakah sambungan kawalan L2TP disahkan?

Sebaik IPsec hidup, perhatikan daemon L2TP untuk sambungan kawalan yang mencapai keadaan terbentuk, kerana PPP tidak boleh bermula sebelum itu. Penolakan pada sambungan kawalan bermakna rahsia terowong berbeza antara hujung, atau satu hujung menuntut rahsia yang tidak pernah dihantar oleh hujung yang lain. Klien sering memaparkan satu medan berlabel shared secret, dan medan itu biasanya milik IPsec dan bukan L2TP. Mengisinya tidak mengkonfigurasi rahsia terowong, dan mengosongkannya tidak menyahaktifkannya.

Jika tiada pihak mengkonfigurasi rahsia terowong, langkau peringkat ini dan anggap kegagalan sambungan kawalan sebagai masalah kebolehcapaian. Sahkan bahawa UDP 1701 sampai ke daemon dan kedua hujung bersetuju pada enkapsulasi yang sama. Peraturan tembok api yang ditulis untuk salah satu daripada dua syarat itu ialah punca biasa sambungan yang terbuka separuh.

Hanya sesi yang mula berunding PPP benar-benar telah melepasi peringkat terowong.

Peringkat tiga: adakah PPP menolak akaun?

Kegagalan PPP kelihatan berbeza dari luar: terowong terbentuk, sesi bermula, dan daemon merekodkan kegagalan kaedah pengesahan atau penolakan akaun. Baca kaedah yang dinamakan dalam mesej itu. PAP dan CHAP gagal atas sebab berbeza, dan pelayan yang menolak satu akan menolak klien yang hanya menawarkan yang itu.

Pada pelayan Linux, periksa fail pilihan yang diserahkan daemon kepada PPP, biasanya /etc/ppp/options.xl2tpd, dan sahkan kaedah mana yang diterima dan di mana akaun diselesaikan. Nama yang wujud dalam RADIUS tetapi tidak dalam fail rahsia setempat gagal dengan bersih dan kelihatan seperti kata laluan yang salah. Kemudian periksa bahawa klien menawarkan kaedah yang diterima pelayan, bukan kaedah yang lebih kuat yang pelayan enggan rundingkan. Menukar kunci pratkongsi untuk membaiki peringkat ini membazirkan satu petang dan tidak mengubah apa-apa.

Apabila sesi akhirnya bangkit, penetapan alamat, DNS dan laluan masih belum diperiksa, dan setiap satu gagal secara senyap dengan caranya sendiri. Simpan tiga lapisan berasingan dalam nota anda: kunci betul dengan akaun salah sentiasa gagal, dan membaiki satu lapisan tidak pernah membaiki lapisan lain.