it-swarm.asia

Yerel ağdan yönlendirilen Genel IP adresine geri döngü - Hairpin NAT

Bu bir Kanonik Sor Firkete hakkında NAT (Geridönüş NAT).

Bu sorunun genel formu:

İstemciler, bir sunucu ve bir NAT Yönlendirici ile bir ağımız var. Yönlendiricide sunucuya bağlantı noktası yönlendirmesi var, bu nedenle hizmetlerinin bir kısmı harici olarak kullanılabiliyor. Yerel ağ istemcileri bağlanamıyor, ancak harici çalışıyor.

  • Bu neden başarısız oluyor?
  • Birleştirilmiş bir adlandırma şemasını nasıl oluşturabilirim (hem yerel hem de harici olarak çalışan DNS adları)?

Bu soru, diğer birçok sorudan alınan yanıtları içermektedir. Başlangıçta FreeBSD, D-Link, Microtik ve diğer ekipmanlara atıfta bulundular. Ancak hepsi aynı sorunu çözmeye çalışıyor.

46
adopilot

Aradığın şeye "saç tokası NAT" deniyor. Harici arabirime atanan bir IP adresi için dahili arabirimden gelen istekler, harici taraf arabiriminden gelmiş gibi, NAT'ted olmalıdır.

Hiç FreeBSD alışkanlığım yok, ancak OpenBSD için "pf" kılavuzunu ( http://www.openbsd.org/faq/pf/rdr.html ) önerilen çözümlerin okunması bölünmüş ufuk DNS, DMZ ağ veya TCP proxy uygulaması beni "pf" nin saç tokası NAT'ı desteklemediğine inandırıyor.

Split-horizon DNS rotasına gidip URL'lerde dahili olarak IP adresleri değil, isimleri kullanarak bakıyorum.

16
Evan Anderson

Bu saç tokası NAT üzerinde kanonik soru olarak yükseltildiğinden, muhtemelen şu anda kabul edilen cevaptan daha geçerli olan bir cevabı olması gerektiğini düşündüm, ki bu (mükemmel olsa da) özellikle FreeBSD'ye.

Bu soru, RFC1918 adresli IPv4 ağlarındaki sunucular tarafından sağlanan ve dış kullanıcılara ağ geçidinde hedef NAT (DNAT) eklenerek sağlanan hizmetler için geçerlidir. Paketleri istemciden hedef adresi yeniden yazan ve hemen dahili ağa enjekte eden ağ geçidi cihazına gider.Paket, ağ geçidine yol açan ağ geçidinde bu kadar dönüş yapar name saç tokası NAT , saç tokası dönüşü ile benzer şekilde.

Sorun, ağ geçidi aygıtı kaynak adresi yeniden değil, hedef adresi yeniden yazdığında ortaya çıkar. Sunucu daha sonra dahili hedef adresi (kendi) ve dahili kaynak adresi (istemcinin) olan bir paket alır; böyle bir adrese doğrudan cevap verebileceğini biliyor, bu yüzden yapıyor. Bu yanıt doğrudan olduğundan, ağ geçidi üzerinden gitmez, bu nedenle gelen hedef NAT dönüşün kaynak adresini yeniden yazarak ilk paket üzerindeki etkisini dengeleme şansı asla olmaz) paket.

Böylece istemci bir harici IP adresine bir paket gönderir, ancak dahili IP adresinden bir yanıt alır. İki paketin aynı konuşmanın bir parçası olduğu hakkında hiçbir fikri yoktur, bu nedenle konuşma gerçekleşmez.

Çözüm böyle bir hedef NAT gerektiren ve iç ağdan ağ geçidine ulaşan paketler için, ayrıca kaynak NAT (SNAT)) Gelen paket, genellikle kaynak adresini ağ geçidinin adresi olarak yeniden yazarak, sunucu daha sonra istemcinin ağ geçidinin kendisi olduğunu düşünür ve doğrudan ona yanıt verir.Bu, ağ geçidine hem DNAT hem de SNAT'ın etkilerini dengeleme şansı verir. iade paketindeki hem kaynak hem de hedef adresleri yeniden yazarak gelen pakette.

İstemci harici bir sunucuyla konuştuğunu düşünüyor. Sunucu, ağ geçidi cihazıyla konuştuğunu düşünüyor. Tüm partiler mutlu. Bir şema bu noktada yardımcı olabilir:

enter image description here

Bazı tüketici ağ geçidi aygıtları, ikinci NAT adımın gerekli olduğu paketleri tanıyacak kadar parlaktır ve bunlar muhtemelen bir saç tokasında kutudan çıkar çıkmaz çalışacaktır NAT senaryo: Diğerleri değildir ve olmayacaktır ve çalışmayacak olmaları olası değildir. Hangi sunucu sınıfı cihazlarının Sunucu Hatası için konu dışı olduğu üzerine bir tartışma.

Uygun ağ aygıtlarının genel olarak çalışması söylenebilir, ancak - yöneticilerini ikinci olarak tahmin etme işinde olmadıkları için - bunu söylemeleri gerekir. Linux DNAT yapmak için iptables kullanır:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

hTTP bağlantı noktası için basit bir DNAT'yi 192.168.3.11. Ancak saç tokası NAT'ı etkinleştirmek için aşağıdakiler gibi bir kurala da ihtiyaç duyulur:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Düzgün çalışması için bu tür kuralların ilgili zincirlerde doğru yerde olması gerektiğini ve filter zincirindeki ayarlara bağlı olarak, NATlu trafiğin akmasına izin vermek için ek kurallar gerekebilir. Tüm bu tartışmalar bu cevabın kapsamı dışındadır.

Ancak diğerlerinin söylediği gibi, firketenin doğru şekilde etkinleştirilmesi NAT sorunu ele almanın en iyi yolu değildir. En iyisi bölünmüş ufuk DNS , kuruluşunuzun talep eden istemcinin bulunduğu yere bağlı olarak, dahili veya harici kullanıcılar için farklı fiziksel sunuculara sahip olması veya DNS sunucusunu, istekte bulunan müşterinin adresi.

49
MadHatter

Buradaki sorun, yönlendiricinizin NAT dahili müşterinizin adresi olmamasıdır. Böylece, TCP el sıkışma başarısız olur.

Aşağıdaki IP'leri kabul edelim

  • Müşteri: 192.168.1.3
  • Sunucu: 192.168.1.2
  • Dahili yönlendirici: 192.168.1
  • Harici yönlendirici: 123.123.123.1

İşte olanlar:

  1. İstemci (192.168.1.3) harici IP'nize 80 numaralı bağlantı noktasını TCP-SYN gönderir (123.123.123.1:80)
  2. Yönlendirici bağlantı noktası yönlendirme kuralını görür ve kaynak IP'yi (192.168.1.3) değiştirmeden paketi sunucuya (192.168.1.2:80) iletir.
  3. İstemci harici IP'den SYN-ACK bekler
  4. Sunucu aynı alt ağda olduğu için yanıtını doğrudan istemciye geri gönderir. Paketi NAT'a ters çevirecek olan yönlendiriciye göndermez.
  5. Müşteri, SYN-ACK'yı 123.123.123.1 yerine 192.168.1.2'den alır. Ve atar.
  6. Müşteri hala 123.123.123.1'den SYN-ACK bekler ve zaman aşımına uğrar.
9
PEra

Neden her yerde sabit kodlu IP adresleri yerine split horizon dns kullanmıyorsunuz? Dış alan adınız dışta 217.x.x.x'i, sonra içte 192.x.x.x'i işaret eder.

4
Ryaner

Orijinal bir D-Link yönlendiricisi (ör. Virgin Media'dan Rev. D/Bellenim Sürümü 1.00VG değil), bu sorunu çözmek için ayarları değiştirebilmeniz gerekir. (Bununla birlikte, diğer birçok nedenden ötürü bir önceki afişin DD-WRT önerisine katılıyorum!)

  1. Yönelticinin web arayüzünde oturum açın
  2. Üst taraftaki Gelişmiş sekmesini tıklayın
  3. Soldaki Güvenlik Duvarı Ayarları sekmesini tıklayın
  4. Aşağıdaki ekran görüntüsünde gösterildiği gibi TCP Bitiş Noktası Filtreleme altındaki Bitiş Noktası Bağımsız radyo düğmesini tıklayın (veya D'deki yönlendirici emülatörü -Link web sitesi)
  5. Değişiklikleri Kaydet; sen bittin

D-Link router web UI screenshot

Bu ekran görüntüsü Rev. C modelinden; seninki biraz farklı olabilir.

2
David

Son zamanlarda benzer bir soruyu yanıtladı: Cisco static NAT LAN tarafında çalışmıyor ve bunun kanonik bir soru olduğunu fark ettim. burada çözüm.

Her şeyden önce: NAT (mümkünse)) - soru NAT'ı yapılandırmakla ilgili değildir. Arkasına yerleştirilmiş bir sunucuya erişmekle ilgilidir NAT from İki DNS bölgesi kullanmak uygulanabilir bir alternatiftir, ancak her zaman çözüm değildir.Ancak çözüm var ve inanılmaz derecede basittir (mükemmel olmasa da, muhtemelen):

(1) sunucuda: genel IP adresini 255.255.255.255 maskesi ile sunucunun ağ arabiriminde ikincil IP adresi olarak ekleyin (web hizmeti veya sunucuda istediğiniz her şey bu IP adresini de dinlemelidir); tüm modern işletim sistemleri bunu yapmanıza izin verecektir (veya birincil arabirime ikincil bir IP eklemek yerine, kendisine atanan genel IP adresi olan bir geri döngü arabirimi kullanılabilir).

(2) LAN ana bilgisayarlarına: genel IP adresi için bir Ana Bilgisayar yolu ekleyin, örneğin Windows ana bilgisayarları için aşağıdaki komutu kullanın: route -p 203.0.113.130 mask 255.255.255.255 192.168 ekle .1.11 (rotayı dağıtmak için DHCP "statik yol" seçeneğini de kullanabilirsiniz). Veya, istemciler ve Internet'e bakan yönlendirici arasında (a) L3 anahtar (lar)/yönlendirici (ler) varsa, bu (bu) ara anahtar (lar)/yönlendirici (ler) üzerinde Ana Bilgisayar yolunu yapılandırın, istemciler.

TCP üç yönlü el sıkışma ile ilgili olanlar için: önerilen yapılandırmada TAMAM çalışacaktır.

Lütfen geri bildirim sağlayın (en azından oy verin).

2
Sergio

Teknik açıdan bu soruna en iyi çözüm ağınızda IPv6'yı etkinleştirmektir. IPv6 etkinleştirildiğinde alan adınız için bir AAAA kaydı oluşturmanız gerekir. yönlendiricinin harici IPv4'üne işaret eden mevcut A kaydını tutun. sunucusunun IPv6 adresini işaret eden bir AAAA kaydı oluşturun .

IPv6 NAT önlemek için yeterli adresleri vardır, bu yüzden saç tokası NAT. Ve IPv6 etkinleştirdikten ve AAAA kayıtları oluşturduktan sonra RFC 8305 IPv4'ten önce IPv6'yı deneyecek. Bu, istemcilerin kullanamayacağı için saç tokası NAT gerekmez) anlamına gelir.

Yine de, dünyanın çoğu IPv6'yı etkinleştirene kadar giden bağlantılar ve gelen bağlantılar için bağlantı noktası yönlendirme için mevcut IPv4 NAT) gerekir.

Aynı zamanda daha hızlı.

IPv6 kullanmak, saç tokası NAT'dan daha iyi bir performans sağlayacaktır.

Hairpin NAT istemciniz yönlendiriciye bir anahtar aracılığıyla bir paket gönderir, yönlendirici daha sonra iki tur çeviri gerçekleştirir ve son olarak paketi anahtar aracılığıyla sunucuya gönderir. tüm yol boyunca tersine gidecektir.

IPv6 ile NAT önlersiniz, bunun yerine paketler doğrudan istemci ve sunucu arasındaki geçiş yoluyla gönderilir. Bu, bir gidiş dönüşte, anahtardan geçiş sayısını 4'ten 2'ye düşürdüğünüz ve yönlendiriciden 2 yönlendirmenin ve yönlendiricinin gerçekleştireceği 4 çeviriden kaçındığınız anlamına gelir. Bu, daha iyi performans anlamına gelir.

Bu, yönlendiriciyle aynı kutuda yerleşik bir anahtar kullansanız bile geçerlidir.

ISS'de IPv6 yoksa ne olur?

IPv6'yı desteklemeyen bir ISS kullanıyorsanız, bu ağda sunucu barındırıp barındırmayacağınızı soracağım. Bunlar, ISS şu anda IPv6'yı desteklemiyorsa ne yapacağımla ilgili önerilerim.

Önce ISS'ye IPv6'ya ihtiyacınız olduğunu söyleyin. Ve belki onlara IPv6 protokolünün yaklaşık 20 yıldır olduğunu hatırlatmak, bu yüzden onu desteklemekte gecikmişler. ISS'nin sizi ciddiye alması için yeterli değilse, diğer ISS'leri aramaya başlayın.

IPv6 destekli bir İSS bulursanız, geçiş süresi için her iki İSS ile de çalışabilirsiniz. Yeni ISS'ye bağlı yönlendiricide LAN tarafında IPv4'ü devre dışı bırakabilir ve ardından her iki yönlendiricinin LAN taraflarını aynı anahtara bağlayabilirsiniz. IPv4 ve IPv6 iki bağımsız protokoldür ve bu nedenle bu bağlantıların farklı yönlendiricilerden geçmesi hiç sorun değildir. Bir yan fayda olarak, bağlantılardan birinde bir kesinti varsa size bir miktar fazlalık verir.

IPv6 destekli bir ISS bulamazsanız, sunucunuzu bir barındırma tesisine taşımayı düşünebilirsiniz. Bir barındırma tesisinde bir sunucu ile coğrafi konuma daha az bağımlısınız ve bu nedenle sağlayıcılar arasında ihtiyaçlarınızı karşılayan bir tane olmasını sağlamaya yardımcı olacak daha fazla rekabet var.

Sunucuyu bir barındırma tesisine taşımak istemcilerinize IPv6 vermeyecektir, ancak sunucuyu taşımak artık ona ulaşmak için hairpin NAT) gerekmediği anlamına gelir.

Yapmamanız gerekenler

IPv6 trafiğini yönlendirmek için bir yolunuz yoksa IPv6'yı açmayın ve AAAA kayıtları oluşturmayın. İSS'niz IPv6'yı desteklemiyorsa, ancak yine de LAN'ınızda IPv6'yı etkinleştirmeyi (belki RFC 4193 adreslerini kullanıyor) ve AAAA kayıtları oluşturmayı seçerseniz, LAN'ınızdaki LAN'ınızdaki sunucuya ulaşan istemciler için çalışacaktır. Ancak LAN'ınız ve dış dünya arasındaki iletişim ilk önce IPv6'yı dener (ki bu işe yaramaz) ve en azından biraz daha yavaş veya en kötü şekilde gerçekleşmeyen IPv4'e geri dönmeye güveniyor olacaksınız.

1
kasperd

Sorularıma sadece benzer problemleri olan ufukları genişletmek için cevap vereceğim.

İnternet Servis Sağlayıcım ile temasa geçtim ve onlardan sorunlarımı çözmeyi denemelerini istedim. Bana sundukları şey sadece sunucu için başka bir genel IP adresi, Şimdi FreeBSD'nin WAN tarafında yerel trafiğe sahibim ve Sunucunun genel IP'sine daha hızlı verim için özel borular yaptık

1
adopilot

Buraya bir cevap ekleyeceğim, çünkü buradaki yorumlar benim özel sorunuma değinmedi. Bunun kötü bir linux çekirdek hatasına çarptığımdan şüpheleniyorum. Kurulum:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Karmaşık görünümlü resme rağmen, diğer yorumlarda yer alan durumlardaki tek ilgili değişiklik, yazılım köprüsünün eklenmesidir, br0. Ağ geçidi kutusu da LAN için bir kablosuz erişim noktası olduğu için orada.

Ağ geçidi kutumuz hala LAN'daki makineler için NAT görevleri yapıyor. Sadece 1 ethernet portu olduğundan, saç tokası NAT yapmak zorunda kalıyor. Sadece verilen iptables kurallarıyla çalışması gerektiğinden şüpheleniyorum Buradaki diğer yorumlarda, ancak Linux çekirdeği 4.9'da en azından öyle değil. 4.9'umuzda ağ geçidi kutumuz Internet'e erişebilirken LAN üzerindeki makineler NAT 't.

tcpdump, eth0'a çarpan gelen paketlere verilen yanıtları gösterir, ancak br0'dan çıkarmazlar. Bu komutu çalıştırmak şu sorunu giderir:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Bu komut çalıştırılmadan önce gelen paketler çekirdeğin varsayılan davranışına göre işlenir, bu da onları köprüye vermek ve ardından çekirdek yönlendirme modüllerini iletmektir. Komut, LAN'dan olmayan paketleri köprüyü atlamaya ve doğrudan yönlendirmeye gitmeye zorlar, bu da köprünün onları düşürme şansı olmadığı anlamına gelir. Yayın ve çok noktaya yayın adresleri köprülenmelidir, aksi takdirde DHCP ve mDNS gibi şeyler çalışmaz. IPv6 kullanıyorsanız, bunun için de kurallar eklemeniz gerekir.

Bunu kullanarak sorunu gidermeye cazip gelebilirsiniz:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Kesinlikle çok cazip davrandım - bu benim ilk girişimimdi. En kısa sürede ben LAN makineleri internet erişim kazandı, bu yüzden bir süre çalışır. Sonra aşağıdakiler meydana geldi (ve deneyi tekrarlamayı umursamadım):

  1. LAN üzerinden ağ geçidine ping süreleri, ağ geçidi kutusuna LAN'dan erişilinceye kadar 0,1 ms'den 0,2 ms, 0,4 ms, 0,8 ms, 2 ms'ye kadar 10 saniyelik aralıklarla iki katına çıktı. Bir paket fırtınası gibi kokuyordu, ama STP her yerde açıldı.
  2. Tüm kablosuz erişim noktaları öldükten kısa bir süre sonra.
  3. Kablosuz ile olanları teşhis etmeye çalışırken, tüm IP telefonlar yeniden başlatıldı.
  4. Bundan kısa bir süre sonra, kablolu makineler LAN ile tüm temasını kaybetti.

Tek çıkış yolu, binadaki her makineyi yeniden başlatmaktı. Tek istisna, yeniden başlatılamayan donanım anahtarlarıydı. Güç çevrimi gerekiyordu.

0
Russell Stuart

Bu soruyu da sorduğumdan beri (bkz. Güvenlik duvarının arkasından gelen bir IP hizmetine dışarıdan IP'sini kullanarak nasıl erişebilirim? ) ve buraya yönlendirildi, ancak buradaki cevaplar bir solution (generic açıklamalar) herkese birkaç saatlik deneme yapmak için Linux (iptables spesifik) çözümümü burada sunsun. Bu dosya iptables-restore formatında ve doğrudan iptables okunabilir (tabii ki IP adreslerini düzenledikten sonra). Bu bir web sunucusu (bağlantı noktası 80) içindir ve yalnızca IPv4 içindir - IPv6 ve SSL (bağlantı noktası 443) için kurallar benzerdir.


# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Değiştir lan.local, web.local ve web.public.com ile yerel ağınız (ör. 10.0.x.0/24), web sunucunuzun yerel IP'si (ör. 10.0.1.2) ve yönlendiricinizin genel IP'si (ör. 4.5.6.7). -4 yalnızca aynı dosyada IPv6 ve IPv4 kurallarına izin vermek içindir (bu satırlar ip6tables). Ayrıca, bağlantı noktası bildirimlerini içerdiklerinde IPv6 adreslerini [köşeli ayraçlar] içine koymayı unutmayın; ör. [fe0a:bd52::2]:80.

Bu sorudaki açıklamalar aslında uygulamak saçlarımı çekmeme neden olan şeylerdi. Umarım hiçbir şeyi dışarıda bırakmam.

0
Jens

Kanonik bir soru olduğu için. Sonicwall yönlendiriciniz varsa cevaplayacağım.

Bilinmesi gereken ifade NAT geri döngü politikası

Bu belgede, bir SonicWall LAN üzerindeki bir Ana Bilgisayarın, sunucunun genel IP adresini FQDN'ye kullanarak SonicWall LAN üzerindeki bir sunucuya nasıl erişebileceği açıklanmaktadır. Birincil LAN Alt Ağının 10.100.0.0/24 ve Birincil NSA IP'nin 3.3.2.1 olduğu bir WAN 4500 (SonicOS Enhanced) ağ) düşünün. diyelim ki müşterileriniz için bir Web siteniz var ve ana bilgisayar adı. Yabancıların web sitesine girebilmesi için gerekli olan politika ve kuralları zaten yazdınız, ancak gerçekten özel bir yan sunucuda çalışıyor 10.100.0.2. 10.100.0.200 IP'si ile özel tarafta bir dizüstü bilgisayar kullanan bir kişisiniz.Windows yoldayken de aynı şeyi yaptığınızdan sunucuya genel adını kullanarak ulaşmak istiyorsunuz. özel taraf ve istek http://www.example.com >, sunucu yerel bir IP adresinde hemen yanınızda olmasına rağmen, geri döngü bunun çalışmasını mümkün kılan şeydir .

Bu işlevselliğe izin vermek için NAT yansıma veya toka) olarak da bilinen bir NAT geri döngü politikası oluşturmanız gerekir.

WAN Arayüzün IP Adresini kullanarak Geridöngü İlkesi

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall, iletişim kurmaya çalıştığınız harici hizmeti tanıyacak ve hedef adresi sunucunun dahili adresine uyacak şekilde yeniden yazacak ve böylece bilgisayara şeffaf olacaktır.

0
yagmoth555