Kesalahan PPTP 800 versus 812 dan koneksi putus setelah satu menit

Tiga pesan kesalahan dari satu klien PPTP biasanya menggambarkan tiga gangguan berbeda. Kesalahan 800 berarti tunnel tidak pernah terbentuk, kesalahan 812 berarti server menolak metode autentikasi, dan putus setelah satu menit adalah timer keepalive yang memutuskan bahwa rekan yang sehat telah pergi. Setiap tahap gagal karena alasannya sendiri, jadi masing-masing perlu pemeriksaannya sendiri.

Kesalahan 800 berarti tunnel tidak pernah terbentuk

Windows memunculkan kesalahan 800 ketika sama sekali tidak dapat membangun tunnel, dan teks tentang server yang tidak terjangkau atau parameter keamanan yang tidak cocok adalah ringkasan, bukan diagnosis. PPTP membutuhkan dua hal terpisah dari jaringan sebelum kredensial apa pun diperiksa. TCP 1723 membawa kanal kontrol, dan protokol IP 47, GRE, membawa muatan yang dienkapsulasi.

Uji jalur luar itu dari luar LAN Anda sendiri, karena koneksi yang bekerja di kantor tidak membuktikan apa pun tentang tepi:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Jika 1723 menjawab dan tangkapan tetap kosong saat klien mencoba terhubung, jalur tersebut menjatuhkan protokol 47. Router dengan 1723 diteruskan tetapi passthrough PPTP dimatikan menghasilkan pola yang persis seperti itu: jabat tangan TCP selesai, lalu paket GRE menghilang, sehingga kegagalan terlihat seperti masalah kredensial padahal tidak ada upaya login.

Arahkan penerusan ke alamat LAN server yang sekarang, aktifkan passthrough PPTP di tempat router menawarkannya, dan coba lagi dari titik luar yang sama. Ketika GRE disaring di hulu dan Anda tidak dapat mengubahnya, SSTP melalui TCP 443 atau L2TP/IPsec melalui UDP 500 dan 4500 memiliki peluang lebih baik daripada perubahan apa pun di sisi Windows.

Kesalahan 812 adalah server yang menolak metode autentikasi Anda

Kesalahan 812 kembali setelah tunnel naik, itulah sebabnya terasa seperti masalah kata sandi. Server menolak metode autentikasi yang dinegosiasikan untuk koneksi, bukan tentu kata sandinya sendiri. Di klien, buka entri VPN, masuk ke tab keamanan, atur jenis ke Point-to-Point Tunneling Protocol, pilih daftar protokol eksplisit, dan centang Microsoft CHAP versi 2.

Anda dapat membaca pengaturan saat ini tanpa mengklik dialog:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Server yang mensyaratkan MS-CHAP v2 menolak klien yang dibiarkan pada PAP atau pada jenis otomatis yang menegosiasikan sesuatu yang lebih lemah, dan kesalahan datang sebelum kata sandi pengguna mana pun dievaluasi. Format akun adalah separuh lain dari penolakan yang sama. Dalam satu kasus Windows mengirim identitas akun Microsoft berbentuk MicrosoftAccount\[email protected] padahal server menginginkan akun lokal atau domain. Mengetik SERVERNAME\username memberi tahu Windows penyimpanan akun mana yang harus dikonsultasikan dan menghapus kesalahan. Masukkan nama secara manual alih-alih membiarkan kredensial tersimpan memutar ulang format sebelumnya.

Putus setelah satu menit adalah keputusan keepalive

Ketika tunnel terhubung, melewatkan sedikit lalu lintas, lalu terputus, lihat perilaku gema LCP server sebelum menyentuh klien. Daemon secara berkala meminta rekan mengonfirmasi bahwa ia masih ada. Jika terlalu sedikit balasan tiba dalam anggaran yang dikonfigurasi, sesi dibongkar meskipun pengguna masih memiliki tautan yang berfungsi.

Pada server Linux pptpd nilai-nilai itu berada di /etc/ppp/options.pptpd, dan perbaikan biasanya memperlebar anggaran, bukan memperpendek interval:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Tiga puluh luput pada interval lima detik memaafkan kemacetan singkat alih-alih menyatakan rekan telah pergi. Menurunkan jumlah menjadi satu atau dua mengubah jitter biasa pada jalur terjemahan menjadi pemutusan kira-kira setiap menit. Jika server Anda Windows RRAS, bukan pptpd, lihat batas waktu sesi PPP dan kebijakan putus saat menganggur. Itu berada di tempat lain, dan menyunting berkas pppd yang tidak ada tidak akan mengubah apa pun.

Subnet yang tumpang tindih merusak jalur data

Tunnel PPTP dapat melakukan autentikasi dengan bersih dan tetap tidak mencapai apa pun ketika kedua situs memakai rentang privat yang sama, misalnya 192.168.1.0/24 di kantor dan di rumah. Klien tidak dapat menentukan host mana yang dimaksud suatu alamat, dan sebagian tumpukan menolak memasang rute sama sekali alih-alih memilih satu.

Perlakukan itu sebagai cacat desain dan nomori ulang salah satu sisi, atau berikan klien rentang akses yang sengaja diterjemahkan. Men-debug klien PPTP tidak dapat memperbaiki ruang alamat yang ada dua kali, dan gejalanya akan tetap tampak seperti putus acak.

Mulai dari tahap yang gagal: GRE untuk 800, metode dan string akun untuk 812, pengaturan gema untuk tunnel yang mati sesuai jadwal.