Peringkat VPN mana yang gagal: IPsec, kawalan L2TP atau pengesahan PPP

Anda menukar kata laluan dan tiada apa bergerak, kerana kegagalan itu tidak pernah berada dalam PPP. L2TP/IPsec melaporkan satu ralat sambungan bagi lima penyerahan yang sangat berbeza, dan setiap penyerahan mempunyai pembaikannya sendiri. Bekerjalah ke belakang: cari peringkat terakhir yang berjaya dan ubah hanya apa yang datang selepasnya. Urutan di bawah juga menentukan bukti mana yang anda kumpul dahulu.

Jawab empat soalan mengikut urutan

Paksa percubaan baharu, kerana sesetengah klien terus memaparkan ralat sebelumnya sehingga profil diputuskan dan disambungkan semula. Kemudian jawab ini: adakah asosiasi keselamatan IPsec, adakah sambungan kawalan L2TP dan panggilan muncul, adakah PPP mencapai keputusan pengesahan, dan adakah IPCP memberi klien alamat? Tidak yang pertama ialah peringkat yang anda betulkan. Semua selepasnya belum diuji, jadi nama pengguna yang ditolak tidak membuktikan apa-apa apabila asosiasi tidak pernah wujud.

Segerakkan jam di kedua-dua hujung sebelum membandingkan. Percubaan semula yang membersihkan IPsec dan gagal pada PPP kelihatan seperti satu kegagalan apabila klien hanya memaparkan mesej terakhir dan log pelayan masih menyimpan percubaan sebelumnya. Baca mengikut cap masa, bukan mengikut baris paling kuat.

Apabila anda hanya mempunyai tangkapan skrin pengguna, bergantung pada pemisahan paling murah: kunci yang dikongsi terlebih dahulu yang salah dan xl2tpd yang tidak pernah menjawab menghasilkan teks yang sama dalam dialog Windows, tetapi satu memerlukan rahsia yang ditukar di kedua-dua hujung dan satu lagi memerlukan daemon dimulakan atau peraturan tembok api pada pelayan itu sendiri. Peranti di tengah tidak boleh menggugurkan 1701 dalaman setelah IPsec mod pengangkutan membungkusnya, jadi jangan mencari penapis laluan yang tidak wujud.

Apa yang sebenarnya dimiliki setiap lapisan

IPsec melindungi paket antara dua rakan; L2TP membawa sesi PPP di dalam laluan terlindung itu, itulah sebabnya RFC 3193 menetapkan mod pengangkutan dan bukan terowong sendiri. Label klien menyebut L2TP, jadi terowong dan log masuk terasa seperti satu mekanisme. Ia bukan: sambungan kawalan L2TP mengesahkan hujung terowong di tempat penggunaan mengaktifkannya, dan PPP mengesahkan pengguna secara berasingan dengan CHAP, PAP atau MS-CHAPv2 mengikut dasar pelayan.

Pemisahan itu menjelaskan dua rahsia yang orang terus keliru. Kunci yang dikongsi terlebih dahulu mengesahkan rakan IPsec. Nama pengguna dan kata laluan mengenal pasti pengguna kepada PPP. Menaip semula rahsia kongsi Windows pada profil yang mengesahkan dengan sijil tidak mengubah apa-apa pada peringkat yang gagal, dan menyunting kata laluan PPP tidak boleh menyediakan saluran terlindung yang hilang. Penahanan yang sama terpakai pada pemeriksaan identiti: jangan matikan identiti rakan atau pengesahan sijil untuk mendapatkan terowong, kerana yang bersambung kemudian ialah laluan, bukan rakan.

Pengesahan juga bukan penghujung PPP. Selepas pengguna diterima, IPCP merundingkan alamat klien dan pilihan DNS serta WINS yang pelayan sanggup berikan. Klien boleh lulus CHAP atau MS-CHAPv2 dan masih berakhir tanpa alamat, yang merupakan kegagalan dalam PPP dan bukan masalah penghalaan. L2TP biasa tanpa IPsec kekal sah dan tidak terlindung, jadi sambungan berjaya tidak pernah membuktikan trafik terlindung; periksa apa yang pelayan kuatkuasakan, bukan label klien.

Putuskan dari peringkat pertama yang hilang

Baca jadual mengikut item pertama yang hilang, dari kiri ke kanan. Lajur kanan ialah satu-satunya kerja yang berbaloi pada masa itu; semua di kirinya sudah terbukti, dan mengujinya semula membakar tetingkap gangguan tanpa menambah maklumat.

Tiga baris wajar diberi amaran. Baris 1701 ialah tempat klien Windows di belakang NAT biasanya mendarat: asosiasi selesai, kemudian tiada apa tiba, dan puncanya ialah pemkapsulan, bukan kata laluan buruk. Baris IPCP ialah yang salah dibaca sebagai masalah laluan, kerana Windows membungkus alamat yang hilang dalam ralat 720 dan ikon dulang hanya mengatakan sambungan gagal; kegagalan itu terletak selepas pengesahan dan sebelum penghalaan. Baris terakhir sama sekali bukan kegagalan IPsec, walaupun ikon dulang mengatakan terputus.

Perintah yang memisahkan lapisan

Pada pelayan Linux yang menjalankan strongSwan, swanctl --list-sas menyenaraikan asosiasi yang terbentuk dengan identiti rakan, dan ipsec statusall meliputi hos strongSwan dan libreswan yang lebih lama. Di bawahnya, ip xfrm state menunjukkan asosiasi kernel yang sebenar, manakala ss -lunp | grep 1701 membuktikan di mana xl2tpd terikat. Jalankan xl2tpd -D di latar hadapan untuk melihat sambungan kawalan dan panggilan muncul, dan hidupkan nyahpepijat pppd dalam /etc/ppp/options.xl2tpd untuk melihat kaedah yang ditawarkan dan jawapannya.

Apabila log menunjukkan pengesahan berjaya, soalan seterusnya ialah sama ada IPCP selesai. Periksa sama ada ip range dalam bahagian [lns default] fail /etc/xl2tpd/xl2tpd.conf masih mempunyai alamat bebas, dan sama ada /etc/ppp/options.xl2tpd benar-benar membawa ms-dns dan ms-wins jika klien mengharapkannya. Kolam yang habis dan pilihan DNS yang hilang kelihatan berbeza pada wayar: yang pertama meninggalkan klien tanpa alamat dan dengan 720, yang kedua memberi alamat tetapi tiada penyelesai, jadi nama gagal manakala ping ke alamat mentah berfungsi. Kedua-duanya tidak dibaiki dengan menaip semula kata laluan.

Pada klien, pemalam L2TP NetworkManager menulis perbualan pppd ke jurnal, jadi journalctl -u NetworkManager -b biasanya memisahkan terowong naik, pengesahan ditolak daripada tiada terowong sama sekali. Pada Windows, Get-VpnConnection melaporkan tetapan pengesahan sebenar profil, dan peristiwa RasClient di bawah Application dalam Event Viewer menamakan komponen yang gagal. Apabila dialog terlalu kabur, aktifkan netsh ras set tracing * enable.

Tangkapan memerlukan satu kehati-hatian. Dengan IPsec mod pengangkutan, UDP 1701 dalaman disulitkan, jadi tangkapan pada antara muka luar menunjukkan ESP, atau UDP 4500 di bawah NAT-T, dan tiada L2TP sama sekali. Ketiadaan 1701 dalam tangkapan adalah dijangka dan bukan bukti port tersekat; perhatikan sama ada pembilang ESP atau 4500 bergerak.

NAT, MTU dan laluan: di mana tindanan mengelirukan anda

NAT memecahkan andaian sebelum apa-apa disahkan. ESP ialah protokol IP tersendiri, jadi peranti yang menterjemah membuangnya kecuali rakan-rakan memkapsul; itulah yang disediakan UDP 4500. Pada pelayan Windows yang sendiri berada di belakang penghala rumah atau get laluan NAT awan, peringkat IPsec gagal dengan ralat 789 sehingga AssumeUDPEncapsulationContextOnSendRule ditetapkan kepada 2 di bawah kunci PolicyAgent dan mesin dimulakan semula, dan kegagalan itu kekal tidak dapat dibezakan daripada port tertutup. Klien di belakang NAT lebih mudah: dengan alamat awam pada pelayan, NAT-T pada UDP 4500 membawa mereka dan nilai itu tidak terlibat.

Setelah PPP naik, MTU berlubang hitam meniru terowong mati: paket kecil melintas, jabat tangan TLS atau muatan halaman tergantung, dan klien mungkin masih memaparkan bersambung. Turunkan MTU antara muka atau ketatkan MSS di get laluan sebelum menyalahkan pelayan. Penghalaan terowong berpecah ialah penyamar yang lain; subnet yang ditolak dengan topeng yang salah membiarkan terowong sihat dan satu aplikasi tidak dapat dicapai. Nama hos peribadi menambah lompatannya sendiri: jika pertanyaan keluar melalui penyelesai setempat, nama itu gagal diselesaikan sebelum mana-mana laluan diuji.

Senarai semak sebelum menyentuh kelayakan

Kerjakan senarai mengikut urutan dan berhenti pada item pertama yang gagal. Setiap langkah murah, dan setiap satu menyingkirkan satu kelas suntingan.

1. Sahkan asosiasi wujud di kedua-dua hujung, dipadankan mengikut identiti rakan dan bukan label bersambung.
2. Sahkan UDP 1701 sampai ke xl2tpd; asosiasi tanpa panggilan ialah kegagalan anda.
3. Baca keputusan PPP, dan jika ia mengesahkan, hasil IPCP, sebelum menganggap kata laluan itu salah.
4. Hanya sekarang masukkan semula kelayakan dalam format yang dijangka pelayan, kerana awalan domain mengubah akaun.
5. Jika masih gagal, tangkap kedua-dua hujung dengan cap masa sejajar dan bandingkan peringkat demi peringkat.

Berhenti pada langkah dua bermakna masalah laluan atau pemkapsulan, dan tiada suntingan kata laluan akan menggerakkannya. Berhenti pada langkah tiga bermakna log sudah menamakan kaedah atau kolam alamat yang perlu dibaiki. Sama ada cara, perubahan seterusnya ialah yang boleh anda pertanggungjawabkan, dan anda berhenti berpusing melalui tetapan yang tidak pernah terlibat.