SoftEther SecureNAT: DHCP ve NAT iki ayrı karardır

SecureNAT iki hizmeti açan tek bir onay kutusudur ve bu konudaki karışıklığın çoğu buradan gelir. Sanal bir DHCP sunucusu istemciye adres, maske, ağ geçidi ve çoğu zaman bir çözümleyici verir. Sanal bir NAT, paketleri o ağ geçidinin ötesine sunucu ana makinesinin kendi ağ yığınını kullanarak iletir. İkisi yapılandırmada yan yana durur ve birbirinden bağımsız olarak başarısız olur: istemcinin kusursuz bir kiralaması olup çalışan yolu olmayabilir ya da çalışan bir yolu olup ayarları yanlış çözümleyiciyi gösterebilir. Bunları iki karar olarak doğrulayın, tanı kısalır.

Tek onay kutusunun arkasında iki hizmet

Sanal DHCP tarafı bir yapılandırma sorusuna yanıt verir: bu istemci bu sanal hub içinde hangi ayarları alır. Sanal NAT tarafı bir iletme sorusuna yanıt verir: istemci hub dışındaki bir adrese paket gönderdiğinde sunucu bunu çevirip iletir mi. Birincisi hub'a özgüdür ve yukarı akış ağı gerektirmez. İkincisi tamamen ana makineye bağlıdır.

Sanal ana makine arayüzü ilk karara aittir, ikincisine değil. Adresi, genellikle varsayılan olarak 192.168.30.1 gibi bir şeydir ve DHCP hizmetinin sunduğu ağ geçididir. Bu, sunucunun genel dinleme adresi değildir ve ikisini karıştırmak o ağda bulunmayan bir makineye yönelen güvenlik duvarı kuralları ve istemci ayarları üretir.

Karar 1: adresi kim sağlar

Sanal DHCP açıksa istemciler yapılandırdığınız havuzdan kiralama almalı, ağ geçidi sanal ana makine arayüzü ve çözümleyici verdiğiniz olmalıdır. İstemcinin durum metnini değil kiralamayı inceleyin, çünkü «bağlandı» tüneli anlatır, adres atamasını değil:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Başka bir şeyde hata ayıklamadan önce bilinmesi gereken iki arıza biçimi var. Önceki tasarımdan kalan statik adresi olan bir istemci onu korur ve kiralamayı yok sayar; bu, DHCP'nin yanıt vermeyi reddetmesi gibi görünür. Köprülenmiş bir segmentteki ikinci DHCP kaynağı da aynı istemciler için yarışır; bu, kesintili adresler ve sorunu yeniden üretemeyen bir destek kuyruğu üretir.

Çakışan havuzlar da buraya girer. Sanal DHCP havuzu ana makinenin LAN alt ağını veya başka bir hub'ın havuzunu çakışırsa istemci belirsiz biçimde yönlendirilen bir adres alır ve sonraki her test sonuçsuz kalır.

Karar 2: sanal ağ geçidinin ötesine kim iletir

Sanal NAT açıkken hub'dan çıkan trafik sunucu tarafından çevrilir ve ana makinenin yönlendirme tablosundan gönderilir. Bu, iletme zincirinin şu olduğu anlamına gelir: istemciden sanal ağ geçidine, sanal NAT'tan ana makine yığınına, ana makine yığınından kendi varsayılan rotasına. Her halka diğerlerine dokunmadan başarısız olabilir ve arıza imzaları farklıdır.

İkinci kararı hub'dan çıkması gereken bir şeyle test edin, hub'a yerel bir şeyle değil. Sanal ağ geçidine ping atmak yalnızca ilk halkayı kanıtlar, fazlasını değil:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Ad çözümlemesi çalışıp genel bir adrese bağlantılar başarısız olursa iletme zincirindesiniz, DHCP'de değil. İkisi de başarısız olursa önce çözümleyiciyi kontrol edin, çünkü erişilemez bir iç adres olarak itilen çözümleyici çalışan bir yolu tamamen bozuk gösterir.

SecureNAT'ın iletmesini sunucu süreci gerçekleştirir, bir köprüyle kullanacağınız çekirdek iletme yolu değil. Bu kullanışlıdır ve köprülemeden yavaştır; ayrıca ana makinenin kendi güvenlik duvarı kuralları ve yönlendirme kararlarının çevrilen trafik için hâlâ geçerli olduğu anlamına gelir. Sanal NAT ana makinenin politikasını atlamaz; onu kullanır.

Ana makinenin kendi yolu üçüncü bir şeydir

Yukarıdakilerin tümü sunucu ana makinesinin hedefe ulaşabildiğini varsayar. Çalışan bir yukarı akış rotası olmayan, kısıtlayıcı bir çıkış politikası olan veya sahip olmadığı bir adres ailesi bulunan ana makine, hub yapılandırması ne kadar doğru olursa olsun ikinci kararda başarısız olur. Ana makineyi tek başına, tünelin dışında kontrol edin, arızayı SoftEther'e yüklemeden önce.

SecureNAT ayrıca sunucuya bağlı her ağa ulaşma yetkisi de değildir. Kendisine ulaşan trafiği çevirir ve iletir; ana makinenin neye ulaşabileceğine karar vermek hâlâ ana makinenin güvenlik duvarı ve yönlendirme işidir ve erişim vermek için tünele güvenen bir tasarım, fazla vermekten tek bir kötü kural uzaktadır.

Adres aileleri kendi kontrollerini hak eder. Çalışan bir IPv4 DHCP örneği, derlemenizde her IPv6 yeteneğinin bulunduğunu kanıtlamaz, bu yüzden çift yığın davranışı vaat etmeden önce gerçekten çalıştırdığınız sürümün kılavuzunu okuyun. Kılavuzun SecureNAT bölümü güncel sürüm için sanal NAT ve DHCP işlevlerini kapsar.

Her kararı kendi testiyle doğrulayın

İlk kararı kiralama kontrolüyle kabul edin: havuzda adres, sanal ana makine arayüzüne eşit ağ geçidi, yapılandırdığınız çözümleyici. İkincisini istemciden gelen bir çıkış isteği ve sunucudaki NAT tablosuna bir bakışla kabul edin, çünkü artan oturum sayısı çevirinin gerçekten gerçekleştiğinin, yalnızca açık olduğunun değil, tek doğrudan kanıtıdır.

Sonra ayrımı tasarım notuna yazın: hangi bileşen adresi sağlar, hangi bileşen iletir ve trafik hangi ana makine arayüzünden çıkar. Bir yeniden başlatma davranışı değiştirdiğinde, o not her şeyi yeniden başlatıp belirtinin kaymasını ummak yerine üçünden hangisini incelemeniz gerektiğini söyler.

Kayda bir karar daha girer, bugün vermeseniz bile: SecureNAT ve yerel bir köprü aynı hub için farklı tasarımlardır ve ikisine de ihtiyaç duyan bir hub farklı bir plana ihtiyaç duyan bir hub'dır. Bilinçli seçin, nedenini yazın, bir sonraki kişi bunu çalışan bir yapılandırmadan geriye doğru çözmek zorunda kalmaz.