MikroTik PPTP düşüyor mu? Sunucuya giden yolu düzeltin

RouterOS'taki bir PPTP istemcisi bağlanır, biraz trafik taşır ve sonra sessizleşir; günlük ise kimlik bilgisi ya da sunucu sorunu gibi görünür. Genellikle ikisi de değildir. Tünel kendi taşıma paketlerini taşıyor, çünkü sunucuya giden yol tünelin kurduğu yolla da eşleşiyor. Karşı taraf yönlendiriciden haber almayı bırakır ve arayüz hâlâ çalışır durumda olduğunu iddia ederken oturum ölür.

Çözüm, sunucuyu fiziksel WAN üzerinden erişilebilir tutan tek bir yol ya da tek bir ayardır. Hangisi olduğu, yönlendiricinin tam tünelli bir ağ geçidi olup olmayacağına bağlıdır.

Belirti: bağlanır, trafik taşır, ölür

Desen her yeniden bağlanmada tekrarlanır ve bu ilk işe yarar ipucudur. Reddedilen parola arayüz açılmadan başarısız olur, yanlış güvenlik duvarı yapılandırması genellikle tek yönü engeller, yönlendirme döngüsü ise arayüzün kurulmasına izin verip sonra onu boğar. Sayaçlara bakın: tünel bir başlangıç paket patlaması gösterir ve sonra hiçbir şey göstermez, WAN arayüzü ise kapsüllenmiş kopyaları göndermeye devam eder. Bu, kendi çıktısını kendine geri besleyen bir yönlendiricidir.

PPTP bunu tetiklemeyi kolaylaştırır çünkü taşıma, sunucunun adresine giden düz IP'dir, uzak ucu başka bir alt ağda oturan bir tünel değildir. O adresi yönlendiren her şey taşımayı da birlikte yönlendirir.

Tünel kendi paketlerini neden yutar

İstemci bağlandığında, ağ geçidi tünel arayüzü olan bir yol kurar. Profil ayrıca varsayılan bir yol kurarsa, daha belirgin bir eşleşmesi olmayan her hedef, sunucunun genel adresi dahil, tünele çözülür. Yönlendirici paketi kapsüller, dış paketi sunucuya adresler ve yolu yeniden arar: aynı hedef, aynı varsayılan, aynı tünel. Sürüme bağlı olarak bu özyineleme düşürülür, kuyruğa alınır ya da karşı taraf pes edip oturumu kesene kadar döngüye girer.

Cihaz üreticileri tam da bunu önlemek için kendi sunucuları için genellikle otomatik olarak bir ana bilgisayar yolu ekler. RouterOS bunu varsaymaz, bu yüzden operatör istisnayı ifade etmek ya da varsayılan yoldan baştan kaçınmak zorundadır.

Sunucu adresini WAN'a sabitleyin

Mümkün olan en dar yolu ekleyin: sunucunun genel adresi için /32, sonraki atlama olarak ISS ağ geçidi, internete çıkan arayüzde. /32 ön ek uzunluğuyla her varsayılanı yener ve aynı ön ek için zaten başka bir yol varsa daha düşük mesafe kazanır. Sonra yeniden bağlanın ve yolun yalnızca listede bulunmadığını, etkin olduğunu doğrulayın.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

ISS ağ geçidi DHCP ile öğreniliyorsa, DHCP'nin kurduğu ağ geçidi adresini kullanın ya da sürüm destekliyorsa yolu arayüze bağlayın. Bir sonraki kiralamada değişen sabit kodlanmış bir ağ geçidi, gecikmeli bir arızadır. Adresi WAN yeniden bağlantısından sonra kontrol edin, çünkü eski bir ağ geçidi o zaman ortaya çıkar ve tünel yeniden düşmeye başlar.

Ya da tünelin varsayılanı almasını durdurun

Tek bir uzak LAN'a ihtiyaç duyan bir şube, PPTP profilini varsayılan yoldan tamamen uzak tutmalıdır. İstemci profilinde o seçeneği kapatın ve bunun yerine tünel arayüzü üzerinden uzak ön ek için belirli bir yol ekleyin. Sıradan trafik WAN'da kalır, tünelin kendi taşıması doğal yolunu korur ve yönlendirme tablosunu açıklamak kolaylaşır. Bu, tek bir alt ağa ihtiyaç duyan bir şube için daha iyi bir tasarımdır; sitenin çıkışı olması gereken bir yönlendirici için değil.

Tam tünelin kendi gereksinimleri vardır: seçili kaynaklar için ilke yönlendirmesi, dönüş trafiği için bir plan ve tünel düştüğünde ne olacağına dair bir karar. Bunların hiçbirini, yalnızca taşımayı canlı tutan ana bilgisayar yolu çözmez.

Katman katman doğrulayın, sonra yönetim deliğini kapatın

Katman katman test edin: bağlanmadan önce sunucunun genel adresine ping atın, bağlandıktan sonra uzak ağ geçidine ping atın, sonra uzak LAN'daki bir ana bilgisayara ping atın. Yönlendiricinin arkasındaki ana bilgisayarların yanıtları onun üzerinden geri alması gerekiyorsa tünel arayüzüne masquerade ekleyin.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Sonra yönlendiriciyi yeniden başlatın ya da bir WAN yeniden bağlantısını zorlayın ve üç pingi tekrarlayın, çünkü yalnızca çalışan yapılandırmada var olan bir yol hayatta kalmaz. Bunun kırıldığı diğer yer, yedek dosyaya aktarılıp sonra geri yüklenen yapılandırmadır; çünkü yol çalışma anında eklendiyse dışa aktarımda eksik olabilir.

Son olarak, herhangi bir VPN ya da yol değişikliği yayımlamadan önce Winbox ve web yönetimini bilinen kaynak adreslerle sınırlayın. Tünelleri sonlandıran bir yönlendirici bir yönetim hedefidir ve dünyaya açık port 80, yeni düzelttiğiniz yoldan daha büyük bir bulgudur.