NAT arkasında SoftEther: doğrudan geçiş mi VPN Azure aktarımı mı?

SoftEther sunucunuz değiştiremediğiniz sağlayıcı yönlendiricisinin arkasında ve istemciler yine de bağlanıyor, bu yüzden bir aktarımın her şeyi taşıdığını varsayıyorsunuz. Bunun doğru olup olmadığı işi hangi mekanizmanın yaptığına bağlı: bir DNS adı, eşgüdümlü bir UDP yolu veya aktarıma giden bir dış tünel. Üçü de bağlı bir istemci üretebilir ve farklı koşullarda başarısız olurlar. Kullanıcılara veya merkezlere dokunmadan önce hangi yolu satın aldığınıza karar verin.

Üç mekanizma, üç farklı vaat

Dinamik DNS adlandırmadır. Ana makine adını değişen bir adrese yöneltilmiş tutar, böylece insanlar numaranın peşinden koşmayı bırakır ve başka bir şey yapmaz. Yerel NAT geçişi eşgüdümdür: iki SoftEther uç noktası bilgi alışverişinde bulunur ve aralarındaki çeviri cihazları üzerinden kullanılabilir bir UDP yolu açmaya çalışır. VPN Azure bir aktarımdır: sunucu hizmete dışarı doğru bağlanır ve istemciler aktarımın altyapısındaki bir ana makine adı üzerinden gelir.

Üçü tek bir özelliğin sürümleri değil, birbirini tamamlar. Bir kurulum adlandırmayı kullanırken bağlantısı gerçekte geçişe veya aktarıma bağlı olabilir.

İstemciye ve ağa göre karar verin

Seçim istemciyle başlar, çünkü geçiş yalnızca yerel SoftEther bağlantı mekanizmasında bulunur. Aynı sunucudaki OpenVPN, L2TP/IPsec ve SSTP dinleyicileri onu devralmaz, aynı ana makineyi paylaşsalar bile. Kullanıcının ne çalıştıracağına ve ardından ağın neye izin verdiğine bakın. Yalnızca TCP 443'e izin veren bir kurumsal ağ sizi o bağlantı noktasındaki bir aktarıma iter, geçişin ihtiyaç duyduğu UDP bağlantı noktalarını geçiren bir ağ ise doğrudan yolu deneyebilir; her ikisini de gerçek çıkış politikasına karşı doğrulayın.

Elle erişilebilen bir dinleyici, bir yönetici yayımlayabildiğinde hâlâ meşru bir tasarımdır, ancak kendi adreslemesi ve güvenlik duvarı işi olan ayrı bir projedir.

Oturumun hangi taşımayı seçtiğini doğrulayın

Bağlantı durumu, kullanılan yol için tek dürüst kaynaktır. Sunucuda okuyun ve istemcinin aldığı ana makine adını çözün.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList hangi oturumların bağlı olduğunu gösterir ve bunlardan biri üzerindeki SessionGet bağlantı türünü bildirir; oturumun aktarım üzerinden gelip gelmediği de dahil. Aktarım altyapısına çözülen bir kayıt, oturumun üçüncü bir taraftan geçtiğini söyler; bunu bir testte o rotayı engelleyerek doğrulayabilirsiniz. Yerel bir istemcide UDP hızlandırma veri yolunu kontrol yolundan uzaklaştırabilir, bu yüzden tek bir gözlem tüm oturumu tanımlamaz. Adres değişikliğinden sonra eskiyen dinamik DNS adı ve arka uç yolu yokken yanıt veren bir aktarım, ayrı ayrı test edilmeye değer iki arıza modudur. Tasarımın amaçladığını değil, ölçtüğünüzü yazın.

Seçilen yolun neye bağlı olduğunu planlayın

Her yol bir bağımlılık taşır. Doğrudan geçiş bir ağ geçişinden veya yeni bir çeviri cihazından sonra değişebilir, aktarım oturumu ise hizmet veya erişilebilir bağlantı noktası başarısız olduğunda başarısız olur. Başka bir ağdan yeniden bağlanın ve istemcinin doğruladığı sunucu kimliğini onaylayın, önceki çalışan yolu aynı testte tutun. Ardından VPN arkasındaki özel kaynağı test edin, çünkü yetkilendirme, merkez üyeliği, adres ataması ve dönüş rotaları her durumda sizin sorumluluğunuzda kalır.

Ana makine adını, protokolü, özellik ayarlarını ve gözlenen taşımayı yazın. Tam olarak o dört bölümlü kayıt, bir sonraki kişinin çalışan bir bağlantıyı yeniden üretmesini sağlar.