PPP CHAP tek başına bir MPPE gereksinimini neden karşılayamaz

Şifrelemede ısrar eden bir PPTP profili genellikle aynı yerde başarısız olur: PPP, MPPE'nin ihtiyaç duyduğu anahtar malzemesini asla üretmeyen bir kimlik doğrulama takasında anlaşır. Tünel yarı canlı görünür, parola kabul edilir ve bağlantı üzerinden herhangi bir trafik geçmeden önce kopar. Bir şey bağlanana kadar CHAP açılır listesine uzanmak gerçek kusuru gizler, o kusur ise kimlik doğrulama yöntemi ile koruma politikası arasındaki bir sözleşmedir. Aşağıdaki kontroller, her biri bir sonrakinden daha ucuz bir nedeni dışlayacak şekilde sıralanmıştır.

Tek bir PPTP bağlantısı içinde iki müzakere yürür

PPTP, bir GRE tüneli içinde normal bir PPP oturumu taşır ve ikisi ayrı ayrı müzakere eder. Dış katman paketlerin nasıl kapsülleneceğine ve hangi denetim kanalının bulunacağına karar verir; iç PPP oturumu eşin kim olduğuna ve üstte hangi korumanın gideceğine karar verir. Bu yüzden bir parola istemi yalnızca iç katman hakkında bir şey kanıtlar ve tamamlanmış bir dış el sıkışma ikisi hakkında da hiçbir şey kanıtlamaz. Profiller burada başarısız olur çünkü insanlar tüneli hata ayıklarken anlaşmazlık PPP'nin içinde oturur.

Düz CHAP, RFC 1994'teki meydan okuma-yanıt takasıdır ve yalnızca paylaşılan bir sır üzerine kuruludur. MS-CHAPv2, farklı mesajlar ve farklı çıktı ile başka bir takastır ve RFC 2759'da standartlaştırılmıştır. İki addaki ortak kelime, tel üzerinde ortak oldukları tek şeydir. Hiçbir ad, takasın ne ürettiğini söylemez ve önemli olan tek kısım budur.

Bu yüzden yalnızca CHAP olarak etiketlenmiş bir seçenek eski bir profilde belirsizdir. Sunucu MS-CHAPv2 isterken istemci düz CHAP sunduğunda, bağlantı denetimi yine de tamamlanabilir ve bir parola yine de kabul edilebilir. Hata daha sonra, sunucu hiçbir şey üretmemiş bir takastan koruma anahtarları türetmeye çalıştığında gelir.

Gerekli yöntemi üretebileceği anahtarlarla eşleştirin

MPPE anahtarları genel olarak PPP'nin bir özelliği değildir. Microsoft CHAP ailesi için türetme RFC 3079'da belirtilmiştir ve girdi olarak paylaşılan bir sır yerine bir MS-CHAP takasının çıktısını alır. EAP yöntemleri aynı yere başka bir yoldan ulaşır; kimlik doğrulama sunucusu anahtarları MS-MPPE-Recv-Key ve MS-MPPE-Send-Key öznitelikleri olarak döndürür. Düz CHAP iki yolun hiçbirinde görünmez ve bu uyumsuzluğun var olmasının tüm nedeni budur.

MPPE isteyip anahtar sağlayabilen her yöntemi reddeden bir yapılandırma kendi içinde çelişkilidir. pppd bu çelişkiyi anahtar uydurarak değil, bağlantıyı reddederek çözer, bu yüzden görünen sonuç kimlik doğrulaması yapıp ardından ağ aşamasında sona eren bir oturumdur. Sunucu bir şey türeten tek yöntemleri reddettiği sürece istemciyi yeniden denemek bunu değiştirmez.

Bundan çıkan kural kısadır: profil MPPE istiyorsa yöntem bir MS-CHAP varyantı ya da sunucunun anahtarlarını döndürdüğü bir EAP yöntemi olmalıdır. Yalnızca MS-CHAPv2'yi reddetmek bunu dayatmaz, çünkü MS-CHAPv1 de anahtar türetir ve ayrıca reddedilmedikçe kullanılabilir kalır; ikisini de reddetmek düz CHAP ve PAP'ı bırakır, bunlar hiçbir şey türetmez ve gereksinimi karşılanamaz hale getirir. Sevmediklerinizi listelemek yerine kabul edilen yöntemi açıkça adlandırın. Bir istemcinin bağlanması için şifreleme gereksinimini bırakmak bir onarım değil, düşürmedir.

Bir istemciyi düzenlemeden önce sunucunun seçeneklerini okuyun

Bu uyumsuzlukların çoğu sunucuda iki dosyada görünür ve bunları okumak bir istemciyi yeniden kurmaktan daha ucuza gelir. Bir Linux PPTP uç noktasında ilgili ayarlar, pptpd'nin ilettiği pppd seçenekler dosyasında yaşar. Bunu sunucuda çalıştırın, istemci durum ekranından değil. Koruma kipini isteyen, reddeden veya adlandıran satırlarla başlayın:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Çıktıyı bir bayrak listesi olarak değil, bir sözleşme olarak okuyun. MPPE isteyip MS-CHAP'in iki varyantını da reddeden bir satırı hiçbir istemci karşılayamaz ve bir MS-CHAP yöntemi için eksik gereksinim, anahtar vermeyen takaslara kapıyı açık bırakır. Ardından kimlerin kimlik doğrulamasına izin verildiğini kontrol edin; bunu sırlar dosyası belirler:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Herhangi bir şeyi değiştirmeden önce üç değer yazın: dış protokol, sunucunun istediği kimlik doğrulama yöntemi ve korumanın zorunlu mu isteğe bağlı mı olduğu. Bu üçü sonraki her kararı belirler ve bunları bir istemci iletişim kutusundan tahmin etmek, bir profilin yarı yapılandırılmış kalmasının yoludur. Çalışırken dosyayı açık tutun, çünkü sonraki bölüm aynı üç değere ihtiyaç duyar.

Hatayı PPP aşamasına göre bulun

PPP hataları aşamalar halinde bildirir ve aşama sözleşmenin hangi maddesinin kırıldığını söyler. Bağlantı denetiminden hiç çıkmayan bir bağlantıda kapsülleme veya müzakere sorunu vardır; kimlik doğrulaması yapıp sonra ölen bir bağlantıda ise genellikle politika veya anahtar sorunu bulunur. Yukarıda kalıp hiçbir şey taşımayan bağlantı yönlendirmeye geçmiştir, bu başka bir incelemedir.

Günlük aşama satırlarını tutar ve bunlar daha yüksek bir hata ayıklama düzeyinden daha yararlıdır. PPP süreçlerini ve koruma iletilerini isteyin, ardından her şeyden önce kimlik doğrulama sonucunu okuyun. Son satırlar genellikle reddeden maddeyi adlandırır:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Bu çıktıda önce kimlik doğrulama sonucunu, ardından korumanın istendiği ama müzakere edilmediği şikayetini arayın. İkinci ileti yukarıdaki çelişkinin imzasıdır ve sunucu anahtar üretebilen tek yöntemi reddettiği sürece hiçbir yeniden deneme onu silmez. İki tuzağı adlandırmaya değer: aşama satırlarını okumadan hata ayıklama düzeyini yükseltmek gürültü üretir ve meydan okuma malzemesini veya parolaları yakalamak bir yapılandırma görevini kimlik bilgisi sızıntısına dönüştürür. Herhangi bir seçeneği değiştirmeden önce o aşamayı kaydedin.

Eski uç nokta kapatılmadan önce çıkışı planlayın

MPPE tarihsel bir bağlantı koruma mekanizmasıdır ve varlığı PPTP'yi yeni bir kurulum için makul bir seçim yapmaz. Microsoft'un güncel kılavuzu yeni uzak erişim kurulumları için PPTP'ye ve önceden paylaşılan anahtarlı L2TP/IPsec'e karşı zaten tavsiye eder. Eski bir uç noktayı canlı tutmak mevcut bir hizmet hakkında karardır, bir sonraki için şablon değildir.

Uç nokta kalması gerektiğinde sözleşmeyi yazın: dış protokol, gerekli kimlik doğrulama yöntemi, zorunlu koruma ve bunu müzakere eden istemci sürümü. Gidebileceğinde, eski profile dokunmadan önce yerine geçenin ağ geçidi kimliğini, istemci kimlik doğrulamasını ve kimlik bilgilerinin nerede yaşayacağını seçin. Ardından yolları, DNS'i ve her kullanıcının erişmeye yetkili olduğu kaynakları planlayın. Amaçlanan istemciyi çalışan bir bağlantıya göre değil, sahibinin gereksinimlerine göre doğrulayın.

Kasıtlı bir ret ret olarak kalmalıdır, çünkü bir testin geçmesi için korumasız bir kipe dönmek bir politika başarısızlığını maruz kalmaya dönüştürür. Bitmiş durum desteklenen, belgelenmiş bir sözleşmedir; eski bir bağlantıyı başarılı kılan en küçük değişiklik kümesi değildir. Yerine geçen aynı kontrolleri geçene kadar eski profili yerinde, kullanılmadan ve belgelenmiş olarak bırakın.