NAT VPN sunucusunda mı yoksa yönlendiricide mi? İkisi de çalışabilir

Bir bağlantıyı dizüstü bilgisayarda varsayılan rota olarak işaretlemek herkesin hatırladığı adımdır ve ağ geçidinde hiçbir şeyi değiştirmeyen de odur. İstemci artık internet isteklerini tünelin içine gönderiyor; bu isteklerin binadan çıkıp çıkmayacağı yönlendirmeye, bir çeviri noktasına ve istemcinin özel adresine ulaşan bir dönüş yoluna bağlıdır. İki düzen üçünü de sağlayabilir, işi farklı yerlere koyarlar ve yanıt yönünün sahibi olmadığında ikisi de aynı sessiz biçimde başarısız olur. Aralarında seçim yapmak, istemci havuzunu kimin görmesi gerektiği sorusudur.

Mit: istemci rotası çıkışı oluşturur

Zorunlu tünelleme istemci tarafında bir politikedir: trafiğin fiziksel bağdaştırıcı yerine VPN bağdaştırıcısına gideceğine karar verir. Microsoft'un VPN yönlendirme belgeleri bu ayrımı ve zorunlu davranışı açıklar ve bu, istemcinin rota tablosu hakkında bir ifadedir, sunucunun yönlendirme kuralları hakkında değil. İstemci açısından tünel internetin yaşadığı yerdir; ağ geçidi açısından bir paket yukarıda hiç kimsenin duymadığı bir adresten geldi. Hiçbir taraf tek başına yanlış yapılandırılmamıştır ve bu yüzden arıza dizüstünün başındaki kişiye bozuk bir sunucu gibi görünür.

Bu uyumsuzluk, makalenin geri kalanının çözdüğü sorunun tamamıdır. Bir şeyin istemcinin özel adresini geri döndürülebilir yapması gerekir ve seçim nerede olduğudur.

Önce dönüş yolunu çizin

Herhangi bir ayara dokunmadan önce yolu gerçek adreslerle yazın ve üzerinde iki olası çeviri noktasını işaretleyin. Bu laboratuvar, 10.70.0.37 adresinde bir istemci, sunucunun 172.16.40.10 LAN adresi, 172.16.40.1 adresinde bir yönlendirici ve 203.0.113.40 adresinde genel bir çıkışla 10.70.0.0/24 VPN havuzunu kullanır.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Zaten internette gezinin sunucu yalnızca kendi yolunu kanıtlar. Bir istemci adına iletilen paket farklı bir karardır, aynı makinedeki iletme politikası tarafından verilir ve genellikle eksik olan da budur. Şemadaki üç karar noktasını işaretlemek konuşmayı her seferinde bunlardan biri üzerinde tutar.

Seçenek A: VPN sunucusunda çeviri

Burada sunucu, paketi yönlendiriciye vermeden önce istemcinin kaynağını kendi LAN adresine çevirir ve yönlendirici çıkışta olağan çevirisini uygular. Yanıtta yönlendiricinin eşlemesi sunucu adresini, sunucunun eşlemesi istemci adresini geri getirir. Seri olarak iki durumlu çeviri normal ve uygulanabilirdir, yeter ki ikisi de kaydedilsin; yönlendiricinin havuza giden bir rotaya hiç ihtiyacı olmaz ve bu düzenin çekiciliği budur.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT olduğunu varsaymak yerine sunucunun zaten neye sahip olduğunu görmek için bu okumaları kullanın. Bir blogdan kopyalanan Linux masquerade kuralı bir Windows yapılandırması değildir ve VPN dinleyicisi için ana makine güvenlik duvarındaki izin, bir istemcinin isteğini ileri iletme izniyle aynı politika değildir. Sunucunun iletme rolünü kendi yönetim yüzeyinden doğrulayın, ardından çeviriye ayrı ayrı bakın, çünkü ikisi genellikle bir dağıtımın farklı bölümleri tarafından etkinleştirilir.

Seçenek B: havuzu yönlendiriciye taşımak

İkinci düzenlemede sunucu istemcinin gerçek kaynak adresini iletir ve yönlendirici bunu çevirir. Bu, istemci havuzunu kenarda görünür tutar; trafik politikası, günlükleme veya denetim yönlendiricide yaşıyorsa bu yardımcı olur. Ayrıca yönlendiricinin 10.70.0.0/24 için 172.16.40.10 adresine işaret eden bir dönüş rotasına ve gerçekten o öneki içeren bir internet politikasına ihtiyacı olduğu anlamına gelir; LAN alt ağı için yazılmış bir kural sessizce havuza yayılmaz.

Bunu, kenar cihazı amaçlanan politika sahibiyse ve yönlendirme ile çeviri tablolarında başka bir öneki kabul edebiliyorsa seçin. Havuzun yukarıda görünmez kalması gerektiğinde ve yönlendirici aynı ekip tarafından yönetilmediğinde sunucu tarafındaki çeviriyi seçin. Hiçbir seçenek istemcideki herhangi bir onay kutusu tarafından ima edilmez ve hiçbiri genel olarak daha güvenli değildir; görünürlüğü ve bakımı farklı yerlere koyarlar.

DNS, IPv6 ve kabulü açık hale getirin

Adres çevirisi ad çözümlemesini düzeltmez. İstemci VPN profiliyle birlikte verilen bir çözümleyici, belirli ad alanları için özel bir çözümleyici veya onaylanmış bir genel çözümleyici kullanabilir ve o politika altında erişilemeyen bir çözümleyici yönlendirme çalıştıktan sonra da başarısız olmaya devam eder. Bir adı ve bir adresi ayrı ayrı test edin ki iki arıza asla tek bir raporda birleşmesin.

IPv6 tasarımda kendi paragrafına ihtiyaç duyar. Çalışan bir IPv4 çevirisi, IPv6 istemcilerinin rotası, geçerli bir genel kaynağı veya tünel düştüğünde onları engelleyen bir politikası olup olmadığı hakkında hiçbir şey söylemez. Bunu söylenmemiş bırakmak, istemcilerin yarısının ağ geçidini sessizce atladığı, diğer yarısının ise çalıştığı anlamına gelir.

Kabul için izin verilen bir istemci isteğini ve yanıtını iki sınır boyunca izleyin ve o anda her sınırın hangi adresi görmesi gerektiğini yazın. O kayıt, bir sonraki havuz değişikliğini eksik dönüş rotasının sahibinin kim olduğu tartışması yerine beş dakikalık bir düzenlemeye dönüştüren şeydir. Kaydı bir bilete değil, istemci profilinin yanında tutun, çünkü bir sonraki mühendisin ilk bulacağı şey profildir.