PPTP geçişi yok: Windows VPN 807 hatasını düzeltme

TCP 1723'ü yönlendirmek çoğu zaman PPTP'nin yalnızca ilk kısmını temizler ve geri kalanını bozuk bırakır, bu yüzden Windows denemede hâlâ 807 hatası döndürür. Sıradaki dürtü 47 numaralı bağlantı noktası için kural eklemektir ve bir öğleden sonrayı harcayan adım tam da budur: GRE, IP başlığındaki bir protokol numarasıdır, yönlendirme tablosunun eşleştirebileceği bir bağlantı noktası değildir. Yönlendirici 47 numaralı protokole geçiş izni verip onu aynı çağrıya bağlamadıkça tünel başlayamaz. Aşağıdaki bölümler iki kanalı ayırır, sonra bunları tek tek sınar.

Bağlantı noktası tablosunda protokol numarası için satır yoktur

PPTP farklı şekillerde başarısız olan iki konuşma kullanır. TCP 1723 üzerindeki çağrıyı başlatır, bağlantı bilgisini aktarır ve kullanıcı bağlantıyı kestiğinde onu yıkar. Yük tarafı, IP başlığının 47 numaralı protokolle etiketlediği GRE içinde çalışır ve o tünelin içinde PPP bağlantıyı görüşürken MS-CHAPv2 kimlik bilgilerini denetler.

GRE taşıma başlığı taşımadığı için hiçbir bağlantı noktası açığa çıkarmaz, dolayısıyla bağlantı noktaları için yazılmış bir kuralın eşleşecek hiçbir şeyi yoktur. 1723'ü yönlendiren bir yönlendirici o TCP oturumu için bir eşleme oluşturur ve orada durur. İkinci yarıyı işleyen bellenim bu özelliği PPTP geçişi ya da PPTP ALG diye adlandırır, bazı bellenimler ikisini de sunmaz ve boşluktan hiç söz etmez. Onay kutusundaki etiket, 47 numaralı protokolün hiç tanınıp tanınmadığından daha az önemlidir.

Veri yolu öldüğünde Windows ne bildirir

807 hatası bağlantının tamamlanamadığını söyler, bu da pratikte çağrının sunucuya ulaştığı ama veri kanalının açılmadığı anlamına gelir. Bu, hesap hakkında değil taşıma hakkında bir hükümdür. 691 hatası kimlik bilgilerine ya da kimlik doğrulama protokolü uyuşmazlığına işaret eden hatadır, bu yüzden sizi bambaşka bir yere gönderir.

Parolaya dokunmadan önce taşıma üzerinde çalışın. 807'nin peşinden koşup kimlik bilgilerini değiştirmek gerçek arızayı yerinde bırakır ve sonraki denemeyi okumayı zorlaştırır.

İkinci bir istemci çalışan bir tüneli neden bozar

Onları ayıracak bağlantı noktaları olmadığından, bir NAT cihazı iki PPTP istemcisini iki HTTPS oturumunu ayırdığı gibi ayıramaz. Bu yüzden birçok tüketici cihazı tek bir PPTP çağrısına izin verir ve onu kaynak adrese göre izler. Tek başına çalışan bir dizüstü bilgisayar, ikinci bir makine aradığında tamamlamayı bırakır ve istemci tarafından bakıldığında arıza rastgele görünür. Bu örüntü bellenime aittir ve hiçbir profil değişikliği onu değiştirmez.

İki istemci de ararken bağlantı tablosunu izleyin. Eşlemeyi her zaman yalnızca ilk ana bilgisayar tutuyorsa, yönlendirici desteklediğinin sınırına gelmiştir ve istemci tarafındaki hiçbir ayar bunu değiştiremez.

Hangi yarının başarısız olduğunu kanıtlayın

Yönlendiricide herhangi bir şeyi değiştirmeden önce TCP 1723'ün geldiğini doğrulayın, çünkü bu yanıt hangi yarıyı sınadığınıza karar verir. Bunları Windows istemcisinden kendi sunucu adınıza karşı çalıştırın. Birincisi bağlantı noktasının yanıt verip vermediğini yazdırır, ikincisi iletişim kutusu olmadan arar, bu da yinelenen denemeleri karşılaştırılabilir kılar.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Bağlantı noktası testinde doğru sonuç, denetim kanalının açık olduğu ve kalan şüphelinin GRE olduğu anlamına gelir. Yanlış sonuç, yönlendirmenin, bir filtrenin ya da iletmenin bozuk olduğu anlamına gelir ve hiçbir GRE değişikliği bunu kurtarmaz. Veri tarafı görülebildiği yerde, sunucu ucunda ya da yönlendiricide izlenmelidir.

tcpdump -ni any proto 47

Wireshark'taki karşılığı ip proto 47 görüntüleme filtresidir, bunu kabukta rahat olmayan birine vermek daha kolaydır. Cevap olarak hiçbir şey çıkmadan GRE geliyorsa dönüş yolunun onarılması gerekir.

Hatayı gerçekte ne düzeltir

Yönlendiricinin ayarı açığa çıkardığı yerde PPTP geçişini etkinleştirin ya da kuralları kabul eden bellenimde 47 numaralı protokole açıkça izin verin. RouterOS'ta forward kuralı protokolle doğrudan eşleşir, bağlantı noktası tabanlı bir iletme bunu asla yapamazdı. Tüketici bellenimi aynı kararı genellikle bir onay kutusunun arkasına saklar, bazen bağlantı noktası yönlendirmesi yerine güvenlik ayarları altında. Böyle bir denetim yoksa istemci tarafında hiçbir şey bunu telafi etmez.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP'yi değiştirmek diğer seçenektir ve çoğu zaman daha ucuzudur. VPN'i kendisi sonlandıran bir yönlendirici gelen istemciler için çift NAT'tan kaçınır ve bağlantı noktası tabanlı NAT'ın zaten işlediği bir protokolün hiç geçişe ihtiyacı yoktur: UDP üzerinden OpenVPN, TCP 443 üzerinden SSTP ya da ESP'yi UDP 4500 içine saran NAT-T ile L2TP/IPsec. PPTP ayrıca MS-CHAPv2'ye bağlıdır ve belgelenmiş zayıflıkları, hata giderildikten sonra bile yeni bir kurulum için onu kötü bir seçim yapar.

Hangi kuralın fark yarattığını yazın, çünkü aynı saha ikinci kullanıcı erişim istediğinde aynı sınırla karşılaşacaktır. Protokol düzeyinde bir düzeltme, sonraki mühendisin bakacağı ağ notlarına aittir.