SSTP di Linux gagal sebelum login? Periksa komponen runtime

Anda memasang plugin SSTP, tombol radio muncul di editor jaringan, Anda mengisi gateway dan nama pengguna, dan profil gagal dengan kesalahan umum sebelum sempat meminta kata sandi. Tidak ada yang tidak biasa dalam urutan itu, dan tidak ada di dalamnya yang membuktikan perangkat lunak terowongan sudah terpasang. Koneksi SSTP dirakit dari bagian-bagian yang dikirim terpisah: plugin VPN yang dapat dijalankan NetworkManager, program klien SSTP yang memiliki sesi TLS dan PPP, daemon PPP di bawahnya, dan penyimpanan rahasia yang boleh dibaca koneksi.

Apa yang ditambahkan entri menu, dan apa yang tidak

Plugin menyumbang deskripsi layanan yang memberi tahu NetworkManager cara memulainya, dan pada sebagian besar distribusi editor kecil yang menggambar formulir. Itulah seluruh cakupan entri menu. Program klien berasal dari paket sumber lain, dan README plugin itu sendiri menyebut pemisahan itu langsung: ini plugin, bukan klien.

Klien kemudian membutuhkan PPP, karena SSTP membawa sesi PPP di dalam koneksi TLS. Tanpa pppd terowongan dapat menyelesaikan jabat tangan TLS dan tetap mati pada bingkai kontrol pertama, yang terlihat seperti masalah kredensial dan bukan. Di Debian dan Ubuntu bagian-bagiannya datang sebagai network-manager-sstp, sstp-client, dan ppp, dan memasang hanya yang pertama adalah alasan paling umum formulir menerima setiap isian sementara koneksi tidak pernah selesai.

Pilihan desktop menambah satu pemisahan lagi. Plasma menyunting profil melalui plasma-nm, yang membutuhkan komponen SSTP sendiri dan membaca deskripsi layanan yang sama, jadi editor tanpa entri SSTP dan CLI yang membuat profil dengan baik berarti separuh editor hilang, bukan runtime rusak.

Baca tahap pertama yang gagal sebelum memasang ulang apa pun

Percobaan SSTP yang gagal melewati tahapan dalam urutan tetap, dan tahap yang gagal memberi tahu komponen mana yang harus dilihat.

Menjalankan plugin adalah yang pertama, dan kegagalan di sana menghasilkan pesan tentang layanan VPN, bukan tentang server. Berikutnya koneksi TCP ke port 443; penolakan atau waktu habis di sini adalah masalah keterjangkauan, bukan TLS. Lalu jabat tangan TLS dan pemeriksaan identitas server, kemudian negosiasi PPP dan autentikasi akun, dan akhirnya penetapan alamat dan rute. Pantau journalctl -f -u NetworkManager saat Anda mengaktifkan profil satu kali, dan baca baris spesifik pertama alih-alih baris umum terakhir.

Urutan itu menjelaskan salah baca yang umum. Keluhan sertifikat dilaporkan sebelum kredensial apa pun dikirim, jadi mengganti kata sandi tidak dapat membantu; penolakan autentikasi PPP datang setelah jabat tangan berhasil, jadi mengganti sertifikat juga tidak membantu. Simpan kesalahan pertama dan tahapnya, dan Anda memiliki diagnosis, bukan gejala.

Kepercayaan sertifikat dan login akun adalah dua gerbang terpisah

Jabat tangan memvalidasi bahwa server adalah yang ingin Anda tuju, menggunakan penerbit dan nama yang Anda konfigurasi. Hanya setelah itu lapisan PPP menawarkan nama pengguna dan kata sandi Anda ke metode autentikasi gateway. Dua pemeriksaan independen, jadi, dievaluasi dalam urutan tetap, dengan pengaturan terpisah untuk masing-masing. Tidak ada yang diketik di kolom kata sandi dapat memengaruhi yang pertama.

Profil yang memercayai penerbit yang salah gagal di gerbang pertama dengan kesalahan identitas. Profil yang memercayainya dengan benar tetapi menyimpan kata sandi lama gagal di gerbang kedua dengan penolakan autentikasi. Keduanya tampak seperti VPN yang tidak akan tersambung, dan tidak satu pun diperbaiki oleh obat yang lain.

Dapatkan penerbit dan nama server yang diharapkan dari siapa pun yang menjalankan gateway alih-alih menebak default editor, dan catat metode autentikasi yang mereka minta. Jika organisasi membutuhkan metode yang tidak dapat diungkapkan plugin, jawaban jujurnya adalah klien yang disetujui yang bisa, bukan profil dengan validasi dimatikan agar kesalahannya hilang.

Biarkan satu pemilik memegang profil dan rahasianya

Setelah profil ada, aktifkan melalui NetworkManager dan biarkan manajer itu memiliki rute dan perubahan resolver yang dihasilkan. Menjalankan klien SSTP mandiri kedua saat NetworkManager sudah menjalankan koneksi memberi Anda dua set rute, dua konfigurasi DNS, dan sesi debugging tanpa satu sumber kebenaran.

Rahasia juga punya pemilik. Koneksi yang ditandai untuk penggunaan seluruh sistem menyimpan kredensial secara berbeda dari yang dibatasi pada sesi pengguna Anda, dan profil yang dibuat dengan tangan dalam file kunci mungkin tidak dapat dibaca oleh agen rahasia yang mengharapkan menyediakan kata sandi secara interaktif. Periksa konteks apa yang diharapkan profil sebelum Anda mengetik ulang kata sandi yang tidak pernah menjadi masalah. Mengaktifkan profil yang sama dari terminal dengan nmcli adalah uji tercepat, karena prompt yang tidak pernah muncul memberi tahu bahwa agen sudah tidak punya apa pun untuk ditawarkan.

Periksa terowongan, rute, dan resolver secara terpisah

Indikator terhubung hanya mengklaim bahwa tautan sudah naik. Periksa tujuan yang benar-benar Anda butuhkan, rute yang membawanya, dan resolver yang digunakan, satu per satu; masing-masing bisa salah sementara dua lainnya baik-baik saja.

Untuk percobaan yang gagal, catat versi setiap komponen dan teks kesalahan yang sudah dibersihkan. Bagikan itu, bukan profil lengkap, karena profil dapat berisi rahasia yang dibagikan sebelumnya dan kredensial tersimpan Anda.

Terakhir, putuskan dan sambungkan kembali, lalu boot ulang sekali. Jika profil hanya berfungsi pada percobaan pertama, masalahnya ada pada penanganan rahasia atau kepemilikan rute, dan keduanya lebih murah diperbaiki sekarang daripada di tengah hari kerja.