Tek bir ortak IP adresi kullanarak NAT'ın arkasında birden fazla sunucuyu gösterme


17

Bu NAT ve DNS hakkında Kanonik Bir Soru

Şu anda bir ağ adresi çeviri (NAT) güvenlik duvarı ile internetten ayrılmış bir web sunucusu ve bir e-posta sunucusu içeren bir DMZ ile bir ağ kurmaya çalışıyorum.

NAT güvenlik duvarını aşağıdaki arabirimlerle yükledim:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

DMZ'mde iki ana bilgisayarım var:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Ben için DNS yapılandırmanız gerekir biliyorum example.comkararlılığı hem etki example.comve mail.example.combenim genel IP adresine.

NAT güvenlik duvarımın gelen tüm istekleri example.com192.168.124.30 adresindeki web sunucusuna ve tüm gelen istekleri mail.example.com192.168.124.32 adresindeki e-posta sunucusuna iletmesini istiyorum. NAT güvenlik duvarımın yapılandırmasında bir "bağlantı noktası yönlendirme" özelliği görüyorum, ancak aradığım şeyi gerçekleştiremiyorum.


3
Sorunuzu, belirli teknolojilere referansları kaldırmak için düzenledim. Soru hala aynı temel şeyi soruyor ama teknolojiden bağımsız bir şekilde. Aynı şekilde, cevabım asıl sorunuz için de geçerlidir, ancak farklı güvenlik duvarı ve servis barındırma durumlarına sahip diğer kişiler burada cevap aramaya gelirse de geçerlidir.
Evan Anderson

Yanıtlar:


18

Özellikle DNS / uygulama katmanı protokolleri arasındaki TCP / IP protokol yığını katmanları arasındaki bilgilerin nasıl aktığına dair düşünceleriniz karışıyor.

Bir tane genel IP adresiniz var. DNS kesinlikle hem çözebilirsiniz mail.example.comve example.comaynı genel IP adresine.

Genel olarak, güvenlik duvarınızın harici arabirimi tarafından alınacak genel IP adresinize yönelik istekleri içeren IP datagramları, uzak istemcinin erişmeye çalıştığı ana bilgisayarın adını içermez. Her iki ana makine adı da aynı IP adresine çözümlendiğinden, güvenlik duvarınız uzak istemcinin hangi ana bilgisayar adını çözdüğünü sihirli bir şekilde "bilemez". IP katmanı, uygulama katmanında kullanılan ana bilgisayar adının farkında değildir.

TCP ve UDP protokolleri, bir ana bilgisayar tarafından sunulan belirli hizmetleri bağlantı noktası numaralarını kullanarak farklılaştırır. Örneğinizde, gelen TCP bağlantı noktası gönderilirken web sunucusuna gelen TCP bağlantı noktasına 80 (HTTP) gelen istekleri göndermek için NAT güvenlik duvarınızın bağlantı noktası yönlendirme (bağlantı noktası adresi çevirisi veya PAT olarak da adlandırılır) özelliğini kullanmak mümkün olabilir 25 (SMTP) e-posta sunucunuza.

Ancak, aynı hizmeti her iki makinede de barındırmayı planlıyorsanız, bu strateji sorunlu hale gelir. Hem web sunucunuzda (Müşteri erişimi için) hem de e-posta sunucunuzda (web postası için) güvenli bir web sitesi barındıracağınızı varsayalım. NAT güvenlik duvarınızın genel IP adresine 443 numaralı TCP bağlantı noktasına (HTTPS) gelen istekler yalnızca bir sunucuya veya diğerine yönlendirilebilir.

Bu duruma yönelik genel çözüm, daha fazla genel IP adresine sahip olmaktır. Çünkü IPv4 adresleri kıt hale geliyor ve bu da sorunlu olabilir.

Sonunda , uygulama katmanındaki bazı protokollerde genel IP adreslerinin azlığı etrafında çalıştık . Örneğin, HTTP / 1.1 Host:özellikle bir web sunucusunun aynı genel IP adresinde birden çok web sitesi barındırmasına izin vermek için başlığı ekledi . TLS , uzak istemci tarafından girilen ana bilgisayar adına göre uygun sertifikanın seçilmesine izin vermek için Sunucu Adı Gösterimi (SNI) uzantısını ekler .

Uygulama katmanında bu tür bir geçici çözüm yapılması, her uygulama katmanı protokolünün kendi "düzeltmesine" (ve ardından tüm sunucu ve istemci yazılımlarının bu "düzeltmeyi" uygulamak zorunda kalacağı anlamına gelir). Bu uzun bir emirdir.

Uygulama katmanı protokolünü değiştirmek yerine, bazı protokoller, istekleri "yönlendirebilen" yazılımlar kullanarak birden çok ana bilgisayar arasında "çoğullamaya" uygundur. Bu, muhtemelen uygulama paketinde paketlerin denetlenmesi gerektiğinden basit bir NAT güvenlik duvarının yapabileceğinin ötesine geçer. Nginx gibi bir ters proxy kullanmak , HTTP protokolü için bu tür bir "çoklama" (veya Forefront TMG veya Microsoft ortamında ISA Server üzerinde Web yayınlama kuralları ) için iyi bir örnektir . Teoride, herhangi bir protokol ters bir proxy aracılığıyla çoğullanabilir, ancak protokol ne kadar ezoterik olursa, özel kodun yazılması hakkında daha fazla konuşmanız daha olasıdır.

Aynı hizmeti tek bir ortak IP adresinde iki farklı ana bilgisayardan sunmanız gerektiğinde, ana bilgisayarlardan birini standart olmayan bir bağlantı noktasına taşıma seçeneğiniz vardır. Ancak bu, istemcilerin standart olmayan bağlantı noktasından haberdar olmalarını gerektirir. HTTP (S) durumunda bu, http://example.com:XXXgösterimle URL'lerle sonuçlanır ( XXXstandart olmayan bağlantı noktası numarasıdır). Durumunuzda bunun sorunlu olup olmayacağı sadece sizin karar verebileceğiniz bir şeydir. (Deneyimlerim, neredeyse hiçbir son kullanıcının :XXXelle girmek zorunda oldukları URL'lerde bağlantı noktası gösterimini kaldıramadığını göstermiştir.)


1
Geçici çözüm, "düzeltme" değil. :)
Michael Hampton

@MichaelHampton - Seni duyuyorum! > smile <
Evan Anderson

@EvanAnderson Cevabınız için teşekkürler. Sanırım işleri berbat ettim çünkü ForeFront ile çalışmaya alışkındım, böyle bir görev bana normal geldi. Uygulama katmanında çalışan bu özelliğe sahip herhangi bir Linux güvenlik duvarı dağıtımının farkında mısınız? Henüz Shorewall'a baktım, ancak bunu yapabildiğinden emin değilim, çünkü bahsettiğiniz gibi ip katmanında bulunan iptables tabanlı.
Atrotygma

5

"Bağlantı Noktası Yönlendirme" özelliğiniz: 80 ve: 443 ila 192.168.124.30 ve kalan bağlantı noktaları (veya yalnızca e-posta sunucunuzun kullanmak üzere yapılandırılmış olanlar) için 192.168.124.32'ye hedeflenen trafiği göndermenize izin verebilir. Herhangi bir nedenle, e-posta sunucusu ve web sunucusu için bu iki bağlantı noktasından birine ihtiyacınız varsa, sorun yaşarsınız. Bu yöntemin çalışması için, e-posta sunucunuza herhangi bir web erişiminin farklı (büyük olasılıkla standart dışı) bir bağlantı noktasında olması gerekir. Bağlantı noktası numarasını nasıl ekleyeceğini ve / veya güvenli bağlantı belirleyeceğini bilmeyen kullanıcılar için web sunucusunu bunun yerine " mail.example.com" yazan her şeyi yeniden yönlendirecek şekilde de ayarlayabilirsiniz . (Sen edilir , doğru posta sunucusuna yalnızca güvenli web bağlantılarını kullanacağız?)https://mail.example.com:other_port

Bu, Uygulama katmanından ziyade Aktarım katmanındadır, yani derin paket denetimine dayanması gerekmez. Bunun yerine, bağlantı noktasının TCP üstbilgisinde bulunması kolay bir konuma bakabilir.


3

"Gelen istekleriniz" farklı şeyler, yani web sunucusu için web trafiği (HTTP) ve posta sunucusu için posta trafiği (SMTP) ise, bu gerçekten yapılabilir: HTTP SMTP yaparken 80 numaralı TCP bağlantı noktasını (HTTPS için 443) kullanır TCP bağlantı noktası 25'i kullanır; böylece, aynı genel IP adresinden HTTP trafiğini web sunucunuza, SMTP trafiğini posta sunucunuza iletebilirsiniz; "port yönlendirme" nin anlamı budur. İyi bir güvenlik duvarı bunu yapabilir.

Ancak, şans eseri iki sunucunun aynı tür trafiği kabul etmesi gerekiyorsa, posta sunucunuz bir web postası hizmeti de barındırıyorsa, sorun yaşarsınız, çünkü belirli bağlantı noktalarını (80 ve / veya 443) iletebilirsiniz sadece tek bir sunucuya; web trafiğini istemcinin istemek için kullandığı ada göre ayırmak için, ters proxy gibi TCP / IP'den daha yüksek düzeyde çalışan bir şeye ihtiyacınız vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.