PPTP ve L2TP/IPsec neden kullanıcı adı isteminden önce duruyor?

Kullanıcı adı isteminin gelmemesi tanısal bir armağandır: PPP henüz başlamamıştır, dolayısıyla hesap, parola ve etki alanı ilkesi henüz sorulmamıştır. Bir PPTP veya L2TP/IPsec bağlantısında istemci kimlik bilgilerini ancak tünel var olduktan ve sunucu bir PPP oturumu başlattıktan sonra ister. O ana kadar başarısız olabilecek her şey taşıma, anahtar değişimi veya tünel kurulumudur; bu, «VPN bozuk» ifadesinden çok daha küçük bir alandır.

Eksik istem hatayı üç aşamaya daraltır

Görünür biçimde başarılı olan son aşamayı not edin, çünkü her birinin sahibi ve çözümü farklıdır. İki aşama önce tıkandığınız hâlde hesap ayarlarını tahmin etmek, bir öğleden sonranın yok olma biçimidir.

İstem olmadan zaman aşımına uğrayan istemci hiçbir zaman bir IPsec ilişkilendirmesi almadı; bu yüzden hata IKE'de ya da paketlerinizin ağ geçidine ulaşıp ulaşmadığındadır. Kimlik bilgilerini doğruladığını bildirip sonra düşen istemci, mesajın ima ettiğinden daha ileri gitmiştir. Ardından ret gelen bir istem, PPP kimlik doğrulamasıdır ve onun yeri hesap makalesidir, bu makale değil.

Birinci aşama: güvenlik duvarının sessizce düşürdüğü protokol

PPTP denetim kanalı için TCP 1723 ve veri yolu için IP protokolü 47 gerektirir; ikisi ayrı yolculuk eder. Birçok ağ 1723'ü iletir ve protokol 47'yi düşürür; bu da müzakere eden ama sonra hiçbir şey taşımayan bir tünel üretir. NAT yapan bir yönlendirici GRE destekli bir geçişe de ihtiyaç duyar ve yalnızca IPv6 olan bir erişim yolu hiçbir yapılandırmada PPTP taşıyamaz.

IPsec üzerinden L2TP, IKE için 500 numaralı bağlantı noktasını ve NAT aşımı için 4500 numaralı bağlantı noktasını harcar, ardından L2TP trafiğini 1701 içine sararken ilişkilendirme oluştuğunda ESP korunan yükü taşır. İki denetim bağlantı noktasına izin verip ESP'ye vermezseniz, başlıktaki belirtinin aynısını alırsınız: görünür ilerleme, ardından herhangi bir kimlik bilgisi iletişiminden önce ölü istemci. Telefon etkin noktasından test etmek, istemci sorununu yol sorunundan ayırmanın ucuz bir yoludur.

İkinci aşama: anahtar olmayan bir anahtar, teklif edilmeyen bir öneri

Eşleşmeyen önceden paylaşılan anahtar hızla ve sessizce başarısız olur; olağan sürüm, ekranda doğru görünen ama yapıştırılmış bir satır sonu veya sonda bir boşluk taşıyan anahtardır. Bir Linux istemcisinde iletişim kutusu mutlaka doğrunun kaynağı değildir: NetworkManager'ın L2TP eklentisi sırları /etc/ipsec.d/ altındaki dosyalarda tutar ve /etc/ipsec.secrets dosyasının hâlâ içerdiği eski bir bağlantı başına dosya, az önce yazdığınızın yerine kullanılır. O dosyayı güvenli bir yere kopyalayın, içerme yolundan çıkarın ve sonra anahtarı elle yeniden yazın.

Bu aşamanın diğer yarısı öneridir. İki uç da aynı faz 1 algoritma kümesi üzerinde — şifreleme, bütünlük ve Diffie-Hellman grubu — ve faz 2 için eşleşen ESP dönüşümleri üzerinde anlaşmalıdır, yoksa ilişkilendirme hiç oluşmaz. Yalnızca 3DES, SHA1 ve MODP1024 sunan bir ağ geçidi daha güçlü algoritmalar için yapılandırılmış bir istemciyi reddeder ve günlüğü reddedilen dönüşümü adlandırır. Hizmeti yeniden başlatmak yerine günlüğü okursanız günlük uyuşmazlığı adlandırır. Bir forum başlığından algoritma dizesi kopyalamak yerine ağ geçidine hangi dönüşümler üzerinde gerçekten pazarlık edeceğini sorun: adresine yöneltilen ike-scan pazarlık edeceği dönüşümleri döndürür. Teklif, ilkenizin artık izin vermediği bir şifreleme ise düzeltme istemciyi düşürmekte değil, ağ geçidindedir.

Windows'ta anahtar ve kimlik doğrulama yöntemi VPN profilinde yaşar ve uyuşmazlık kimlik bilgisi isteminden sonra değil önce ortaya çıkar. Alıcı bir Windows Server ise uzak erişim rolünün kurulu olduğunu, sertifikanın istemcilerin bağlandığı adla eşleştiğini ve hiçbir bağlantı noktası filtresinin yukarıdaki protokollerden dar olmadığını doğrulayın.

Üçüncü aşama: tünel var ve PPP hiç başlamıyor

IKE tamamlandığında ve istem yine de hiç görünmediğinde güvenlik duvarına değil tünel artalan sürecine bakın. L2TP'nin UDP 1701'de dinleyen bir şeye ihtiyacı vardır — Linux'ta xl2tpd veya kl2tpd, Windows'ta uzak erişim hizmeti — ve kurulu ama durdurulmuş bir hizmet istemci tarafından tam olarak düşürülmüş bir paket gibi görünür. Zaten doğruladığınız kuralları yeniden açmadan önce dinleyiciyi denetleyin. Ardından PPP pazarlık etmelidir ve ilk LCP alışverişi sessiz bir başarısızlığın genellikle indiği yerdir.

Bu aşamadaki bir tuzak hiç de ağ hatası değildir: Windows belirli bir VPN türünden aynı anda yalnızca bir bağlantıya izin verir, bu yüzden ikinci deneme 937 hatasını döndürür, «bu türden başka bir bağlantı kullanımda». Bu yerel bir kuraldır ve etrafından dolanmanın yolu başka bir aygıt, başka bir tünel türü veya zaten var olan tek bağlantıyı paylaşmaktır.

Tahmin etmek yerine günlüğü aşama sırasına göre okuyun

İstemciyi durdurun, yeniden başlatın ve bileşenleri günlüğü yazdıkları sırayla okuyun. Yani önce IPsec artalan süreci — strongSwan veya Libreswan, ve ipsec --version hangisi olduğunu söyler — sonra L2TP artalan süreci, sonra pppd. Hangi bileşen hatadan önce en son yazdıysa incelenecek aşamayı işaretler, çünkü dizide ondan sonra gelen hiçbir şey çalışmadı.

Kayıtlı bir oturum yerine taze bir bağlantıyla doğrulayın, çünkü önbellekten yeniden bağlanan bir istemci alışverişin bazı bölümlerini atlayabilir ve eski bir sonucu yeniden üretebilir. Erişilebilirliği, anahtar değişimini, tüneli ve PPP'yi tek tek, bu sırayla doğrulayın. O zaman eksik istem bir gizem olmaktan çıkar ve gerçekten üzerinde çalışabileceğiniz bir listenin ikinci satırı olur. Bu liste aynı zamanda ağ ekibine verdiğiniz şeydir; aksi hâlde onlardan başlatılmamış bir artalan sürecinde yaşayan bir hata için güvenlik duvarını denetlemeleri istenirdi.