LAN içinden DNAT'lı web sunucusuna erişim

Internet'e, sunucuya ve yerel ağdaki bazı iş istasyonlarına bağlantı sağlayan bir yönlendiricili küçük bir ağım var.

Sunucuya Internet'ten erişilmesi amaçlanmıştır ve yönlendirici iptables'ında birkaç DNAT girişi vardır, örneğin:

-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10

Harici paketler ppp0arabirime arabirim yoluyla gelir ve dahili br-lananahtarlar, aslında anahtar ve WLAN adaptörünü içerir. Sorun, harici erişim iyi çalışıyor olsa da, DNS çözümlemeli bir dış IP (atanmış ppp0) tarafından LAN içinden sunucuya erişmeye çalışmak başarısız.

İcat edebildiğim tek çözüm, yönlendiricinin /etc/hostsdahili IP'ye işaretine statik girişler eklemektir , ancak joker karakterler olmadığından (ve bu sisteme atanmış en az üç üst düzey alan adı var, onlarca alt alan adı saymıyor), bu oldukça gevrek ve başarısızlığa eğilimli. Daha iyi bir şey önerebilir misin?

Ben sadece çok yardımcı olmadı bu soruyu buldum .

İlgili ise, yönlendirici dnsmasq ile OpenWRT 10.03 Kamikaze çalıştırır.

Neredeyse 8 yıl sonra, hiç kimsenin bunu OpenWRT'de varsayılan olarak kullanılan UCI yapılandırma sistemini kullanarak nasıl doğru şekilde yapacağını açıklamamasına şaşırdım.

Steven Monday'in cevabı doğru, ancak iptablesdoğrudan UCI yapılandırma sisteminden daha düşük bir katman olan ve mümkünse çoğu OpenWRT kullanıcısı tarafından dokunulmadan bırakılan komutları kullanıyor .

UCI'deki başka bir dahili ana bilgisayardan genel IP / bağlantı noktası kombinasyonları aracılığıyla iç sunuculara erişmenin doğru yolu reflection, dosyadaki her bir DNAT hedefinin altındaki yapılandırma seçeneğini etkinleştirmektir /etc/config/firewall. Bu davranış burada belgelenmiştir .

Örneğin:

config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option src_dport '44322' option dest_ip '192.168.5.22' option dest_port '443' option name 'apache HTTPS server' option reflection '1'

Not: Belirtilen OpenWRT belgelerine göre, reflectionvarsayılan olarak etkindir. Testlerimde durum böyle değildi.

Orijinal cevabımı sildim, çünkü bunun doğru olduğundan tam olarak emin değildim. O zamandan beri söz konusu ağı simüle etmek için küçük bir sanal VM ağı kurmak için biraz zamanım oldu. İşte benim için çalışan güvenlik duvarı kuralları kümesi ( yalnızca tablo iptables-saveiçin formatta nat):

-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE

İlk POSTROUTINGkural, internet bağlantısını LAN ile paylaşmanın kolay bir yoludur. Bütünlük için orada bıraktım.

PREROUTINGKural ve ikinci POSTROUTINGdış IP adresi üzerinden sunucuya bu bağlantıların bakılmaksızın bağlantıları LAN içindeki dışarıdan ya kaynaklanan olsun, başına gelebilir bu yüzden birlikte kural, uygun NAT kurarlar. LAN üzerindeki istemciler sunucuya harici IP adresi üzerinden bağlandığında, sunucu bağlantıları yönlendiricinin dahili IP adresinden (192.168.2.1) geliyormuş gibi görür.

İlginç bir şekilde, ikinci POSTROUTING kuralının da işe yarayan birkaç varyasyonu olduğu ortaya çıktı. Hedef olarak değiştirilirse -j SNAT --to-source 192.168.2.1, etki (şaşırtıcı değil) şu şekilde aynıdır MASQUERADE: sunucu yerel LAN istemcilerinden gelen bağlantıları yönlendiricinin dahili IP adresinden kaynak olarak görür . Diğer taraftan, hedef olarak değiştirilirse -j SNAT --to-source 89.179.245.232, NAT'lar yine de çalışır, ancak sunucu yerel LAN istemcilerinden gelen bağlantıları yönlendiricinin harici IP adresinden (89.179.245.232) kaynak olarak görür .

Son olarak, orijinal PREROUTING/ DNATkuralınızın -i ppp0çalışmadığına dikkat edin , çünkü kural asla LAN istemcilerinden gelen paketlerle eşleşmez (bunlar yönlendiriciye ppp0arabirim yoluyla girmediği için ). Yalnızca PREROUTINGdahili LAN istemcileri için ikinci bir kural ekleyerek çalışmasını sağlamak mümkün olacaktır , ancak bu durum uygun olmayabilir (IMO) ve yine de açıkça harici IP adresine başvurması gerekir.

Şimdi, bir "saç tokası NAT" (veya "NAT geri döngü" veya "NAT yansıması" ya da bir kişi onu tercih etse de) çözümü ayrıntılı olarak ortaya koyduktan sonra bile, bölünmüş bir DNS çözümünün-- - harici IP'ye giden harici istemciler ve dahili IP'ye giden dahili istemciler ile - daha tavsiye edilen yol olacaktır. Neden? Çünkü daha fazla insan DNS'nin nasıl çalıştığını anlıyor ve NAT'ın nasıl çalıştığını anlıyor ve iyi sistemler kurmanın büyük bir kısmı bakımı yapılabilen parçaları kullanmayı seçiyor. Bir DNS kurulumunun, gizli bir NAT kurulumundan (elbette IMO) daha iyi anlaşılması ve dolayısıyla doğru bir şekilde sürdürülmesi muhtemeldir.

Yaygın bir çözüm, dahili ana makinelerinizi bu ana makine adları için doğru "dahili" adresi döndüren yerel bir DNS sunucusuna yönlendirmektir.

Başka bir çözüm - ve bunu Cisco güvenlik duvarlarımızda çalıştığım yerde kullanıyoruz - güvenlik duvarında bu adreslere karşılık gelen DNS yanıtlarını yeniden yazmaktır. Linux için şu anda bunu yapan araçlar olduğunu sanmıyorum.

Doğru şeyi yapmak için ağ geçidinizdeki yönlendirmeyi yapılandırabilmeniz gerekir. Sunucuları, harici olarak eşlenen IP adreslerinden haberdar olacak şekilde yapılandırmanız gerekebilir (örneğin, sahte bir arayüze atayarak). Bu yapılandırmayla, bir dahili sistemden başka bir dahili sisteme ("harici" adresini kullanarak) iletişim yönlendiriciden geçer.

Yapmak istediğiniz şey çağrılır NAT Loopbackve LAN'ınızdan Sunucunuza gelen paketlerin yönlendiriciye geri dönmesi için bir SNAT kuralı eklemenizi gerektirir:

-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232

larsks, ad alanının \ etki alanının dahili bir sürümünü barındırmayla ilgili yorum genellikle bu sorunu geçmişte ele alma şeklimdir. Tabii ki, bunu yapmak için dahili olarak bir DNS sunucusuna ihtiyacınız var.

Konuk ağımın, wan ağımdan yönlendirilen bağlantı noktalarına bağlanmasına izin vermek için aşağıdaki çözümü buldum. Bu komut dosyası "Ağ -> Güvenlik Duvarı -> Özel Kurallar" bölümüme yerleştirildi:

# lookup the public IP (DDNS resolves to this)
wanip=$(ip route get 8.8.8.8 | awk -F"src " 'NR==1{split($2,a," ");print a[1]}')

# Guest network to LAN
# srcname is the guest network name, this needs to match for iptables
srcname=guest
# CIDR notation of guest and lan networks
srcnet=192.168.15.0/24
tgtnet=192.168.10.0/24
# router (openwrt) IP on lan network
tgtrouter=192.168.10.1
# host on lan network where ports are normally forwarded
tgthost=192.168.10.5
# ports to forward as a list or range
tcpports=8080,9090
udpports=12345

prechain=prerouting_${srcname}_rule
postchain=postrouting_${srcname}_rule

# reset the tables to prevent duplicate rules
iptables -t nat -F ${prechain}
iptables -t nat -F ${postchain}

iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP SNAT" -j SNAT --to-source ${tgtrouter}
iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP SNAT" -j SNAT --to-source ${tgtrouter}

Yeniden başlatmayı desteklemek için, openwrt üzerindeki ssh komut satırından aşağıdakileri çalıştırmam gerekiyordu (aksi takdirde, bazı kuralların eklendiği ve yeniden başlatma sırasında temizlendiği bir yarış durumu olduğuna inanıyorum):

uci set firewall.@include[0].reload="1"
uci commit firewall

NAT yansıması, LAN ağındaki bağlantılar için kendi kendine kurulur, ancak trafiği izole etmek için birden fazla arabirim oluşturduysanız diğer ağlara kurulmaz. Web arayüzünden bir yönlendirme kuralı yapılandırmayı denedim, ancak bu, konuk ağdan bir LAN ana bilgisayarına bir bağlantı noktasına tüm trafiği gönderir. Yukarıdaki, tüm ağ trafiği yerine WAN IP'sine yapılan istekleri durdurur.

Bunun yerine dahili bir DNS kullanılabilir, ancak yalnızca tüm bağlantı noktası iletimleri yalnızca tek bir ana bilgisayara giderse. Farklı bağlantı noktalarını ilettiğiniz birden çok ana bilgisayarınız varsa, farklı bağlantı noktaları için kuralları farklı IP'lere tgthostve bağlantı noktalarına tekrarlayabilirsiniz .