qemu i brak przekierowania portów w iptables

[szakkanaku]

Udało mi się przekierować usługę www przy pomocy iptables. Okazało się, że wprawdzie miałem włączone przekierowanie portu:

Kod: Zaznacz cały

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.168.10.1:9001

ale zabrakło następujących wpisów:

Kod: Zaznacz cały

iptables -A INPUT -s 0/0 -p tcp -m state --state NEW,ESTABLISHED,RELATED -m tcp --dport 9001 -j ACCEPT

Kod: Zaznacz cały

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED -m tcp --sport 9001 -j ACCEPT

Usługa www już działa. Mały wypadek przy pracy.

Próbowałem podobnie uczynić w przypadku dns, ale sprawa pewnie jest bardziej skomplikowana. Mianowicie uczyniłem podobnie jak w przypadku usługi www:

Kod: Zaznacz cały

iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.168.10.1:9003

Kod: Zaznacz cały

iptables -A INPUT -s 0/0 -p udp -m state --state NEW,ESTABLISHED,RELATED -m udp --dport 9003 -j ACCEPT

Kod: Zaznacz cały

iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED,RELATED -m udp --sport 9003 -j ACCEPT

ale nie pomogło. Przez tcpdump sprawdziłem, że do maszyny wirtualnej docierają zapytania z zewnątrz i są wysyłane odpowiedzi. Z serwera, na którym uruchomiona została wirtualna maszyna, jednak zapytania nie docierały, ani też nie zostały przysyłane odpowiedzi m. in. po wydaniu polecenia:

Kod: Zaznacz cały

host e1.example.com

Dodam, że nazwa: e1.example.com, dotyczy interfejsu eth1. Wprowadziłem więc następujący wpis w firewallu:

Kod: Zaznacz cały

iptables -t nat -A OUTPUT -p udp -d 10.168.10.1 --dport 53 -j DNAT --to-destination 10.168.10.1:9003

Po wydaniu ponownie polecenia:

Kod: Zaznacz cały

host e1.example.com

zapytania zostały wysłane i przez tcpdump było widać:

Kod: Zaznacz cały

17:34:31.772058 IP e1.example.com.34432 > vm.example.com.domain: 47989+ A? e1.example.com. (46)
17:34:31.869507 IP vm.example.com.domain > e1.example.com.34432: 47989* 1/1/1 A 10.168.10.1 (99)

że odpowiedzi też są wysyłane z wirtualnej maszyny, ale to co pojawiło na serwerze było niesatysfakcjonujące:

Kod: Zaznacz cały

;; reply from unexpected source: 10.168.10.1#9003, expected 10.168.10.1#53
;; reply from unexpected source: 10.168.10.1#9003, expected 10.168.10.1#53
;; connection timed out; no servers could be reached

Jak widać odpowiedzi nie trafiają na ten sam port, z którego były wysłane zapytania, czyli 53, a w zamian za to są przesyłane na port docelowy, na który zostały wysłane wspomniane zapytania. Niby logiczne, ale zastanawiam się czemu odpowiedzi nie zostały przesłane na port 53, mimo że próbowałem także ustawić to przez przekierowanie, ale nic nie pomaga. Nie dotyczy to tylko serwera, ale także sieci wewnętrznej. W przypadku usługi www wszystko działa poprawnie, no chyba że odpowiedź powraca przez port 80, gdyż jest włączone przekierowanie. Czy ktoś wie jak rozwiązać ten węzeł gordyjski? Czy muszę jednak pogrzebać w ebtables by to rozwiązać, czy jednak można to zrobić w iptables?

[mariaczi]

szakkanaku jaki cel i sens widzisz w przekierowywaniu zapytań DNS na inne porty?
Nie kombinuj tylko zezwól systemowi gościowi na komunikację z serwerami DNS po standardowych portach.

[szakkanaku]

Z ciekawości sprawdziłem jeszcze raz - ustawiłem przekierowanie na port 53. Zapomniałem jednak, że to już sprawdzałem. W qemu zmieniłem przekierowanie z:

Kod: Zaznacz cały

hostfwd=udp:10.168.10.1:9003-10.168.10.100:53

na:

Kod: Zaznacz cały

hostfwd=udp:10.168.10.1:53-10.168.10.100:53

Pojawia się jednak komunikat podczas uruchamiania vm:

Kod: Zaznacz cały

could not set up host forwarding rule 'udp:10.168.10.1:53-10.168.10.100:53'

Proces uruchamiania jest następnie przerywany, a sam vm nie został uruchomiony.
Problem ten dotyczy także innych portów związanych z usługami takimi jak m. in. dhcp. Dlatego też jestem zmuszony przekierować numery tych portów na inne porty wyższe, a podczas tego procesu jak widać natrafiłem na problem.

Dodane:
Jest to jednak już tylko kwestia routingu, bo przekierowanie działa. Przez interfejs eth0 wszystko przechodzi, a do sieci lokalnej o interfejsie eth1 nie. Nawet w taki sposób nie działa przekierowanie stron, więc nic dziwnego że z dnsem są problemy. Będę musiał nad tym jeszcze posiedzieć.