Mengapa PPTP dan L2TP/IPsec berhenti sebelum permintaan nama pengguna?

Tidak munculnya permintaan nama pengguna adalah anugerah diagnostik: PPP belum dimulai, jadi akun, kata sandi, dan kebijakan domain belum ditanyakan. Pada koneksi PPTP atau L2TP/IPsec klien meminta kredensial hanya setelah terowongan ada dan server telah memulai sesi PPP. Segala yang bisa gagal sebelum momen itu adalah transportasi, pertukaran kunci, atau penyiapan terowongan, sebuah wilayah yang jauh lebih kecil daripada «VPN-nya rusak».

Permintaan yang hilang mempersempit kesalahan ke tiga tahap

Catat tahap terakhir yang berhasil secara kasatmata, karena masing-masing punya pemilik dan perbaikan berbeda. Menebak pengaturan akun sementara Anda tertahan dua tahap lebih awal adalah cara satu sore hari lenyap.

Klien yang habis waktu tanpa permintaan tidak pernah mendapat asosiasi IPsec, jadi kesalahannya ada di IKE atau pada apakah paket Anda mencapai gateway sama sekali. Klien yang melaporkan sedang memverifikasi kredensial lalu jatuh sudah lebih jauh daripada yang disiratkan pesan itu. Permintaan yang diikuti penolakan adalah autentikasi PPP, dan itu tempatnya di artikel akun, bukan di sini.

Tahap satu: protokol yang dijatuhkan firewall secara diam-diam

PPTP membutuhkan TCP 1723 untuk kanal kendalinya dan protokol IP 47 untuk jalur data, dan keduanya berjalan terpisah. Banyak jaringan meneruskan 1723 dan menjatuhkan protokol 47, yang menghasilkan terowongan yang bernegosiasi lalu tidak mengangkut apa pun. Router yang melakukan NAT juga butuh lolos dengan dukungan GRE, dan jalur akses yang hanya IPv6 tidak dapat mengangkut PPTP dalam konfigurasi apa pun.

L2TP di atas IPsec menghabiskan port 500 untuk IKE dan port 4500 untuk penembusan NAT, lalu membungkus lalu lintas L2TP itu sendiri ke dalam 1701, sementara ESP mengangkut muatan terlindungi begitu asosiasinya ada. Izinkan kedua port kendali tetapi bukan ESP, dan Anda memperoleh tepat gejala di judul: kemajuan yang terlihat, lalu klien mati sebelum dialog kredensial apa pun. Menguji dari hotspot ponsel adalah cara murah memisahkan masalah klien dari masalah jalur.

Tahap dua: kunci yang bukan kuncinya, usulan yang tidak ditawarkan

Kunci yang dibagikan sebelumnya dan tidak cocok gagal cepat dan diam-diam, dan versi umumnya adalah kunci yang tampak benar di layar tetapi membawa pemisah baris yang tertempel atau spasi di ujungnya. Pada klien Linux dialognya belum tentu menjadi sumber kebenaran: plugin L2TP NetworkManager menyimpan rahasia dalam berkas di bawah /etc/ipsec.d/, dan berkas lama per koneksi yang masih disertakan /etc/ipsec.secrets akan dipakai alih-alih berkas yang baru Anda ketik. Salin berkas itu ke tempat aman, keluarkan dari jalur penyertaan, lalu ketik ulang kuncinya dengan tangan.

Separuh lain tahap ini adalah usulan. Kedua ujung harus sepakat pada kumpulan algoritme fase 1 yang sama — enkripsi, integritas, dan grup Diffie-Hellman — serta transformasi ESP yang cocok untuk fase 2, atau asosiasinya tidak terbentuk sama sekali. Gateway yang hanya menawarkan 3DES, SHA1, dan MODP1024 akan menolak klien yang dikonfigurasi untuk algoritme lebih kuat, dan lognya menyebut transformasi yang ditolak. Log itu menyebut ketidakcocokannya jika Anda membacanya alih-alih menyalakan ulang layanannya. Daripada menyalin untai algoritme dari utas forum, tanyakan kepada gateway transformasi apa yang benar-benar akan dinegosiasikannya: ike-scan yang diarahkan ke alamatnya mengembalikan transformasi yang akan dinegosiasikannya. Jika satu-satunya tawaran adalah kriptografi yang tidak lagi diizinkan kebijakan Anda, perbaikannya ada di gateway, bukan pada penurunan versi klien.

Di Windows kunci dan metode autentikasi berada di profil VPN, dan ketidakcocokan muncul sebelum permintaan kredensial, bukan sesudahnya. Bila penerimanya Windows Server, pastikan peran akses jarak jauh terpasang, sertifikatnya cocok dengan nama yang dihubungi klien, dan tidak ada filter port yang lebih sempit daripada protokol di atas.

Tahap tiga: terowongannya ada dan PPP tidak pernah mulai

Ketika IKE selesai dan permintaannya tetap tidak muncul, lihat daemon terowongan, bukan firewall. L2TP membutuhkan sesuatu yang mendengarkan di UDP 1701 — xl2tpd atau kl2tpd di Linux, layanan akses jarak jauh di Windows — dan layanan yang terpasang tetapi berhenti tampak dari sisi klien sama seperti paket yang dijatuhkan. Periksa pendengarnya sebelum membuka kembali aturan yang sudah Anda verifikasi. Setelah itu PPP harus bernegosiasi, dan pertukaran LCP pertama adalah tempat kegagalan senyap biasanya mendarat.

Satu jebakan pada tahap ini sama sekali bukan kesalahan jaringan: Windows hanya mengizinkan satu koneksi dari jenis VPN tertentu pada satu waktu, jadi percobaan kedua mengembalikan galat 937, «koneksi lain jenis ini sedang dipakai». Itu aturan lokal, dan jalan di sekitarnya adalah perangkat lain, jenis terowongan lain, atau berbagi satu koneksi yang sudah ada.

Baca log dalam urutan tahap, bukan menduga-duga

Hentikan klien, jalankan lagi, dan baca komponennya sesuai urutan mereka menulis log. Artinya pertama daemon IPsec — strongSwan atau Libreswan, dan ipsec --version memberi tahu Anda yang mana — lalu daemon L2TP, lalu pppd. Komponen mana pun yang menulis terakhir sebelum kegagalan menandai tahap yang perlu diselidiki, karena semua yang datang sesudahnya dalam urutan itu tidak berjalan sama sekali.

Verifikasi dengan koneksi baru, bukan sesi tersimpan, karena klien yang menyambung ulang dari tembolok bisa melewati bagian pertukaran dan memunculkan hasil basi. Pastikan jangkauan, pertukaran kunci, terowongan, dan PPP satu per satu, dalam urutan itu. Saat itulah permintaan yang hilang berhenti menjadi misteri dan menjadi baris kedua dari daftar yang benar-benar bisa Anda kerjakan. Daftar itu juga yang Anda serahkan kepada tim jaringan, yang jika tidak akan dimintai memeriksa firewall untuk kesalahan yang hidup di daemon yang tak pernah dijalankan.