Tahap VPN mana yang gagal: IPsec, kendali L2TP, atau autentikasi PPP

Anda mengganti kata sandi dan tidak ada yang bergerak, karena kegagalan tidak pernah ada di PPP. L2TP/IPsec melaporkan satu galat koneksi untuk lima penyerahan yang sangat berbeda, dan setiap penyerahan punya perbaikannya sendiri. Bekerjalah mundur: temukan tahap terakhir yang berhasil dan ubah hanya apa yang datang sesudahnya. Urutan di bawah juga menentukan bukti mana yang Anda kumpulkan lebih dulu.

Jawab empat pertanyaan secara berurutan

Paksa percobaan baru, karena sebagian klien terus menampilkan galat sebelumnya sampai profil diputus dan disambungkan lagi. Lalu jawab ini: apakah ada asosiasi keamanan IPsec, apakah koneksi kendali L2TP dan panggilan muncul, apakah PPP mencapai putusan autentikasi, dan apakah IPCP memberi klien sebuah alamat? Tidak yang pertama adalah tahap yang Anda perbaiki. Semua sesudahnya belum diuji, jadi nama pengguna yang ditolak tidak membuktikan apa pun bila asosiasi tidak pernah ada.

Sinkronkan jam di kedua ujung sebelum membandingkan. Percobaan ulang yang membersihkan IPsec dan gagal di PPP tampak seperti satu kegagalan ketika klien hanya menampilkan pesan terakhir dan log server masih menyimpan percobaan sebelumnya. Bacalah menurut stempel waktu, bukan menurut baris paling berisik.

Ketika hanya ada tangkapan layar pengguna, andalkan pemisahan termurah: kunci yang dibagikan sebelumnya salah dan xl2tpd yang tidak pernah menjawab menghasilkan teks yang sama di dialog Windows, tetapi yang satu memerlukan rahasia yang diubah di kedua ujung dan yang lain memerlukan daemon dijalankan atau aturan tembok api di server itu sendiri. Perangkat di tengah tidak dapat membuang 1701 dalam setelah IPsec mode transport membungkusnya, jadi jangan mencari penyaring jalur yang tidak ada.

Apa yang sebenarnya dimiliki tiap lapisan

IPsec melindungi paket antara kedua rekan; L2TP membawa sesi PPP di dalam jalur terlindung itu, itulah sebabnya RFC 3193 menetapkan mode transport alih-alih terowongan sendiri. Label klien menyebut L2TP, sehingga terowongan dan login terasa seperti satu mekanisme. Bukan: koneksi kendali L2TP mengautentikasi ujung terowongan di tempat penerapan mengaktifkannya, dan PPP mengautentikasi pengguna secara terpisah dengan CHAP, PAP, atau MS-CHAPv2 menurut kebijakan server.

Pemisahan itu menjelaskan dua rahasia yang terus dicampur orang. Kunci yang dibagikan sebelumnya mengautentikasi rekan IPsec. Nama pengguna dan kata sandi mengidentifikasi pengguna kepada PPP. Mengetik ulang rahasia bersama Windows pada profil yang mengautentikasi dengan sertifikat tidak mengubah apa pun pada tahap yang gagal, dan menyunting kata sandi PPP tidak dapat menyediakan kanal terlindung yang hilang. Penahanan yang sama berlaku pada pemeriksaan identitas: jangan matikan identitas rekan atau validasi sertifikat untuk mendapatkan terowongan, karena yang tersambung kemudian adalah jalur, bukan rekan.

Autentikasi pun bukan akhir PPP. Setelah pengguna diterima, IPCP menegosiasikan alamat klien serta opsi DNS dan WINS yang bersedia diberikan server. Klien dapat lolos CHAP atau MS-CHAPv2 dan tetap berakhir tanpa alamat, yang merupakan kegagalan di dalam PPP dan bukan masalah perutean. L2TP polos tanpa IPsec tetap sah dan tidak terlindung, jadi koneksi yang berhasil tidak pernah membuktikan lalu lintas terlindung; periksa apa yang dituntut server, bukan label klien.

Putuskan dari tahap pertama yang hilang

Baca tabel menurut butir pertama yang hilang, dari kiri ke kanan. Kolom kanan adalah satu-satunya pekerjaan yang layak saat itu; semua di kirinya sudah terbukti, dan mengujinya ulang membakar jendela gangguan tanpa menambah informasi.

Tiga baris layak diberi peringatan. Baris 1701 adalah tempat klien Windows di belakang NAT biasanya mendarat: asosiasi selesai, lalu tidak ada yang datang, dan penyebabnya enkapsulasi, bukan kata sandi buruk. Baris IPCP adalah yang salah dibaca sebagai masalah rute, karena Windows membungkus alamat yang hilang dalam galat 720 dan ikon baki hanya mengatakan koneksi gagal; kegagalan itu berada setelah autentikasi dan sebelum perutean. Baris terakhir sama sekali bukan kegagalan IPsec, meskipun ikon baki mengatakan terputus.

Perintah yang memisahkan lapisan

Pada server Linux yang menjalankan strongSwan, swanctl --list-sas mendaftar asosiasi yang terbentuk beserta identitas rekan, dan ipsec statusall mencakup hos strongSwan serta libreswan yang lebih lama. Di bawahnya, ip xfrm state menampilkan asosiasi kernel yang sebenarnya, sedangkan ss -lunp | grep 1701 membuktikan di mana xl2tpd terikat. Jalankan xl2tpd -D di latar depan untuk melihat koneksi kendali dan panggilan muncul, dan aktifkan debug pppd di /etc/ppp/options.xl2tpd untuk melihat metode yang ditawarkan dan jawabannya.

Setelah log menunjukkan autentikasi berhasil, pertanyaan berikutnya adalah apakah IPCP selesai. Periksa apakah ip range di bagian [lns default] pada /etc/xl2tpd/xl2tpd.conf masih punya alamat bebas, dan apakah /etc/ppp/options.xl2tpd benar-benar membawa ms-dns dan ms-wins bila klien mengharapkannya. Kumpulan yang habis dan opsi DNS yang hilang terlihat berbeda di kabel: yang pertama meninggalkan klien tanpa alamat dan dengan 720, yang kedua memberi alamat tetapi tanpa penyelesai, sehingga nama gagal sementara ping ke alamat mentah berfungsi. Keduanya tidak diperbaiki dengan mengetik ulang kata sandi.

Pada klien, plugin L2TP NetworkManager menulis percakapan pppd ke jurnal, sehingga journalctl -u NetworkManager -b biasanya memisahkan terowongan naik, autentikasi ditolak dari tidak ada terowongan sama sekali. Di Windows, Get-VpnConnection melaporkan pengaturan autentikasi profil yang sebenarnya, dan peristiwa RasClient di bawah Application dalam Event Viewer menamai komponen yang gagal. Ketika dialog terlalu kabur, aktifkan netsh ras set tracing * enable.

Tangkapan memerlukan satu kehati-hatian. Dengan IPsec mode transport, UDP 1701 dalam terenkripsi, jadi tangkapan pada antarmuka luar menampilkan ESP, atau UDP 4500 di bawah NAT-T, dan tidak ada L2TP sama sekali. Tidak adanya 1701 dalam tangkapan adalah wajar dan bukan bukti port terblokir; perhatikan apakah penghitung ESP atau 4500 bergerak.

NAT, MTU, dan rute: tempat tumpukan menyesatkan Anda

NAT merusak anggapan sebelum apa pun diautentikasi. ESP adalah protokol IP tersendiri, jadi perangkat yang menerjemahkan membuangnya kecuali kedua rekan mengenkapsulasi; itulah yang disediakan UDP 4500. Pada server Windows yang sendiri berada di belakang router rumah atau gerbang NAT awan, tahap IPsec gagal dengan galat 789 sampai AssumeUDPEncapsulationContextOnSendRule disetel ke 2 di bawah kunci PolicyAgent dan mesin dimulai ulang, dan kegagalannya tetap tak terbedakan dari port tertutup. Klien di belakang NAT lebih mudah: dengan alamat publik pada server, NAT-T di UDP 4500 membawanya dan nilai itu tidak terlibat.

Setelah PPP naik, MTU berlubang hitam meniru terowongan mati: paket kecil lewat, jabat tangan TLS atau pemuatan halaman menggantung, dan klien mungkin masih menampilkan tersambung. Turunkan MTU antarmuka atau jepit MSS di gerbang sebelum menyalahkan server. Perutean terowongan terbelah adalah penyamar lain; subnet yang dikirim dengan masker salah membuat terowongan sehat dan satu aplikasi tak terjangkau. Nama hos privat menambah lompatannya sendiri: bila kueri keluar melalui penyelesai lokal, nama gagal diselesaikan sebelum rute apa pun diuji.

Daftar periksa sebelum menyentuh kredensial

Kerjakan daftar secara berurutan dan berhenti pada butir pertama yang gagal. Setiap langkah murah, dan masing-masing menyingkirkan satu kelas suntingan.

1. Pastikan asosiasi ada di kedua ujung, dicocokkan menurut identitas rekan, bukan label tersambung.
2. Pastikan UDP 1701 mencapai xl2tpd; asosiasi tanpa panggilan adalah kegagalan Anda.
3. Baca putusan PPP, dan bila mengautentikasi, hasil IPCP, sebelum menganggap kata sandi salah.
4. Baru sekarang masukkan lagi kredensial dalam format yang diharapkan server, karena awalan domain mengubah akun.
5. Bila masih gagal, tangkap kedua ujung dengan stempel waktu sejajar dan bandingkan tahap demi tahap.

Berhenti di langkah dua berarti masalah jalur atau enkapsulasi, dan tidak ada suntingan kata sandi yang menggesernya. Berhenti di langkah tiga berarti log sudah menamai metode atau kumpulan alamat yang harus diperbaiki. Bagaimanapun, perubahan berikutnya adalah yang dapat Anda pertanggungjawabkan, dan Anda berhenti berputar pada pengaturan yang tak pernah terlibat.