L2TP NO_PROPOSAL_CHOSEN: hangi aşama gerçekte başarısız oldu?
Bildirim bir önerinin reddedildiğini söylüyor, hangisinin olduğunu değil. Aşamayı bulmak için backend günlüğünü okuyun, sonra paketleri ağ geçidini yönetenle karşılaştırın.
NO_PROPOSAL_CHOSEN, herhangi bir PPP kullanıcı adı incelenmeden önce gelir; bu yararlı bir gerçektir ve aynı zamanda mesajın neden yanıltıcı olduğunun nedenidir. Bir tarafın bir öneriyi reddettiğini bildirir; hangi parametrenin uyuşmadığını bildirmez ve reddin IKE ilişkisinin kurulması sırasında mı yoksa daha sonra trafik korumasının müzakere edilmesi sırasında mı gerçekleştiği konusunda hiçbir şey söylemez. Bu iki olasılığın arkasında iki farklı düzeltme vardır ve bunlardan yalnızca biri insanların ilk başvurduğu PFS onay kutusuyla ilgilidir.
Tek mesaj, iki öneri kümesi
IKEv1 L2TP/IPsec düzeninde art arda iki müzakere vardır. Aşama 1, IKE güvenlik ilişkisini bir şifreleme algoritması, bir bütünlük algoritması ve bir Diffie-Hellman grubundan kurar. Ardından aşama 2 trafiğin nasıl korunacağını müzakere eder ve PFS gereksinimi o ikinci konuşmaya aittir.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Aşamalar sıralı olduğu için arızanın konumu hangi listeyi karşılaştıracağınızı söyler. Mesajın tüm tanılama değeri buradadır ve herhangi bir ayara dokunmadan önce bunu çıkarmaya değer.
PFS onay kutusu aşama 1'i neden onaramaz
PFS'yi devre dışı bırakmak aşama 2'nin bir özelliğini değiştirir. Taraflar aşama 1 üzerinde hiç anlaşamadıysa ESP konuşması hiç gerçekleşmez, bu yüzden onay kutusunun reddetme üzerinde hiçbir etkisi yoktur ve bu nedenle değiştirilmesi aynı hatayı farklı bir zaman damgasıyla verir.
Ters hata da aynı derecede yaygındır. Başarılı bir IKE ilişkisi ESP önerisinin kabul edilebilir olduğunu kanıtlamaz ve aşama 2 grubunun eşleştiğini kesinlikle kanıtlamaz. Kurulmuş bir yönetim tünelini yalnızca aşama 1 hakkında kanıt olarak değerlendirin. İnsanlar yeşil satırı «tünel ayakta» diye okur ve ardından ikinci müzakerenin başlamadığını kimse söylemediği için yanlış aşamada bir saat harcar.
Algoritmaları seçmeden önce günlüğü okuyun
Reddetmeden hemen önceki mesajları bağlantıyı gerçekten işleyen backend'den toplayın ve aynı denemeyle ilişkilendirin. Bu ilişkilendirme olmadan başka bir bağlantının geçmişini okuyor ve ondan sonuç çıkarıyorsunuz.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanBu satırlardan iki soruyu yanıtlayın: aşama 1 ilişkisi kuruldu mu ve hangi değiş tokuş başarısız oldu. Bu iki yanıt aramayı tek bir öznitelik listesine daraltır. Çevresinde bağlam olmayan çıplak bir bildirim bunu yapamaz, forum başlığından bir öneri denemek ne kadar cazip olsa da. Başka bir backend'e sahip makineden çalışan bir dizeyi kopyalamak genellikle bir reddetmeyi bir diğeriyle değiştirir, biraz daha geç.
Backend sözdizimi yolculuk etmez
Herhangi bir şeyi karşılaştırmadan önce NetworkManager-l2tp sürümünü ve IPsec backend sürümünü not edin. Libreswan ve strongSwan ne öneri sözdizimini ne de aynı algoritma kümelerini paylaşır, bu yüzden birinde çalışan bir dize diğerinde sözdizimi hatasıdır. Kurulu backend IKEv1'i politikaya göre de reddedebilir ve o zaman hiçbir öneri asla kabul edilmez.
Projenin README dosyası bu backend farklarını belgeler ve aşama 1 ile aşama 2 alanlarını ayrı tutar. Onu yapının belgesi olarak okuyun, her tarihsel şifreleme yöntemini ve zayıf bir grubu açma daveti olarak değil, çünkü yalnızca böyle başarılı olan bir bağlantı sizden kurmanız istenen bağlantı değildir.
Paket üzerinde anlaşın, sonra aşamaları doğrulayın
Ağ geçidi operatörüne hangi IKE ve ESP paketlerinin desteklendiğini ve onaylandığını sorun, sonra bu yanıtı istemcinin yapılandırma dosyasıyla değil gerçek önerileriyle karşılaştırın. Anlaşmazlık özellikle aşama 2 PFS'si ile ilgiliyse, desteklenen bir grup veya açıkça onaylanmış PFS'siz bir politika üzerinde karar kılın. Politikayı hatanın adından çıkarsamayın.
Tek örtüşme, kuruluşun artık kabul etmediği bir kriptografi gerektirdiğinde karar ağ geçidine veya bir protokol geçişine aittir. İstemci dizesini bir şey müzakere edene kadar genişletmek, bilinen bir zayıflığı yanında yeşil bir onay işaretiyle teslim etmenin yoludur.
Gerçek uyuşmazlığı düzelttikten sonra, L2TP ve PPP'yi araştırmadan önce IPsec kurulumunu doğrulayın ve sonraki herhangi bir kimlik doğrulama reddini bir sonraki aşamaya ait sayın. Ardından yenilemeyi onaylanmış test sürecinde deneyin, çünkü ilk ilişkinin kurulması ömrünün geri kalanı hakkında hiçbir şey söylemez.