Mam małą sieć z routerem, który utrzymuje połączenie z Internetem, serwerem i niektórymi stacjami roboczymi w sieci lokalnej.
Serwer powinien być dostępny z Internetu, aw routerze iptables ustawiono kilka wpisów DNAT, takich jak:
-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
Pakiety zewnętrzne przychodzą do routera przez ppp0
interfejs, a pakiety wewnętrzne z br-lan
, które faktycznie obejmują przełącznik i adapter WLAN. Problem polega na tym, że podczas gdy dostęp zewnętrzny działa dobrze, próba uzyskania dostępu do serwera z sieci LAN za pomocą zewnętrznego adresu IP rozpoznanego przez DNS (przypisanego ppp0
) kończy się niepowodzeniem.
Jedynym rozwiązaniem, które udało mi się wymyślić, jest dodanie statycznych wpisów do routera /etc/hosts
wskazujących na wewnętrzny adres IP, ale ponieważ nie ma symboli wieloznacznych (i mam co najmniej trzy domeny najwyższego poziomu przypisane do tego systemu, nie licząc dziesiątek subdomen), to raczej chrupiące i podatne na awarie. Czy możesz zasugerować coś lepszego?
Znalazłem tylko to pytanie , które nie było zbyt pomocne.
Jeśli to istotne, router działa z OpenWRT 10.03 Kamikaze z dnsmasq.
Odpowiedzi:
Dziwi mnie, że po prawie 8 latach nikt nie wyjaśnił, jak to zrobić poprawnie, używając systemu konfiguracji UCI używanego domyślnie w OpenWRT.
Odpowiedź Stevena Monday jest poprawna, ale używa ona
iptables
bezpośrednio poleceń, które są niższą warstwą niż system konfiguracji UCI i najlepiej pozostawić je nietkniętym przez większość użytkowników OpenWRT, jeśli to możliwe.Prawidłowym sposobem dostępu do wewnętrznych serwerów za pośrednictwem ich publicznych kombinacji adresów IP / portów z innego wewnętrznego hosta w UCI jest włączenie opcji konfiguracji w
reflection
ramach każdego określonego celu DNAT w pliku/etc/config/firewall
. To zachowanie jest tutaj udokumentowane .Na przykład:
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'
Uwaga: Zgodnie ze wskazaną dokumentacją OpenWRT
reflection
jest domyślnie włączona. W moich testach tak nie było.źródło
Usunąłem pierwotną odpowiedź, ponieważ nie byłem w pełni pewien, że jest poprawny. Od tego czasu miałem trochę czasu na skonfigurowanie małej wirtualnej sieci maszyn wirtualnych w celu symulacji danej sieci. Oto zestaw reguł zapory, które działały dla mnie (w
iptables-save
formacie, tylko dlanat
tabeli):Pierwsza
POSTROUTING
zasada to prosty sposób udostępniania połączenia internetowego LAN. Zostawiłem to dla kompletności.PREROUTING
Zasada i drugaPOSTROUTING
zasada wspólnie ustalić odpowiednie NAT, dzięki czemu połączenia z serwerem poprzez zewnętrzny adres IP może się zdarzyć, niezależnie od tego, czy połączenia pochodzą z zewnątrz lub od wewnątrz sieci LAN. Gdy klienci w sieci LAN łączą się z serwerem za pomocą zewnętrznego adresu IP, serwer widzi połączenia jako pochodzące z wewnętrznego adresu IP routera (192.168.2.1).Co ciekawe, okazuje się, że istnieje kilka odmian drugiej reguły POSTROUTING, które również działają. Jeśli cel zostanie zmieniony na
-j SNAT --to-source 192.168.2.1
, efekt jest (co nie jest zaskakujące) taki sam jakMASQUERADE
: serwer widzi połączenia od lokalnych klientów LAN jako pochodzące z wewnętrznego adresu IP routera . Z drugiej strony, jeśli zmieniono cel na-j SNAT --to-source 89.179.245.232
, wówczas NAT nadal działają, ale tym razem serwer widzi połączenia od lokalnych klientów LAN jako pochodzące z zewnętrznego adresu IP routera (89.179.245.232).Na koniec zauważ, że twoja oryginalna
PREROUTING
/DNAT
reguła z-i ppp0
nie działa, ponieważ reguła nigdy nie pasuje do pakietów pochodzących od klientów LAN (ponieważ te nie wchodzą do routera przezppp0
interfejs). Można by to zrobić, dodając drugąPREROUTING
regułę tylko dla wewnętrznych klientów LAN, ale byłoby to nieeleganckie (IMO) i nadal musiałoby jawnie odnosić się do zewnętrznego adresu IP.Teraz, nawet po dokładnym opisaniu rozwiązania „szpilka do włosów NAT” (lub „pętla NAT”, „odbicie NAT” lub cokolwiek innego, jak wolą to nazywać), nadal uważam, że rozwiązanie DNS z dzielonym horyzontem - -z klientami zewnętrznymi korzystającymi z zewnętrznego adresu IP i klientami wewnętrznymi korzystającymi z wewnętrznego adresu IP --- byłaby bardziej wskazana droga. Dlaczego? Ponieważ więcej osób rozumie, jak działa DNS, niż rozumie, jak działa NAT, a duża część budowania dobrych systemów decyduje się na części, które można konserwować. Konfiguracja DNS jest bardziej zrozumiała, a zatem poprawnie utrzymywana, niż tajemna konfiguracja NAT (oczywiście IMO).
źródło
Częstym rozwiązaniem jest skierowanie wewnętrznych hostów na lokalny serwer DNS, który zwraca poprawny „wewnętrzny” adres dla tych nazw hostów.
Innym rozwiązaniem - i używamy tego, gdy pracuję nad naszymi zaporami Cisco - jest przepisanie odpowiedzi DNS na zaporze ogniowej, które odpowiadają tym adresom. Nie sądzę, że istnieją narzędzia dla Linuksa, które teraz to robią.
Powinieneś być w stanie skonfigurować routing na swojej bramie, aby postępować właściwie. Konieczne może być skonfigurowanie serwerów, aby były świadome ich zewnętrznie zmapowanego adresu IP (np. Poprzez przypisanie go do fikcyjnego interfejsu). W tej konfiguracji komunikacja z jednego systemu wewnętrznego do innego systemu wewnętrznego - przy użyciu jego „zewnętrznego” adresu - przebiegałaby przez router.
źródło
ip rule add to 89.179.245.232 dev br-lan table 10; ip route add 89.179.245.232 via 192.168.2.10 dev br-lan table 10
i to nie działa.To, o co prosisz, nazywa się
NAT Loopback
i wymaga dodania reguły SNAT, aby pakiety pochodzące z Twojej sieci LAN na Twój serwer wracały przez router:źródło
-i ppp0
opcję w omawianej regule, ponieważ była ona obsługiwana przez inny łańcuch; reguła ta zapobiegałaby routingowi pakietów przychodzących z sieci LAN (a gdybym ją włączył, pakiety będą pochodzić z niewłaściwego źródła i zostaną odrzucone).Komentarz larsks na temat hostowania wewnętrznej wersji przestrzeni nazw \ domena jest ogólnie sposobem, w jaki radziłem sobie z tym problemem w przeszłości. Oczywiście, aby to zrobić, potrzebujesz serwera DNS wewnętrznie.
źródło
cname
nie obsługuje masek, a zatem nie dotyczy mnie z powodu liczby subdomen.Wymyśliłem następujące rozwiązanie, aby umożliwić mojej sieci gości połączenie z portami, które zostały przekierowane z mojej sieci WAN do LAN. Ten skrypt jest umieszczony w mojej sekcji „Sieć -> Zapora -> Reguły niestandardowe”:
Aby wesprzeć ponowne uruchomienie, musiałem uruchomić następujące polecenie z wiersza poleceń ssh na openwrt (w przeciwnym razie uważam, że istnieje warunek wyścigu, w którym niektóre reguły zostały dodane, a następnie usunięte podczas ponownego uruchamiania):
Odbicie NAT jest skonfigurowane dla połączeń w sieci LAN z samym sobą, ale nie z innymi sieciami, jeśli utworzono wiele interfejsów do izolowania ruchu. Próbowałem skonfigurować regułę przekazywania z interfejsu internetowego, ale wysyła on cały ruch do portu z sieci gościa do tego hosta LAN. Powyższe przechwytuje tylko żądania do WAN IP zamiast całego ruchu sieciowego.
Zamiast tego można użyć wewnętrznego DNS, ale tylko wtedy, gdy wszystkie przekierowania portów idą tylko do jednego hosta. Jeśli masz wiele hostów, na których przekazujesz różne porty, możesz powtórzyć reguły dla różnych portów dla różnych
tgthost
adresów IP i portów.źródło
conntrack
moduł dopasowania. Aby rozwiązać problem, wystarczy zastosować jedną taką zasadę:iptables -t nat -A POSTROUTING --dst <lan-net> ! --src <lan-gw-ip> -m conntrack --ctstate DNAT --ctorigdst <wan-gw-ip> -j MASQUERADE