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

Tiada gesaan nama pengguna ialah hadiah diagnostik: PPP belum bermula, jadi akaun, kata laluan dan dasar domain belum ditanya lagi. Dalam sambungan PPTP atau L2TP/IPsec klien meminta kelayakan hanya selepas terowong wujud dan pelayan telah memulakan sesi PPP. Segala yang boleh gagal sebelum detik itu ialah pengangkutan, pertukaran kunci atau persediaan terowong, iaitu kawasan yang jauh lebih kecil daripada «VPN rosak».

Gesaan yang tiada menyempitkan kerosakan kepada tiga peringkat

Catat peringkat terakhir yang berjaya secara kelihatan, kerana setiap satu mempunyai pemilik dan pembaikan berbeza. Meneka tetapan akaun semasa anda terperangkap dua peringkat lebih awal ialah cara satu petang hilang.

Klien yang tamat masa tanpa gesaan tidak pernah mendapat perkaitan IPsec, jadi kerosakan ada pada IKE atau pada sama ada paket anda sampai ke gateway. Klien yang melaporkan sedang mengesahkan kelayakan dan kemudian jatuh telah pergi lebih jauh daripada yang disiratkan mesej itu. Gesaan yang diikuti penolakan ialah pengesahan PPP, dan itu tergolong dalam artikel akaun, bukan artikel ini.

Peringkat satu: protokol yang dicampak senyap oleh tembok api

PPTP memerlukan TCP 1723 untuk saluran kawalannya dan protokol IP 47 untuk laluan data, dan kedua-duanya bergerak berasingan. Banyak rangkaian meneruskan 1723 dan mencampak protokol 47, yang menghasilkan terowong yang berunding dan kemudian tidak membawa apa-apa. Penghala yang melakukan NAT juga memerlukan laluan dengan sokongan GRE, dan laluan akses IPv6 sahaja tidak dapat membawa PPTP dalam sebarang konfigurasi.

L2TP melalui IPsec menggunakan port 500 untuk IKE dan port 4500 untuk lintasan NAT, kemudian membalut trafik L2TP itu sendiri dalam 1701, manakala ESP membawa muatan terlindung setelah perkaitan wujud. Benarkan dua port kawalan tetapi bukan ESP, dan anda mendapat tepat gejala dalam tajuk: kemajuan kelihatan, kemudian klien mati sebelum sebarang dialog kelayakan. Menguji dari hotspot telefon ialah cara murah untuk memisahkan masalah klien daripada masalah laluan.

Peringkat dua: kunci yang bukan kuncinya, cadangan yang tidak ditawarkan

Kunci yang dikongsi terlebih dahulu yang tidak sepadan gagal dengan cepat dan senyap, dan versi biasa ialah kunci yang kelihatan betul di skrin tetapi membawa pemisah baris yang ditampal atau ruang di hujungnya. Pada klien Linux dialog itu bukan semestinya sumber kebenaran: pemalam L2TP NetworkManager menyimpan rahsia dalam fail di bawah /etc/ipsec.d/, dan fail lama bagi setiap sambungan yang masih disertakan oleh /etc/ipsec.secrets akan digunakan sebagai ganti fail yang baru anda taip. Salin fail itu ke tempat selamat, keluarkan daripada laluan sertaan, kemudian taip semula kunci itu dengan tangan.

Separuh lagi peringkat ini ialah cadangan. Kedua-dua hujung mesti bersetuju pada set algoritma fasa 1 yang sama — penyulitan, integriti dan kumpulan Diffie-Hellman — dan pada transformasi ESP yang sepadan untuk fasa 2, jika tidak perkaitan itu tidak terbentuk sama sekali. Gateway yang hanya menawarkan 3DES, SHA1 dan MODP1024 akan menolak klien yang dikonfigurasi untuk algoritma lebih kuat, dan lognya menamakan transformasi yang ditolak. Log itu menamakan ketidakpadanan jika anda membacanya dan bukannya memulakan semula perkhidmatan itu lagi. Daripada menyalin rentetan algoritma daripada urutan forum, tanya gateway transformasi mana yang benar-benar akan dirundingkannya: ike-scan yang dihalakan ke alamatnya mengembalikan transformasi yang akan dirundingkannya. Jika satu-satunya tawaran ialah kriptografi yang dasar anda tidak lagi benarkan, pembaikan itu terletak pada gateway, bukan pada penurunan taraf klien.

Dalam Windows kunci dan kaedah pengesahan tinggal dalam profil VPN, dan ketidakpadanan muncul sebelum gesaan kelayakan dan bukan selepasnya. Di mana penerima ialah Windows Server, sahkan bahawa peranan akses jauh dipasang, bahawa sijil sepadan dengan nama yang disambung oleh klien, dan bahawa tiada penapis port lebih sempit daripada protokol di atas.

Peringkat tiga: terowong wujud dan PPP tidak pernah bermula

Apabila IKE selesai dan gesaan masih tidak muncul, lihat daemon terowong dan bukan tembok api. L2TP memerlukan sesuatu yang mendengar pada UDP 1701 — xl2tpd atau kl2tpd pada Linux, perkhidmatan akses jauh pada Windows — dan perkhidmatan yang dipasang tetapi dihentikan kelihatan dari pihak klien sama seperti paket yang dicampak. Semak pendengar sebelum membuka semula peraturan yang sudah anda sahkan. Kemudian PPP mesti berunding, dan pertukaran LCP pertama ialah tempat kegagalan senyap biasanya mendarat.

Satu perangkap pada peringkat ini bukan kegagalan rangkaian sama sekali: Windows membenarkan hanya satu sambungan bagi jenis VPN tertentu pada satu masa, jadi percubaan kedua mengembalikan ralat 937, «sambungan lain jenis ini sedang digunakan». Itu peraturan setempat, dan jalan memintasnya ialah peranti lain, jenis terowong lain, atau berkongsi satu-satunya sambungan yang sudah wujud.

Baca log mengikut susunan peringkat dan bukan meneka

Hentikan klien, mulakannya semula, dan baca komponen mengikut susunan yang ditulisnya dalam log. Iaitu pertama daemon IPsec — strongSwan atau Libreswan, dan ipsec --version memberitahu anda yang mana — kemudian daemon L2TP, kemudian pppd. Komponen yang menulis terakhir sebelum kegagalan menandakan peringkat untuk disiasat, kerana semua yang datang selepasnya dalam jujukan itu tidak berjalan langsung.

Sahkan dengan sambungan baharu dan bukan sesi tersimpan, kerana klien yang menyambung semula daripada cache boleh melangkau bahagian pertukaran dan menghasilkan semula keputusan lapuk. Sahkan jangkauan, pertukaran kunci, terowong dan PPP satu demi satu, dalam susunan itu. Kemudian gesaan yang tiada berhenti menjadi misteri dan menjadi baris kedua senarai yang benar-benar boleh anda kerjakan. Senarai itu juga yang anda serahkan kepada pasukan rangkaian, yang jika tidak akan diminta memeriksa tembok api untuk kerosakan yang tinggal dalam daemon yang tidak dimulakan.