MSCHAPv2 bukan protokol VPN: tanya tentang terowong dahulu

Nama pengguna dan kata laluan bergerak di dalam pembawa, dan MSCHAPv2 hanya menamakan kaedah yang bergerak. Tanya terowong mana yang membawanya sebelum memilih profil klien, kerana rentetan akaun yang sama muncul dalam susunan yang tidak berkongsi satu baris kod pun. Setiap profil yang diberikan kepada anda mengekod kedua-dua keputusan, walaupun helaian arahan hanya mencetak salah satunya. Urutan di bawah ialah perkara yang boleh dijawab operator tanpa meneka dan yang boleh anda semak tanpa menangkap paket.

Pengesahan menumpang di dalam terowong

VPN membuat dua keputusan yang kelihatan seperti satu: bagaimana kedua-dua pihak membina saluran terlindung, dan bagaimana seseorang membuktikan identiti di dalamnya. Yang kedua dicetak pada helaian arahan kerana itulah yang ditaip oleh manusia. Yang pertama menentukan sama ada mana-mana klien akan berfungsi langsung, dan itulah yang dilangkau orang. Minta operator menamakan pembawa dahulu kemudian kaedahnya, dalam urutan itu. Dua sambungan boleh menuntut nama akaun dan kata laluan yang sama tanpa berkongsi sebarang pelaksanaan di bawah kotak log masuk.

Itulah sebabnya tetapan yang disalin daripada telefon rakan sekerja yang berfungsi boleh gagal pada telefon anda, walaupun pelayan menerima kedua-dua kelayakan. Kelayakan tidak pernah menjadi perbezaannya; profil yang membungkusnya itulah perbezaannya. kedua-dua pihak betul dan tiada apa yang bersambung biasanya tepat kekeliruan ini, dan ia hilang sebaik sahaja pembawa itu dinamakan.

Tiga tempat kaedah yang sama muncul

Dalam PPP langkah pengesahan menunggu sehingga ada pautan, dan RFC 2759 mentakrifkan MS-CHAPv2 sebagai langkah itu, sebab itulah kaedah itu muncul dalam L2TP dan dalam penggunaan PPTP yang lebih lama. Terowong tamat dahulu dan rundingan PPP berlaku di dalamnya, jadi peringkat PPP yang gagal boleh membiarkan terowong kelihatan terbina dalam log pelayan. Baca kedua-dua peringkat itu secara berasingan sebelum membuat kesimpulan bahawa kelayakan ditolak. Jadi klien yang dikonfigurasikan untuk L2TP boleh menjadi betul sepenuhnya dan masih menjadi klien yang salah untuk get laluan yang hanya bertutur IKEv2.

IKEv2 sebaliknya meletakkan EAP-MSCHAPv2 di dalam pertukaran kunci, jadi kelayakan yang sama gagal pada saat yang berbeza dan muncul sebagai ralat pengesahan dan bukan ralat sesi. Profil IKEv2 platform Android ialah contoh harian, dan ia meminta sijil atau pengecam pelayan dan bukannya pilihan PPP. Nama akaun adalah sama dalam kedua-dua susunan, jadi ia tidak boleh memberitahu anda yang mana satu anda ada. Hanya senarai protokol yang disokong operator menentukan perkara itu.

VPN berasaskan TLS menambah susunan ketiga, dengan medan nama pengguna dan kata laluannya sendiri dan tanpa MS-CHAPv2 di mana-mana dalam pertukaran. Melihat kotak kata laluan kerana itu bukan bukti tentang protokol di belakangnya, kerana borang itu dibina supaya kelihatan biasa. Sahkan protokol daripada dokumentasi pelayan, bukan daripada bentuk tetingkap klien.

Jawapan yang benar-benar anda perlukan

Hantar permintaan sebagai senarai, kerana senarai sukar dijawab separuh. Minta protokol terowong, kaedah di dalamnya, dan klien yang disokong operator pada platform anda. Kemudian minta identiti dan tetapan kepercayaan get laluan, format akaun, dan apa yang patut boleh dicapai selepas sambungan didirikan.

Tiga yang pertama menentukan sama ada anda mendapat profil yang berfungsi langsung. Tiga yang terakhir menentukan sama ada profil itu melakukan apa yang diperlukan oleh kerja. Simpan jawapan itu dilampirkan pada tiket, kerana orang seterusnya akan bertanya enam soalan yang sama. Di mana jawapan tiada, anggap jurang itu sebagai keputusan yang belum dibuat oleh operator, bukan sesuatu yang boleh anda simpulkan.

Jangan longgarkan pengesahan get laluan

Pelayan juga membuktikan identitinya kepada klien, dan separuh pertukaran itu bukan hiasan. Mematikan pengesahan sijil supaya profil yang degil dapat bersambung menerima mana-mana titik akhir yang menjawab, termasuk yang tidak pernah dituju oleh sesiapa. Ia juga menyembunyikan ketidakpadanan sebenar dan bukannya menyelesaikannya, yang menolak kegagalan ke saat yang lebih lewat dan kurang jelas. Profil yang memerlukan pemeriksaan dimatikan ialah profil yang menunjuk kepada sesuatu yang tidak dapat disahkannya.

Ketidakpadanan biasanya ialah nama, kerana sijil yang dikeluarkan untuk satu nama hos gagal apabila profil mendail alamat. Dail nama itu dan bukannya mematikan pemeriksaan. Pihak berkuasa sijil persendirian gagal apabila peranti tidak pernah diberi akarnya, dan pembetulannya ialah mengedarkan akar itu melalui laluan yang diluluskan. Persekitaran terurus menjangka operator membekalkan identiti dan sauh kepercayaan, dan profil merujuk kedua-duanya. Apabila medan itu tiada, minta artifak itu dan bukannya menarik diri daripada pengesahan.

Padankan profil, kemudian buktikan setiap peringkat

Setelah pembawa diketahui, ikuti proses terdokumentasi klien itu dan masukkan hanya medan yang dimintanya. Medan tambahan yang diisi kerana ia wujud tetap nilai yang salah, dan ia gagal lebih lewat daripada yang wajib. Simpan profil tanpa perubahan selepas sambungan berjaya yang pertama, supaya suntingan kemudian boleh dibandingkan dengan sesuatu yang diketahui berfungsi.

Kemudian sahkan mengikut peringkat: terowong terbina, pengguna disahkan, alamat dan laluan yang diperuntukkan muncul, dan satu perkhidmatan yang dibenarkan menjawab. Setiap peringkat meninggalkan baris lognya sendiri pada pelayan, dan membacanya mengikut urutan menjadikan aduan kabur sebagai penemuan yang khusus. Jika platform tidak lagi menyokong susunan yang diterangkan operator, itu perbualan penghijrahan dan bukan alasan untuk mengaktifkan setiap pilihan lama pada peranti. Pembawa, kaedah dan profil ialah tiga jawapan berasingan, dan sambungan yang berfungsi mempunyai ketiga-tiganya selaras.