L2TP bağlanıyor ama PPP pazarlığı başarısız: hangi aşama?

IPsec tüneli kurulur, istemci korumalı bir eş gösterir ve sonra bağlantı özel alt ağa hiçbir şey ulaşmadan ölür. Bu boşluk PPP'nin kendi işini yapmasıdır: bağlantı seçenekleri, kullanıcı kimlik doğrulaması ve adres ataması hepsi şifreli tünel var olduktan sonra gerçekleşir. Başarılı bir ilk aşama değişimi hiçbir parola veya iç adres vermez. Aşamaları sırayla okuyun; arıza genellikle kendi adını koyar.

Tünel yalnızca ilk katmandır

L2TP, PPP çerçevelerini IPsec ile korunan bir tünel içinde taşır; yani bir paketin yönlendirilebilmesi için iki bağımsız pazarlığın başarılı olması gerekir. Dıştaki, iki ucun anahtarlar ve kimlikler üzerinde anlaştığını kanıtlar. İçteki ise bağlantı parametrelerini, kullanıcının kimlik doğrulamasından geçip geçmediğini ve istemcinin hangi adresi aldığını belirler.

PPP içindeki bir arıza, tek bir durum ışığı gösteren her istemcide bozuk tünel gibi görünür. Bunu tünel sorunu saymak anahtarların yeniden üretilmesine, hizmetlerin yeniden başlatılmasına ve sonunda hiç yanlış olmamış paylaşılan bir sırrın değiştirilmesine yol açar. Yararlı ayrım ucuzdur: eş ile değişim tamamlandıysa ve istemci kullanıcı adı istemine veya kimlik doğrulama aşamasına geçtiyse tünel iyidir. Bu noktadan sonraki her şey PPP'ye aittir.

Başarılı olan son aşamayı okuyun

Günlüğü ileri doğru yürütün ve tamamlanmayan ilk aşamada durun. Önce LCP gelir, sonra kimlik doğrulama, sonra IPv4 parametreleri için IPCP.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP zaman aşımı, iki ucun temel bağlantı seçenekleri üzerinde hiç anlaşmadığı anlamına gelir; bu kötü parola değil, profil uyuşmazlığı veya engellenmiş bir iç protokoldür. Açık kimlik doğrulama reddi tam tersi durumdur: bağlantı kalktı ve bir taraf kimlik bilgilerini reddetti. Başarılı kimlik doğrulamadan sonra IPCP zaman aşımı adres havuzlarına veya sunucu ilkesine işaret eder. Her birinin farklı sahibi ve farklı onarımı vardır, bu yüzden aşama son hata metninden daha önemlidir.

Günlük kesitini aşama adıyla birlikte kayıtta saklayın. Aşama sınırı olmadan yapıştırılan bir kuyruk sonraki okuyucuyu tahmine davet eder ve burada tahmin bir saate mal olur.

İstemci ile sunucu arasındaki anlaşma

İki uç da aynı kimlik doğrulama yöntemini kabul etmelidir ve kayıtlı bir profil, sunucunun geçen çeyrekte kaldırdığı bir yöntemi isteyebilir. Yönetilen kurulumlar sunucu tarafını da gizler; orada ret nedeni genellikle cihaz yerine kullanıcı üzerine kaydedilir.

Her eski seçenek yerine desteklenen tek bir yöntemi etkinleştirin, çünkü beş yöntem sunan bir istemci hangisinin başarısız olduğunu örter. Yöneticiden sunucu tarafı ilkesini ve tam reddi isteyin; bu kimsenin parola yayımlamasını gerektirmez. Tek bir istemciyi kurtarmak için etkinleştirilen eski bir yöntem, dosyayı kopyalayan her profile yayılma eğilimindedir.

Adresi doğrulayın, oturum açmayı değil

Tamamlanmış bir oturum açma kullanılabilir oturum değildir. IPCP iç adresi pazarlık eder ve tükenmiş bir havuz veya istemciyi reddeden bir ilke, bağlı bir tüneli yönlendirilecek hiçbir şey olmadan bırakabilir.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Önce iç adresi, sonra gerçekten ihtiyaç duyduğunuz kaynak için rotayı ve çözümleyiciyi kontrol edin. İç adres bir web sitesinin bildirdiği genel çıkış değildir ve ikisini karıştırmak insanları olmayan bir sızıntıyı aramaya gönderir. Özel kaynağı adla sınamadan önce adresle sınayın ki DNS arızası yönlendirme arızası sanılmasın.

Aşamayı, yöntemi ve adresi tek bir nota yazın ve tarih atın. Aynı hesap bir ay sonra yeniden başarısız olursa o not, beş dakikalık bir kontrol ile yeni bir soruşturma arasındaki farktır. Farklı aşamalardaki arızalar farklı olaylardır, istemci tek bir iletişim kutusu gösterse bile.