SSTP pada Linux gagal sebelum log masuk? Semak komponen masa jalan

Anda memasang pemalam SSTP, butang radio muncul dalam editor rangkaian, anda mengisi gerbang dan nama pengguna, dan profil gagal dengan ralat umum sebelum ia sempat meminta kata laluan. Tiada apa yang luar biasa dalam urutan itu, dan tiada apa di dalamnya membuktikan perisian terowong dipasang. Sambungan SSTP dipasang daripada bahagian yang dihantar secara berasingan: pemalam VPN yang boleh dilancarkan NetworkManager, program klien SSTP yang memiliki sesi TLS dan PPP, daemon PPP di bawahnya, dan stor rahsia yang dibenarkan dibaca oleh sambungan.

Apa yang ditambah oleh entri menu, dan apa yang tidak

Pemalam menyumbang penerangan perkhidmatan yang memberitahu NetworkManager cara memulakannya, dan pada kebanyakan pengedaran editor kecil yang melukis borang. Itulah keseluruhan skop entri menu. Program klien datang daripada pakej sumber yang berbeza, dan README pemalam itu sendiri menyatakan pemisahan itu secara langsung: ia pemalam, bukan klien.

Klien kemudian memerlukan PPP, kerana SSTP membawa sesi PPP di dalam sambungan TLS. Tanpa pppd terowong boleh melengkapkan jabat tangan TLS dan masih mati pada bingkai kawalan pertama, yang kelihatan seperti masalah kelayakan dan bukan. Pada Debian dan Ubuntu bahagian-bahagian itu datang sebagai network-manager-sstp, sstp-client dan ppp, dan memasang yang pertama sahaja ialah sebab paling biasa borang menerima setiap ruang tetapi sambungan tidak pernah selesai.

Pilihan desktop menambah satu lagi pemisahan. Plasma menyunting profil melalui plasma-nm, yang memerlukan komponen SSTP sendiri dan membaca penerangan perkhidmatan yang sama, jadi editor tanpa entri SSTP dan CLI yang mencipta profil dengan baik ialah separuh editor yang hilang, bukan masa jalan yang rosak.

Baca peringkat pertama yang gagal sebelum memasang semula apa-apa

Percubaan SSTP yang gagal melalui peringkat dalam susunan tetap, dan peringkat yang gagal memberitahu komponen mana untuk dilihat.

Melancarkan pemalam ialah yang pertama, dan kegagalan di situ menghasilkan mesej tentang perkhidmatan VPN, bukan tentang pelayan. Seterusnya sambungan TCP ke port 443; penolakan atau tamat masa di sini ialah masalah capaian, bukan TLS. Kemudian jabat tangan TLS dan pemeriksaan identiti pelayan, kemudian rundingan PPP dan pengesahan akaun, dan akhirnya peruntukan alamat dan laluan. Perhatikan journalctl -f -u NetworkManager semasa anda mengaktifkan profil sekali, dan baca baris khusus pertama dan bukan baris umum terakhir.

Susunan itu menjelaskan salah baca yang biasa. Aduan sijil dilaporkan sebelum sebarang kelayakan dihantar, jadi menukar kata laluan tidak dapat membantu; penolakan pengesahan PPP datang selepas jabat tangan berjaya, jadi menggantikan sijil juga tidak membantu. Simpan ralat pertama dan peringkatnya, dan anda mempunyai diagnosis, bukan gejala.

Kepercayaan sijil dan log masuk akaun ialah dua gerbang berasingan

Jabat tangan mengesahkan bahawa pelayan itu ialah yang anda mahu tuju, menggunakan pengeluar dan nama yang anda konfigurasikan. Hanya selepas itu lapisan PPP menawarkan nama pengguna dan kata laluan anda kepada kaedah pengesahan gerbang. Dua pemeriksaan bebas, jadi, dinilai dalam susunan tetap, dengan tetapan berasingan untuk setiap satu. Tiada apa yang ditaip dalam medan kata laluan boleh mempengaruhi yang pertama.

Profil yang mempercayai pengeluar yang salah gagal di gerbang pertama dengan ralat identiti. Profil yang mempercayainya dengan betul tetapi menyimpan kata laluan lapuk gagal di gerbang kedua dengan penolakan pengesahan. Kedua-duanya kelihatan seperti VPN yang tidak akan bersambung, dan tiada satu pun diperbaiki oleh ubat yang lain.

Dapatkan pengeluar dan nama pelayan yang dijangka daripada sesiapa yang mengendalikan gerbang dan bukannya meneka lalai editor, dan catat kaedah pengesahan yang mereka perlukan. Jika organisasi memerlukan kaedah yang tidak dapat dinyatakan oleh pemalam, jawapan jujurnya ialah klien yang diluluskan yang boleh, bukan profil dengan pengesahan dimatikan supaya ralat hilang.

Biarkan satu pemilik memegang profil dan rahsia

Setelah profil wujud, aktifkannya melalui NetworkManager dan biarkan pengurus itu memiliki laluan dan perubahan penyelesai yang terhasil. Menjalankan klien SSTP kendiri kedua semasa NetworkManager sudah mengendalikan sambungan memberi anda dua set laluan, dua konfigurasi DNS dan sesi nyahpepijat tanpa satu sumber kebenaran.

Rahsia juga mempunyai pemilik. Sambungan yang ditandakan untuk penggunaan seluruh sistem menyimpan kelayakan secara berbeza daripada yang terhad kepada sesi pengguna anda, dan profil yang dicipta secara manual dalam fail kunci mungkin tidak boleh dibaca oleh ejen rahsia yang menjangka membekalkan kata laluan secara interaktif. Semak konteks yang dijangka oleh profil sebelum anda menaip semula kata laluan yang tidak pernah menjadi masalah. Mengaktifkan profil yang sama dari terminal dengan nmcli ialah ujian terpantas, kerana gesaan yang tidak pernah muncul memberitahu anda bahawa ejen itu sudah tiada apa untuk ditawarkan.

Semak terowong, laluan dan penyelesai secara berasingan

Penunjuk bersambung hanya mendakwa bahawa pautan telah naik. Semak destinasi yang anda benar-benar perlukan, laluan yang membawanya dan penyelesai yang digunakan, satu demi satu; setiap satu boleh salah sementara dua yang lain baik.

Untuk percubaan yang gagal, rakam versi setiap komponen dan teks ralat yang telah dibersihkan. Kongsi itu, bukan profil penuh, kerana profil mungkin mengandungi rahsia yang dikongsi terlebih dahulu dan kelayakan tersimpan anda.

Akhir sekali, putuskan sambungan dan sambung semula, kemudian but semula sekali. Jika profil hanya berfungsi pada percubaan pertama, masalahnya terletak pada pengendalian rahsia atau pemilikan laluan, dan kedua-duanya lebih murah untuk dibaiki sekarang daripada di tengah hari bekerja.