Neden daha fazla kurum NAT saç tokalarına izin vermek için içten içe NAT veya benzeri çözümler kullanmıyor?

İçeriden içeriye NAT aka NAT geridöngü, ASA'nın harici arabirimindeki bir web sunucusuna veya dahili arabirimdeki bilgisayarlardan benzer bir cihaza erişirken, saç tokası NAT sorunlarını çözer. Bu, DNS yöneticilerinin, ortak adreslere NAT'lenen sunucuları için karşılık gelen RFC1918 adreslerine sahip yinelenen bir iç DNS bölgesini sürdürmesini önler. Ben bir ağ mühendisi değilim, bu yüzden bir şeyleri özlüyorum, ama bu, yapılandırmak ve uygulamak için hiç akıllıca gibi görünüyor. Asimetrik yönlendirme bir sorun olabilir, ancak kolayca hafifletilebilir.

Tecrübelerime göre, ağ yöneticileri / mühendisleri, sistem halklarının, güvenlik duvarlarını NAT saç tokalarını doğru şekilde kullanacak şekilde yapılandırmak yerine, yalnızca split-dns çalıştırmasını tercih ediyor. Bu neden?

Bunu yapmamamın birkaç nedeni var:

• Gerekmediğinde neden DMZ yönlendiricilerini ve güvenlik duvarını zorlamalısınız? Dahili hizmetlerimizin çoğu DMZ'de değil, genel kurumsal alandadır ve zaman zaman uzaktan erişim için DMZ'de proxy hizmetleri vardır. İçeriden içeriye nat yapmak, bizim için önemli olan DMZ'ye daha fazla yük ekler.
• DNAT + SNAT yapmazsanız, haklı olarak zor olan asimetrik yönlendirme elde edersiniz. Böylece SNAT ve kaynak IP bilgilerini kaybedersiniz. Bununla birlikte, sorun giderme amacıyla kaynak IP'leri insanlara bağlamak çok yararlıdır. Ya da bazen aptallık durumlarında sinir bozucu amaçlar. “Hey, bu IP kimliği doğrulanmamış bir servis X’de riskli bir şey yapıyor” “Ah, imap sunucuya kim olduğunu kaydedelim”.

Açıkçası, bunun kesin bir cevabı olamaz , ancak bunun birkaç nedeni olabilir:

1. Elegance: NAT, başlamak için çok zarif değil, IPv4'ün sınırlı adres alanına sahip olması gerekliliğidir. NAT'tan kaçınabilirsem, yapacağım. IPv6 ile sorun herhangi bir oranda ortadan kalkıyor.
2. Karmaşıklık: özellikle tüm güvenlik sınırlarınızı yaratan tek bir "çekirdek" yönlendiricinizin olmadığı durumlarda, filtre yapılandırmaları oldukça zor olabilir. Ya öyle ya da NAT kurallarını yönlendirici cihazlarınızın neredeyse tümüne yaymanız ve sürdürmeniz gerekir.
3. Referans: Güvenlik duvarı yöneticileri, sunucu yönetici ekibinin geri kalanından farklı milletlerde olsalar, ulaşılması zor olabilir. Değişikliklerin güvenlik duvarı yöneticisinin birikintisi (veya tatilleri) tarafından ertelenmemesini sağlamak için, sorumluluğu aynı ekipte tutma seçeneği seçilmiştir.
4. Taşınabilirlik ve yaygın uygulama: DNS görüşlerini kullanmak, bu sorunu çözmek için "herkesin bildiği tek şeydir". Her sınır yönlendirici, geridönüş NAT'ı basit bir şekilde desteklemeyebilir, daha az insanın kendi ortamınıza doğru şekilde nasıl kurulacağını bilmesi olasıdır. Ağ sorunlarını giderirken, ekibin, saç tokası NAT konfigürasyonundan ve tüm sonuçlarından haberdar olması gerekir - bunlar görünüşte alakasız bir problemi kovalarken bile

Yasal Uyarı - Bu bir flamebait cevaptır.

Bunun gibi çözümlerden kaçınılmasının bence ortak bir nedeni , ağ mühendisleri adına NAT'ın mantıksız bir korku / nefretidir . Bununla ilgili bazı tartışma örnekleri görmek istiyorsanız, şunlara göz atın:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Tom'un blogu oldukça ateşli NAT / IPv6 tartışmalarını çekmeye devam ediyor)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (blogum)

Söyleyebileceğim kadarıyla, bu korkunun çoğu Cisco'nun zayıf NAT uygulamalarından kaynaklanıyor (bu anlamda mantıksız olmayabilir), ama aklıma "klasik" ağ mühendisi "NAT" da çok iyi okuyor. Kötü "dünya görüşü, mükemmel mantıklı olduğu ve aslında çözümü basitleştirdiği durumlarda bunun gibi bariz örnekler göremiyor.

İşte buradasın - kalbinin içeriğine oy ver! :-)

Benim tahminim:

1. Bölünmüş DNS daha kolay anlaşılır.
2. NAT Firkete yönlendiricideki kaynakları kullanır, split-dns kullanmaz.
3. Yönlendiriciler, split-dns kurulumundan alamadığınız bant genişliği sınırlamalarına sahip olabilir.
4. Bir yönlendirme / NAT adımlarından kaçınırken Split-dns her zaman daha iyi performans gösterir.

Firkete NAT için artı kısımda,

• Kurulduktan sonra sadece çalışır.
• Dizüstü bilgisayarlar için DNS önbellekleriyle ilgili sorun yok, iş ağı ve genel internet arasında taşındı.
• Bir sunucunun DNS'si yalnızca tek bir yerde yönetilir.

Trafik yoğunluğu az olan küçük bir ağ için dahili bir sunucuya firkete NAT ile giderim. Sunucuya birçok bağlantısı olan ve bant genişliği ve gecikmenin önemli olduğu daha büyük bir ağ için split-dns ile gidin.

Benim bakış açıma göre, bu Cisco Pix'ten ASA'ya geçiş arasında biraz değişti. aliasKomutu kaybettim . Genel olarak, dış adrese bir Cisco güvenlik duvarı içerisindeki arayüzden erişmek bir çeşit kandırmaca gerektirir. Bkz: Harici IP üzerinden dahili sunucuma nasıl ulaşırım?

Yine de her zaman yinelenen bir iç DNS bölgesi sürdürmemize gerek yoktur. Cisco ASA, NAT ifadesinde yapılandırılmışsa harici adresler için DNS sorgularını iç adreslere yönlendirebilir. Ancak, bu ayrıntı derecesine sahip olmak ve güvenlik duvarına adım atmak yerine bunu tek bir yerde yönetebilmek için ortak DNS bölgesi için bir iç bölge tutmayı tercih ediyorum.

Genellikle, bunu bir ortamda (posta, web, birkaç kamu hizmetleri) gerektirebilecek sadece birkaç sunucu vardır, bu yüzden çok büyük bir problem olmamıştır.

Birkaç neden düşünebilirim:

1. Pek çok kuruluş, zaten tüm iç DNS bilgilerini dünyaya yayınlamak istemediklerinin bir sonucu olarak zaten DNS'i böldü, bu nedenle halka açık bir IP üzerinden maruz kalan birkaç sunucuyu idare etmek için fazladan bir çaba harcanmıyor.
2. Bir kuruluş ve ağı büyüdükçe, iç insanlara hizmet veren sistemleri dışarıdan hizmet veren sunuculardan ayırırlar; bu nedenle, iç kullanım için dış olanlara yönlendirme çok daha uzun bir ağ yolu olabilir.
3. Aracı cihazların paketlerinde ne kadar az değişiklik olursa, gecikme, yanıt süresi, cihaz yükleme ve sorun giderme söz konusu olduğunda o kadar iyidir.
4. (çok küçük, kuşkusuz) NATing cihazı paketin başlıklarının dışına çıkmazsa ve içindeki verileri yeni IP adresleriyle değiştirirse NAT'ın hala kıracağı protokoller vardır. Sadece bir kurumsal hafıza durumu olsa bile, özellikle de% 100 emin olmadıkları bir protokolle uğraşıyorlarsa, insanların bundan kaçınmaları için geçerli bir nedendir.

NAT geridöngü kullanacak olsaydım, NAT aygıtının sahte kaynak adreslerini nasıl işleyeceği konusunda biraz endişeliydim. Paketin hangi arabirime girdiğini kontrol etmezse, dahili adresleri WAN'dan taklit edebilir ve paketleri dahili adreslerle sunucuya gönderebilirim. Yanıt alamadım, ancak dahili bir adres kullanarak sunucuyu tehlikeye atabilirim.

NAT loopback'i kurar, DMZ anahtarını takar ve sahte dahili kaynak adresleriyle paketleri gönderirdim. Aldıklarını görmek için sunucu günlüğüne bakın. Sonra kafeye gidip ISS'imin sahte adresleri engelleyip engellemediğini göreceğim. NAT yönlendiricimin kaynak arayüzünü kontrol etmediğini tespit edersem, ISS'm kontrol etse bile büyük olasılıkla NAT geridöngü kullanmazdım.