VPN'in hangi aşaması başarısız oldu: IPsec, L2TP denetimi veya PPP kimlik doğrulaması

Parolayı değiştirdiniz ve hiçbir şey kımıldamadı, çünkü arıza hiçbir zaman PPP'de değildi. L2TP/IPsec beş çok farklı teslim için tek bir bağlantı hatası bildirir ve her teslimin kendi onarımı vardır. Ters yönde çalışın: son başarılı aşamayı bulun ve yalnızca ondan sonra geleni değiştirin. Aşağıdaki sıra hangi kanıtı önce toplayacağınızı da belirler.

Dört soruyu sırayla yanıtlayın

Yeni bir deneme zorlayın, çünkü bazı istemciler profil bağlantısı kesilip yeniden kurulana kadar önceki hatayı göstermeye devam eder. Sonra şunu yanıtlayın: IPsec güvenlik ilişkisi var mıydı, L2TP denetim bağlantısı ve çağrı göründü mü, PPP kimlik doğrulama kararına ulaştı mı ve IPCP istemciye adres verdi mi? İlk hayır düzelttiğiniz aşamadır. Sonrasındaki her şey test edilmemiştir, bu yüzden ilişki hiç oluşmadıysa reddedilen kullanıcı adı hiçbir şeyi kanıtlamaz.

Karşılaştırmadan önce iki uçtaki saatleri eşitleyin. IPsec'i temizleyip PPP'de başarısız olan yeni deneme, istemci yalnızca son mesajı gösterdiğinde ve sunucu günlüğü hâlâ önceki denemeyi tuttuğunda tek bir arıza gibi görünür. En gürültülü satıra göre değil, zaman damgasına göre okuyun.

Elinizde yalnızca kullanıcının ekran görüntüsü varsa en ucuz ayrıma yaslanın: yanlış ön paylaşımlı anahtar ve hiç yanıt vermeyen xl2tpd Windows iletişim kutusunda aynı metni üretir, ancak biri iki uçta da değiştirilmiş bir sır ister, diğeri sunucunun kendisinde başlatılmış bir servis veya güvenlik duvarı kuralı ister. Ortadaki cihaz, taşıma kipindeki IPsec onu sardıktan sonra içteki 1701'i düşüremez, bu yüzden olmayan bir yol süzgeci aramayın.

Her katman gerçekte neyi sahiplenir

IPsec iki eş arasındaki paketleri korur; L2TP o korumalı yolun içinde bir PPP oturumu taşır, bu yüzden RFC 3193 kendi tüneline değil taşıma kipine hükmeder. İstemci etiketi L2TP der, bu yüzden tünel ve giriş tek bir mekanizma gibi görünür. Değiller: L2TP denetim bağlantısı, dağıtımın etkinleştirdiği yerde tünel uçlarının kimliğini doğrular; PPP ise sunucu ilkesine göre kullanıcıyı ayrıca CHAP, PAP veya MS-CHAPv2 ile doğrular.

Bu ayrım, insanların sürekli karıştırdığı iki sırrı açıklar. Ön paylaşımlı anahtar IPsec eşlerini doğrular. Kullanıcı adı ve parola kullanıcıyı PPP'ye tanıtır. Sertifikayla doğrulama yapan bir profilde Windows'un paylaşılan sırrını yeniden yazmak başarısız aşamada hiçbir şeyi değiştirmez ve PPP parolasını düzenlemek eksik korumalı kanalı sağlayamaz. Aynı ölçülülük kimlik denetimi için de geçerlidir: tünel elde etmek için eşin kimliğini veya sertifika doğrulamasını kapatmayın, çünkü o zaman bağlanan yol olur, eş değil.

Kimlik doğrulama da PPP'nin sonu değildir. Kullanıcı kabul edildikten sonra IPCP istemci adresi ile sunucunun vermeye razı olduğu DNS ve WINS seçeneklerini pazarlık eder. İstemci CHAP veya MS-CHAPv2'yi geçip yine de adressiz kalabilir; bu PPP içindeki bir arızadır, yönlendirme sorunu değil. IPsec'siz düz L2TP geçerli ve korumasız kalır, bu yüzden başarılı bir bağlantı trafiğin korunduğunu asla kanıtlamaz; sunucunun neyi zorunlu kıldığına bakın, istemci etiketine değil.

İlk eksik aşamaya göre karar verin

Tabloyu ilk eksik öğeye göre soldan sağa okuyun. Sağ sütun o anda değerli olan tek iştir; solundaki her şey zaten kanıtlanmıştır ve yeniden test etmek bilgi eklemeden kesinti penceresini yakar.

Üç satır uyarıyı hak eder. 1701 satırı, NAT arkasındaki Windows istemcilerinin genellikle indiği yerdir: ilişki tamamlanır, sonra hiçbir şey gelmez ve neden kötü parola değil kapsüllemedir. IPCP satırı yanlışlıkla yol sorunu olarak okunan satırdır, çünkü Windows eksik adresi 720 hatasına sarar ve tepsi simgesi yalnızca bağlantının başarısız olduğunu söyler; o arıza kimlik doğrulamadan sonra ve yönlendirmeden önce durur. Son satır hiç IPsec arızası değildir, simge bağlantı kesildi dese de.

Katmanları ayıran komutlar

strongSwan çalıştıran bir Linux sunucuda swanctl --list-sas kurulmuş ilişkileri eşin kimliğiyle listeler ve ipsec statusall daha eski strongSwan ve libreswan ana makinelerini kapsar. Altında ip xfrm state çekirdeğin gerçek ilişkilerini gösterir, ss -lunp | grep 1701 ise xl2tpd'nin nereye bağlı olduğunu kanıtlar. Denetim bağlantılarının ve çağrıların geldiğini görmek için xl2tpd -D'i ön planda çalıştırın ve sunulan yöntemle yanıtı görmek için /etc/ppp/options.xl2tpd içinde pppd hata ayıklamasını açın.

Günlükler başarılı kimlik doğrulama gösterdiğinde sıradaki soru IPCP'nin tamamlanıp tamamlanmadığıdır. /etc/xl2tpd/xl2tpd.conf dosyasının [lns default] bölümündeki ip range hâlâ boş adres içeriyor mu ve istemci bekliyorsa /etc/ppp/options.xl2tpd gerçekten ms-dns ile ms-wins taşıyor mu diye bakın. Tükenmiş havuzla eksik DNS seçeneği kabloda farklı görünür: ilki istemciyi adressiz ve 720 ile bırakır, ikincisi adres verir ama çözümleyici vermez, bu yüzden adlar başarısız olurken ham adreslere ping çalışır. İkisi de parolayı yeniden yazmakla düzelmez.

İstemcide NetworkManager'ın L2TP eklentisi pppd konuşmasını günlüğe yazar, bu yüzden journalctl -u NetworkManager -b genellikle tünel ayakta, kimlik doğrulama reddedildi durumunu hiç tünel yok durumundan ayırır. Windows'ta Get-VpnConnection profilin gerçek kimlik doğrulama ayarlarını bildirir ve Event Viewer'da Application altındaki RasClient olayları başarısız bileşeni adlandırır. İletişim kutusu çok belirsizse netsh ras set tracing * enable'i açın.

Yakalamalar tek bir dikkat ister. Taşıma kipinde IPsec ile içteki UDP 1701 şifrelidir, bu yüzden dış arayüzdeki yakalama ESP gösterir veya NAT-T altında UDP 4500 ve hiç L2TP göstermez. Yakalamada 1701'in olmaması beklenir ve kapalı bağlantı noktasının kanıtı değildir; ESP veya 4500 sayaçlarının kımıldayıp kımıldamadığına bakın.

NAT, MTU ve rotalar: yığının sizi yanılttığı yer

NAT, herhangi bir şey doğrulanmadan önce varsayımları kırar. ESP kendi IP protokolüdür, bu yüzden çeviri yapan cihaz eşler kapsüllemedikçe onu atar; tam olarak UDP 4500 bunu sağlar. Kendisi bir ev yönlendiricisinin veya bulut NAT geçidinin arkasında duran Windows sunucusunda IPsec aşaması 789 hatasıyla başarısız olur; PolicyAgent anahtarının altında AssumeUDPEncapsulationContextOnSendRule 2'ye ayarlanıp makine yeniden başlatılana kadar, arıza kapalı bağlantı noktasından ayırt edilemez kalır. NAT arkasındaki istemciler daha kolaydır: sunucuda genel bir adres varsa UDP 4500 üzerindeki NAT-T onları taşır ve o değer işe karışmaz.

PPP ayaktayken kara delikli MTU ölü bir tüneli taklit eder: küçük paketler geçer, TLS el sıkışması veya sayfa yüklemesi asılır ve istemci hâlâ bağlı görünebilir. Sunucuyu suçlamadan önce arayüzün MTU'sunu düşürün veya geçitte MSS'i sıkın. Bölünmüş tünel yönlendirmesi diğer sahtekârdır; yanlış maskeyle itilen bir alt ağ tüneli sağlıklı, bir uygulamayı erişilemez bırakır. Özel ana makine adı kendi adımını ekler: sorgu yerel çözümleyiciden çıkıyorsa, herhangi bir rota test edilmeden önce ad çözülemez.

Kimlik bilgilerine dokunmadan önce kontrol listesi

Listeyi sırayla işleyin ve başarısız olan ilk öğede durun. Her adım ucuzdur ve her biri bir bütün değişiklik sınıfını dışlar.

1. İlişkinin iki uçta var olduğunu doğrulayın, bağlandı etiketiyle değil eşin kimliğiyle eşleştirilmiş.
2. UDP 1701'in xl2tpd'ye ulaştığını doğrulayın; çağrısız ilişki sizin arızanızdır.
3. Parolanın yanlış olduğunu varsaymadan önce PPP'nin kararını ve doğruladıysa IPCP sonucunu okuyun.
4. Ancak şimdi kimlik bilgilerini sunucunun beklediği biçimde yeniden girin, çünkü etki alanı öneki hesabı değiştirir.
5. Hâlâ başarısızsa iki ucu hizalı zaman damgalarıyla yakalayın ve aşama aşama karşılaştırın.

İkinci adımda durmak yol veya kapsülleme sorunu demektir ve hiçbir parola düzenlemesi bunu kımıldatmaz. Üçüncü adımda durmak günlüğün düzeltilecek yöntemi veya adres havuzunu zaten adlandırdığı anlamına gelir. Her durumda bir sonraki değişiklik gerekçelendirebileceğiniz olandır ve hiç karışmamış ayarlarda dönmeyi bırakırsınız.