Linux'ta SSTP oturum açmadan önce başarısız mı oluyor? Çalışma zamanı parçalarını denetleyin

SSTP eklentisini kurarsınız, ağ düzenleyicide radyo düğmesi belirir, bir ağ geçidi ve kullanıcı adı girersiniz ve profil daha parola sormadan genel bir hatayla başarısız olur. Bu sıralamada olağandışı hiçbir şey yoktur ve içinde tünel yazılımının kurulu olduğunu kanıtlayan hiçbir şey de yoktur. Bir SSTP bağlantısı ayrı ayrı gönderilen parçalardan birleştirilir: NetworkManager'ın başlatabileceği bir VPN eklentisi, TLS ve PPP oturumuna sahip SSTP istemci programı, altındaki PPP artalan süreci ve bağlantının okumasına izin verilen bir sır deposu.

Menü girdisinin eklediği ve eklemediği şeyler

Eklenti, NetworkManager'a nasıl başlatılacağını söyleyen bir hizmet tanımı ve çoğu dağıtımda formu çizen küçük bir düzenleyici sağlar. Menü girdisinin tüm kapsamı budur. İstemci programı farklı bir kaynak paketten gelir ve eklentinin kendi README dosyası bu ayrımı doğrudan söyler: bu bir eklentidir, istemci değildir.

Sonra istemcinin PPP'ye ihtiyacı vardır, çünkü SSTP bir TLS bağlantısının içinde PPP oturumu taşır. pppd olmadan tünel TLS el sıkışmasını tamamlayabilir ve yine de ilk denetim çerçevesinde ölebilir; bu kimlik bilgileri sorunu gibi görünür ve değildir. Debian ve Ubuntu'da parçalar network-manager-sstp, sstp-client ve ppp olarak gelir ve yalnızca ilkini kurmak, formun her alanı kabul etmesi ama bağlantının asla tamamlanmamasının en yaygın nedenidir.

Masaüstü seçimi bir ayrım daha ekler. Plasma profilleri plasma-nm üzerinden düzenler; bunun kendi SSTP bileşenine ihtiyacı vardır ve aynı hizmet tanımını okur, bu yüzden SSTP girdisi olmayan bir düzenleyici ile profilleri sorunsuz oluşturan bir CLI, bozuk bir çalışma zamanı değil eksik bir düzenleyici yarısıdır.

Herhangi bir şeyi yeniden kurmadan önce ilk başarısız aşamayı okuyun

Başarısız bir SSTP denemesi sabit bir sırayla aşamalardan geçer ve başarısız olan aşama hangi bileşene bakmanız gerektiğini söyler.

Eklentiyi başlatmak ilkidir ve oradaki bir hata sunucu hakkında değil VPN hizmeti hakkında bir ileti üretir. Sonra 443 numaralı bağlantı noktasına TCP bağlantısı gelir; burada bir ret veya zaman aşımı erişilebilirlik sorunudur, TLS sorunu değil. Ardından TLS el sıkışması ve sunucu kimliği denetimi, sonra PPP görüşmeleri ve hesap kimlik doğrulaması, en sonunda adres ataması ve yollar. Profili bir kez etkinleştirirken journalctl -f -u NetworkManager izleyin ve son genel satır yerine ilk belirgin satırı okuyun.

Bu sıra yaygın bir yanlış okumayı açıklar. Sertifika şikâyeti herhangi bir kimlik bilgisi gönderilmeden önce bildirilir, bu yüzden parolayı değiştirmek yardımcı olamaz; PPP kimlik doğrulama reddi başarılı bir el sıkışmasından sonra gelir, bu yüzden sertifikayı değiştirmek de yardımcı olmaz. İlk hatayı ve aşamasını saklayın, o zaman belirti değil teşhis elde edersiniz.

Sertifikaya güven ve hesaba giriş ayrı kapılardır

El sıkışması, sunucunun ulaşmak istediğiniz sunucu olduğunu yapılandırdığınız veren ve adla doğrular. Ancak ondan sonra PPP katmanı kullanıcı adınızı ve parolanızı ağ geçidinin kimlik doğrulama yöntemine sunar. Yani iki bağımsız denetim sabit bir sırayla değerlendirilir ve her birinin ayrı ayarları vardır. Parola alanına yazılan hiçbir şey birinciyi etkileyemez.

Yanlış verene güvenen profil ilk kapıda kimlik hatasıyla başarısız olur. Ona doğru güvenen ama eski bir parola saklayan profil ikincisinde kimlik doğrulama reddiyle başarısız olur. İkisi de bağlanmayacak bir VPN gibi görünür ve hiçbiri diğerinin ilacıyla düzelmez.

Beklenen vereni ve sunucu adını düzenleyicinin varsayılanlarını tahmin etmek yerine ağ geçidini işleten kişiden alın ve gerektirdikleri kimlik doğrulama yöntemini not edin. Kuruluşun eklentinin ifade edemediği bir yönteme ihtiyacı varsa dürüst yanıt, bunu yapabilen onaylı bir istemcidir; hatayı yok etmek için doğrulaması kapatılmış bir profil değil.

Profili ve sırları tek bir sahip tutsun

Profil oluştuktan sonra onu NetworkManager üzerinden etkinleştirin ve ortaya çıkan yollar ile çözümleyici değişikliklerinin sahibi o yönetici olsun. NetworkManager bağlantıyı zaten yönetirken ikinci bir bağımsız SSTP istemcisi başlatmak size iki yol kümesi, iki DNS yapılandırması ve tek bir doğruluk kaynağı olmayan bir hata ayıklama oturumu verir.

Sırların da bir sahibi vardır. Sistem genelinde kullanım için işaretlenmiş bir bağlantı kimlik bilgilerini kullanıcı oturumunuzla sınırlı olandan farklı saklar ve anahtar dosyasında elle oluşturulmuş bir profil, parolayı etkileşimli olarak sağlamayı bekleyen sır aracısı tarafından okunamayabilir. Hiçbir zaman sorun olmayan bir parolayı yeniden yazmadan önce profilin hangi bağlamı beklediğini denetleyin. Aynı profili terminalden nmcli ile etkinleştirmek en hızlı sınavdır, çünkü hiç görünmeyen bir istem, aracının zaten sunacak bir şeyi olmadığını söyler.

Tüneli, yolları ve çözümleyiciyi ayrı ayrı denetleyin

Bağlı göstergesi yalnızca bağlantının kalktığını iddia eder. Gerçekten ihtiyacınız olan hedefi, onu taşıyan yolu ve kullanılan çözümleyiciyi tek tek denetleyin; diğer ikisi yerindeyken her biri yanlış olabilir.

Başarısız bir deneme için her bileşenin sürümünü ve temizlenmiş hata metnini kaydedin. Tüm profili değil bunları paylaşın, çünkü profil önceden paylaşılan sırrı ve saklanan kimlik bilgilerinizi içerebilir.

Son olarak bağlantıyı kesip yeniden bağlanın ve bir kez yeniden başlatın. Profil yalnızca ilk denemede çalışıyorsa sorun sırların işlenmesinde veya yolların sahipliğindedir ve ikisini de şimdi düzeltmek bir iş gününün ortasına göre daha ucuzdur.