MSCHAPv2 bukan protokol VPN: tanyakan dulu soal terowongannya

Nama pengguna dan kata sandi berjalan di dalam pembawa, dan MSCHAPv2 hanya menyebut metode yang berjalan. Tanyakan terowongan mana yang membawanya sebelum memilih profil klien, karena rangkaian akun yang sama muncul dalam susunan yang tidak berbagi satu baris kode pun. Setiap profil yang diberikan kepada Anda mengodekan kedua keputusan, bahkan ketika lembar instruksi hanya mencetak salah satunya. Urutan di bawah adalah yang dapat dijawab operator tanpa menebak dan yang dapat Anda periksa tanpa menangkap paket.

Autentikasi menumpang di dalam terowongan

VPN mengambil dua keputusan yang tampak seperti satu: bagaimana kedua pihak membangun kanal terlindungi, dan bagaimana seseorang membuktikan identitas di dalamnya. Yang kedua dicetak pada lembar instruksi karena itulah yang diketik manusia. Yang pertama menentukan apakah ada klien yang akan bekerja sama sekali, dan itulah yang dilewati orang. Mintalah operator menyebut pembawa lebih dulu lalu metodenya, dalam urutan itu. Dua koneksi dapat menuntut nama akun dan kata sandi yang sama tanpa berbagi implementasi apa pun di bawah kotak masuk.

Itulah sebabnya pengaturan yang disalin dari ponsel rekan kerja yang berfungsi bisa gagal di ponsel Anda, bahkan ketika server menerima kedua kredensial. Kredensial tidak pernah menjadi pembedanya; profil yang membungkusnya itulah pembedanya. kedua pihak benar dan tidak ada yang tersambung biasanya justru kebingungan ini, dan menjadi jelas begitu pembawanya disebut.

Tiga tempat metode yang sama muncul

Dalam PPP langkah autentikasi menunggu sampai ada tautan, dan RFC 2759 mendefinisikan MS-CHAPv2 sebagai langkah itu, karena itulah metode tersebut muncul di L2TP dan pada penerapan PPTP yang lebih tua. Terowongan berakhir lebih dulu dan negosiasi PPP terjadi di dalamnya, sehingga tahap PPP yang gagal dapat membuat terowongan tampak berdiri di log server. Bacalah kedua tahap itu secara terpisah sebelum menyimpulkan kredensial ditolak. Jadi klien yang dikonfigurasi untuk L2TP bisa sepenuhnya benar dan tetap menjadi klien yang salah bagi gateway yang hanya berbicara IKEv2.

IKEv2 justru menaruh EAP-MSCHAPv2 di dalam pertukaran kunci, sehingga kredensial yang sama gagal pada saat berbeda dan muncul sebagai galat autentikasi alih-alih galat sesi. Profil IKEv2 platform Android adalah contoh sehari-hari, dan ia meminta sertifikat atau pengenal server alih-alih opsi PPP. Nama akun identik pada kedua susunan, jadi ia tidak dapat memberi tahu mana yang Anda miliki. Hanya daftar protokol yang didukung operator yang menentukan itu.

VPN berbasis TLS menambahkan susunan ketiga, dengan kolom nama pengguna dan kata sandi sendiri dan tanpa MS-CHAPv2 di mana pun dalam pertukaran. Melihat kotak kata sandi karena itu bukan bukti tentang protokol di belakangnya, sebab formulirnya dibangun agar tampak familier. Pastikan protokolnya dari dokumentasi server, bukan dari bentuk jendela klien.

Jawaban yang sebenarnya Anda butuhkan

Kirim permintaan sebagai daftar, karena daftar sulit dijawab setengah. Mintalah protokol terowongan, metode di dalamnya, dan klien yang didukung operator di platform Anda. Lalu mintalah identitas dan pengaturan kepercayaan gateway, format akun, dan apa yang harus dapat dijangkau setelah koneksi berdiri.

Tiga yang pertama menentukan apakah Anda mendapat profil yang berfungsi sama sekali. Tiga yang terakhir menentukan apakah profil itu melakukan apa yang dibutuhkan pekerjaan. Simpan jawabannya terlampir pada tiket, karena orang berikutnya akan menanyakan enam pertanyaan yang sama. Bila jawaban tidak ada, perlakukan celah itu sebagai keputusan yang belum diambil operator, bukan sebagai sesuatu yang dapat Anda simpulkan.

Jangan longgarkan verifikasi gateway

Server juga membuktikan identitasnya kepada klien, dan separuh pertukaran itu bukan hiasan. Mematikan verifikasi sertifikat agar profil yang keras kepala tersambung menerima titik akhir mana pun yang menjawab, termasuk yang tidak pernah dituju siapa pun. Itu juga menyembunyikan ketidakcocokan nyata alih-alih menyelesaikannya, yang mendorong kegagalan ke saat yang lebih akhir dan kurang jelas. Profil yang membutuhkan pemeriksaan dimatikan adalah profil yang menunjuk ke sesuatu yang tidak dapat diverifikasinya.

Ketidakcocokan biasanya berupa nama, karena sertifikat yang diterbitkan untuk satu nama host gagal ketika profil memanggil alamat. Panggil namanya alih-alih mematikan pemeriksaan. Otoritas sertifikat privat gagal ketika perangkat tidak pernah diberi akarnya, dan perbaikannya adalah menyebarkan akar itu lewat jalur yang disetujui. Lingkungan terkelola mengharapkan operator menyediakan identitas dan jangkar kepercayaan, dan profil merujuk keduanya. Ketika kolomnya tidak ada, mintalah artefaknya alih-alih melepaskan verifikasi.

Cocokkan profilnya, lalu buktikan setiap tahap

Setelah pembawanya diketahui, ikuti proses terdokumentasi klien itu dan masukkan hanya kolom yang dimintanya. Kolom tambahan yang diisi karena ada tetap merupakan nilai yang salah, dan gagal lebih lambat daripada yang wajib. Simpan profil tanpa perubahan setelah koneksi berhasil pertama, agar suntingan berikutnya dapat dibandingkan dengan sesuatu yang diketahui berfungsi.

Lalu verifikasi bertahap: terowongan berdiri, pengguna terautentikasi, alamat dan rute yang diberikan muncul, dan satu layanan yang diizinkan menjawab. Setiap tahap meninggalkan baris lognya sendiri di server, dan membacanya berurutan mengubah keluhan kabur menjadi temuan spesifik. Jika platform tidak lagi mendukung susunan yang dijelaskan operator, itu percakapan migrasi dan bukan alasan mengaktifkan setiap opsi lama di perangkat. Pembawa, metode, dan profil adalah tiga jawaban terpisah, dan koneksi yang berfungsi memiliki ketiganya selaras.