L2TP/IPsec başarısız: IPsec, tünel kimlik doğrulaması veya PPP oturumunu ayırın

Tek bir L2TP/IPsec bağlantısı içinde üç şey kimlik doğrulaması yapar ve bunlardan yalnızca biri arama yapan kişiyi ilgilendirir. IPsec tünelin uç noktalarını kanıtlar, L2TP denetim bağlantısı eşleri kendi sırrıyla yeniden kanıtlayabilir ve ardından PPP oturum içindeki kullanıcı hesabını kanıtlar. Herhangi bir aşamadaki başarısızlık istemci penceresinde genel bir oturum açma hatası gibi görünür, sunucu günlüğünde ise tamamen farklı görünür. Aşamaları sırayla geçin ve ilk başarısız olanda durun, çünkü test edilmemiş bir aşamanın altındaki her aşama da test edilmemiştir.

Üç kimlik doğrulama aşaması, üç farklı kimlik

IPsec, uç noktaların kime ait olduğunu önceden paylaşılan bir anahtar veya sertifika kullanarak kanıtlar. Bu kimlik makinelere veya ağ geçitlerine aittir, asla klavyedeki insana değil. Eşler bu aşamada anlaşamazsa hiçbir L2TP paketi alınıp verilmez.

L2TP denetim bağlantısı, iki uçta da bulunması gereken ortak bir sır tarafından yürütülen ikinci ve ayrı bir meydan okuma-yanıt alışverişi ekleyebilir.

RFC 2661 bu denetim bağlantısı kimlik doğrulamasını isteğe bağlı yapar, bu da aynı hatanın iki sunucuda neden farklı belirtiler verdiğini açıklar. Tünel sırrını hiç yapılandırmamış bir kurulum bu aşamayı tamamen atlar; yalnızca tek tarafta yapılandırmış olan ise PPP hiç sunulmadan başarısız olur. Ardından PPP kullanıcıyı PAP, CHAP veya MSCHAPv2 ile doğrular ve adı yerel, chap-secrets içinde veya RADIUS üzerinde olabilecek bir hesap deposuna verir. Bu noktada yanlış bir parola sizi yine de çalışan bir tünel ve başarısız bir oturumla baş başa bırakır.

Yapılandırmayı düzenlemeden önce durma noktasını okuyun

Durum çıktısının strongSwan'a mı Libreswan'a mı ait olduğunu bilmek için ipsec --version ile başlayın. Ardından istemci penceresini değil sunucu günlüğünü okuyun, çünkü hangi aşamanın reddettiğini sunucu kaydeder.

Tek bir satır genellikle kaydı çözer: IKE veya önerilerle ilgili şikayet birinci aşamadır, denetim bağlantısı mesajı ikinci aşamadır ve PPP yöntemi veya hesap reddi üçüncü aşamadır. O satırı zaman damgasıyla birlikte kayda kopyalayın. İstemci tarafından tahmin yürütmek, zaten elinizde olan tek kanıtı harcar.

Anahtar malzemesini ve parolaları o yapıştırmadan uzak tutun; aşamanın adı işi yönlendirir ve sızan önceden paylaşılan anahtar kaydı daha kötü sonuçlarla yeniden açar.

Birinci aşama: IPsec'in bir ilişkilendirmesi var mı?

strongSwan üzerinde ipsec statusall veya Libreswan üzerinde ipsec whack --status çalıştırın ve sıfır olmayan sayaçlara sahip kurulmuş bir alt ilişkilendirme arayın. ip xfrm state ikisinde de çekirdek görünümünü gösterir. Sayaçları artan kurulu bir SA çifti, birinci aşamanın bittiği ve ilerleyebileceğiniz anlamına gelir.

İlişkilendirmenin hiç olmaması eş adresine, öneri kümesine veya önceden paylaşılan anahtara işaret eder ve bazen UDP 500'ü yeniden yazıp UDP 4500'ü düşüren bir cihaza da işaret eder. Kurulup birkaç saniye sonra kaybolan bir ilişkilendirme genellikle kimlik bilgileri sorunu değil, iki uç arasındaki ömür uyuşmazlığıdır. Bir şeyi yeniden yazmadan önce iki tarafın da aynı şifreleme ve karma önerilerini listelediğini kontrol edin. Listelemiyorsa hiçbir anahtar asla çalışmaz.

İlişkilendirme eksik olduğu sürece durun. O noktada PPP seçeneklerini düzenlemek hiçbir şeyi değiştirmez ve gerçek arızayı sıradaki kişiden saklar.

İkinci aşama: L2TP denetim bağlantısı kimlik doğrulaması yaptı mı?

IPsec ayağa kalktığında, L2TP arka plan programını kurulmuş duruma ulaşan bir denetim bağlantısı için izleyin, çünkü PPP ondan önce başlayamaz. Denetim bağlantısındaki bir ret, tünel sırrının uçlar arasında farklı olduğu veya bir ucun diğerinin hiç göndermediği bir sırrı istediği anlamına gelir. İstemciler genellikle shared secret etiketli tek bir alan gösterir ve bu alan genellikle L2TP'ye değil IPsec'e aittir. Onu doldurmak tünel sırrını yapılandırmaz, temizlemek ise devre dışı bırakmaz.

Hiçbir taraf tünel sırrı yapılandırmadıysa bu aşamayı atlayın ve denetim bağlantısı hatasını bunun yerine erişilebilirlik sorunu olarak ele alın. UDP 1701'in arka plan programına ulaştığını ve iki ucun aynı kapsülleme üzerinde anlaştığını doğrulayın. Bu iki koşuldan biri için yazılmış bir güvenlik duvarı kuralı, yarısı açılan bir bağlantının yaygın nedenidir.

Yalnızca PPP görüşmesine başlayan oturum tünel aşamasını gerçekten geçmiştir.

Üçüncü aşama: PPP hesabı reddediyor mu?

PPP hatası dışarıdan farklı görünür: tünel kurulmuştur, oturum başlar ve arka plan programı bir kimlik doğrulama yöntemi hatası veya hesap reddi kaydeder. O mesajda adı geçen yöntemi okuyun. PAP ve CHAP farklı nedenlerle başarısız olur ve birini reddeden sunucu yalnızca onu sunan istemciyi de reddeder.

Bir Linux sunucusunda, arka plan programının PPP'ye verdiği seçenek dosyasını, genellikle /etc/ppp/options.xl2tpd, inceleyin ve hangi yöntemlerin kabul edildiğini ve hesapların nerede çözüldüğünü doğrulayın. RADIUS'ta bulunup yerel sırlar dosyasında bulunmayan bir ad temiz biçimde başarısız olur ve yanlış parola gibi görünür. Ardından istemcinin sunucunun kabul ettiği bir yöntem sunduğunu, sunucunun görüşmeyi reddettiği daha güçlü bir yöntemi sunmadığını kontrol edin. Bu aşamayı onarmak için önceden paylaşılan anahtarı değiştirmek bir öğleden sonrayı harcar ve hiçbir şeyi değiştirmez.

Oturum sonunda ayağa kalktığında, adres ataması, DNS ve rotalar henüz denetlenmedi, ve her biri kendi biçiminde sessizce başarısız olur. Üç katmanı notlarınızda ayrı tutun: doğru anahtar ile yanlış hesap her zaman başarısız olur ve bir katmanı onarmak asla diğerini onarmaz.