L2TP/IPsec PSK reddedildi: önce iletişim kutusu, sonra dosyalar

Yöneticinin mesajındaki önceden paylaşılan anahtarı NetworkManager iletişim kutusuna yapıştırırsınız, göstermek için kutuyu işaretlersiniz ve anahtar karakter karakter eşleşir. Bağlantı yine de tünel kalkmadan bir kimlik doğrulama hatasıyla sonlanır. Bunu ilk gördüğümde anahtarın yanlış olduğunu sandım; değildi. Demonun gerçekte ne okuduğunu iki başka şey belirler: eklentinin o bağlantı için yazdığı sır dosyası ve değerin iletişim kutusundan değişmeden geçip geçmediği.

Aşağıdaki yol anahtarı alandan dosyaya kadar izler ve nerede kaybolduğunu söyleyen şey tam olarak bu sıradır. Bunu çalışan makinede değil, başarısız olan makinede yapın, çünkü iki makine arasındaki fark genellikle anahtar değil dosya düzenidir.

İletişim kutusundan başlayın, ama alana güvenmeyin

Bağlantının IPsec sekmesini açın ve anahtarı yapıştırmak yerine yeniden yazın. Bir sohbet mesajından, PDF'ten veya parola yöneticisinden kopyalanan anahtar, alanın göstermediği bir satır sonuyla gelebilir ve görünen karakterler yine de doğru görünür.

Parolayı gösterme denetimine tıklayın ve dizenin ortasına değil sonuna bakın. İmleç metnin altında boş bir satır bırakıyorsa onu silin ve son karakteri yeniden yazın. Bu tek düzeltme bu tür bildirimlerin şaşırtıcı bir bölümünü çözer ve herhangi bir günlüğü okumaktan daha ucuza gelir.

Anahtar uzun satırları kıran bir bilet sisteminden geliyorsa, kırmayan bir kanaldan isteyin. İki dizeyi yan yana gözle karşılaştırmak yerine uzunlukları yöneticiyle karşılaştırın; kırılma noktasında kaybolan karakter orantılı bir yazı tipinde görünmez.

Anahtarı /etc/ipsec.d içine kadar izleyin

Eklenti PSK'yı hiçbir zaman IPsec demonuna komut satırında argüman olarak vermez. Bunun yerine değeri bir sır dosyasında saklar ve demonun o dosyayı içeri almasını sağlar, yoksa /etc/ipsec.secrets dosyasına bir include satırı ekler. İletişim kutusunun tuttuğu şey üretilen dosya için bir girdidir, kullanımdaki değer değil.

Herhangi bir şeyi değiştirmeden önce neler olduğunu listeleyin:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Eklentinin eski sürümleri her bağlantı için bir dosya yazardı, bağlantının UUID'sine göre adlandırılırdı, örneğin /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Bir profili uygulamada silmek o dosyayı güvenilir biçimde silmez. Önceki bir sunucudan kalan eski bir dosya hâlâ diskteyse ve hâlâ içeri alınıyorsa demon artık kullanmadığınız bir profile ait bir sırrı seçebilir ve görünen alan doğruyken bağlantı başarısız olur.

1.2.12 değişikliğinin yükseltmelere ne yaptığını anlayın

Eklentinin 1.2.12 sürümü bağlantı başına sır dosyalarını tek bir paylaşılan dosyayla değiştirdi, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Yükseltme, UUID'ye göre eski dosyaları temizlemez ve var olan include /etc/ipsec.d/*.secrets satırı onları içeri almaya devam eder. 1.2.16 sürümü varsayılan önerilerin işlenmesini değiştirdi, sırların düzenini değil.

Bu geçmiş, aynı görünen profile sahip iki makinenin neden farklı davrandığını açıklar. Anahtar aynıdır; demonun içeri aldığı dosya kümesi aynı değildir. Sahipsiz bir dosyayı kaldırırken silmek yerine kenara taşıyın, bağlantıyı doğrulayın ve ancak çalışan durum kaydedildikten sonra silin. Yeniden adlandırmak, arıza başka yerdeyse eski değerin geri alınabilir kalmasını sağlar.

Depolama biçiminin tutamadığı karakterleri ayırın

strongSwan'ın paylaşılan sır dizesine ilişkin belgeleri, değerin satır sonu veya çift tırnak karakteri içeremeyeceğini belirtir. Bir belgeden yapıştırılan anahtar, normal bir iletişim kutusunda hiçbir görsel fark olmadan bunlardan birini taşıyabilir.

1.2.12'den beri saklanan değer düz metin değildir. Eklenti PSK'yı dosyaya ulaşmadan önce base64 ile kodlar ve sürüm notları bu kodlamayı çift tırnağın artık anahtarda kabul edilebilir olmasının gerekçesi olarak gösterir. Bu yüzden alana yazılan tırnak temsil edilebilir; aynı şey her denetim karakteri için geçerli değildir.

Uzunluk başka bir kısıttır. L2TP/IPsec yazılımında evrensel bir alt sınır yoktur: bazı istemciler yirmi karakterden kısa anahtarları kabul eder, bazı ağ geçitleri bir alt sınır uygular. Kısa bir anahtar reddedilirse kural sunucu ilkesine veya o istemcinin doğrulamasına aittir ve yerelde bir şeyi yükseltmek bunu değiştirmez.

Hangi kimlik doğrulama katmanının başarısız olduğunu okuyun

Önce ipsec --version komutunu çalıştırın, çünkü strongSwan ile Libreswan farklı dosya adları ve sözdizimi kullanır ve biri için verilen tavsiye diğerine zarar verebilir. Ardından başarısızlık aşamasını istemcinin mesajından veya demonun günlüğünden okuyun: önceden paylaşılan anahtarla ilgili bir şikâyet, reddedilen kullanıcı adı ve paroladan farklı bir olaydır.

PSK tünelin uçlarını doğrular. Kullanıcı adı ve parola L2TP içindeki kişiyi doğrular ve IPsec ilişkisi kalktıktan sonra PPP bunlarla ilgilenir. Doğru PSK yanlış hesapla yine başarısız olur ve hesabı değiştirmek, demonun hiçbir zaman doğru okumadığı bir anahtarı onarmaz.

Bileti kapatırken dördünü de yazın: eklenti sürümü, kullanılan sır dosyası, anahtarın yeniden yazılıp yazılmadığı veya yapıştırıldığı ve hatada adı geçen katman. Böylece bu yolu sonradan yineleyen herkes, çalışan ve başarısız makine arasındaki farka doğrudan atlayabilir.