PPTP 800 ve 812 hataları ile bir dakika sonra kopan bağlantılar

Hata 800, hata 812 ve bir dakika sonra ölen PPTP tüneli üç ayrı arızadır. Her belirtiyi gerçekte başarısız olan katmanla eşleştirin.

Tek bir PPTP istemcisinden gelen üç hata iletisi genellikle üç farklı arızayı anlatır. Hata 800 tünelin hiç kurulmadığı, hata 812 sunucunun kimlik doğrulama yöntemini reddettiği anlamına gelir ve bir dakika sonra kopma, sağlıklı bir eşin gittiğine karar veren bir keepalive zamanlayıcısıdır. Her aşama kendi nedeniyle başarısız olur, bu yüzden her biri kendi denetimini gerektirir.

Hata 800 tünelin hiç kurulmadığı anlamına gelir

Windows, tüneli hiç kuramadığında hata 800 verir ve ulaşılamayan sunucu ya da uygun olmayan güvenlik parametreleriyle ilgili metin teşhis değil özettir. PPTP'nin herhangi bir kimlik bilgisi incelenmeden önce ağdan iki ayrı şeye ihtiyacı vardır. TCP 1723 denetim kanalını taşır, IP protokolü 47, yani GRE de kapsüllenmiş yükü taşır.

Bu dış yolu kendi LAN'ınızın dışından test edin, çünkü ofis içinde çalışan bir bağlantı kenar hakkında hiçbir şey kanıtlamaz:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

1723 yanıt veriyor ve istemci bağlanmaya çalışırken yakalama boş kalıyorsa yol 47 protokolünü düşürüyor demektir. 1723'ü yönlendiren ama PPTP geçişi kapalı olan bir yönlendirici tam olarak bu deseni üretir: TCP el sıkışması tamamlanır, ardından GRE paketleri kaybolur, böylece arıza hiç oturum açma denenmemiş olmasına rağmen kimlik bilgisi sorunu gibi görünür.

Yönlendirmeyi sunucunun güncel LAN adresine çevirin, PPTP geçişini yönlendiricinin sunduğu yerde açın ve aynı dış noktadan yeniden deneyin. GRE yukarı akışta filtreleniyorsa ve bunu değiştiremiyorsanız, TCP 443 üzerinden SSTP veya UDP 500 ve 4500 üzerinden L2TP/IPsec, Windows tarafında yapabileceğiniz herhangi bir değişiklikten daha iyi şansa sahiptir.

Hata 812, sunucunun kimlik doğrulama yönteminizi reddetmesidir

Hata 812 tünel ayağa kalktıktan sonra geri döner, bu yüzden parola sorunu gibi hissettirir. Sunucu bağlantı için görüşülen kimlik doğrulama yöntemini reddeder, illa parolanın kendisini değil. İstemcide VPN girdisini açın, güvenlik sekmesine gidin, türü Point-to-Point Tunneling Protocol olarak ayarlayın, açık protokol listesini seçin ve Microsoft CHAP sürüm 2'yi işaretleyin.

Geçerli ayarı iletişim kutusunda tıklamadan okuyabilirsiniz:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 isteyen bir sunucu, PAP'ta veya daha zayıf bir şeyi görüşen otomatik türde bırakılmış istemciyi reddeder ve hata herhangi bir kullanıcı parolası değerlendirilmeden önce gelir. Hesap biçimi aynı reddin diğer yarısıdır. Bir vakada Windows MicrosoftAccount\[email protected] biçiminde bir Microsoft hesap kimliği gönderdi, oysa sunucu yerel veya etki alanı hesabı istiyordu. SERVERNAME\username yazmak Windows'a hangi hesap deposuna başvurulacağını söyledi ve hatayı kaldırdı. Adı elle girin, kayıtlı bir kimlik bilgisinin önceki biçimi tekrarlamasına izin vermeyin.

Bir dakika sonra kopmalar bir keepalive kararıdır

Tünel bağlandığında biraz trafik geçirip sonra bağlantıyı kopardığında, istemciye dokunmadan önce sunucunun LCP yankı davranışına bakın. Daemon eşten düzenli olarak hâlâ orada olduğunu onaylamasını ister. Yapılandırılmış bütçe içinde çok az yanıt gelirse, kullanıcının hâlâ çalışan bir bağlantısı olmasına rağmen oturum düşürülür.

Linux pptpd sunucusunda bu değerler /etc/ppp/options.pptpd içinde yaşar ve olağan onarım aralığı kısaltmak değil bütçeyi genişletmektir:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Beş saniyelik aralıkta otuz kaçırma kısa bir duraklamayı bağışlar, eşi gitmiş ilan etmek yerine. Sayıyı bire veya ikiye indirmek, çevrilmiş bir yoldaki olağan titremeyi yaklaşık her dakikada bir kopmaya çevirir. Sunucunuz pptpd yerine Windows RRAS ise, bunun yerine PPP oturum zaman aşımına ve boşta kalınca bağlantı kesme ilkesine bakın. Onlar başka bir yerde yaşar ve var olmayan bir pppd dosyasını düzenlemek hiçbir şeyi değiştirmez.

Çakışan alt ağlar veri yolunu kırar

PPTP tüneli temiz kimlik doğrulaması yapıp yine de hiçbir yere ulaşamayabilir; iki taraf da aynı özel aralığı kullandığında, örneğin ofiste ve evde 192.168.1.0/24. İstemci belirli bir adresin hangi ana bilgisayara işaret ettiğini söyleyemez ve bazı yığınlar birini seçmek yerine rotayı hiç kurmamayı reddeder.

Bunu bir tasarım hatası olarak görün ve bir tarafı yeniden numaralandırın ya da istemciye bilerek çevrilmiş bir erişim aralığı verin. PPTP istemcisinde hata ayıklamak iki kez var olan adres uzayını düzeltemez ve belirti rastgele kopma gibi görünmeye devam eder.

Başarısız olan aşamayla başlayın: 800 için GRE, 812 için yöntem ve hesap dizesi, programa göre ölen tünel için yankı ayarları.

İlgili makaleler