Przekierowanie portów na VPS/kontener LXC

[Fizyda 34]

Posiadam na matce jeden interfejs i 2 adres ip (publiczne). Serwer jest w ovh, drugi adres ip dodany jako eth0:0. Na serwerze mam też CSF'a i to za jego pomocą przekierowuję porty.

 

Właściwie wszystko działa, jest tylko jeden problem wszystkie połączenia przychodzące na przekierowanych portach na kontenery pochodzą z adresu ip eth0:0.

Czyli np z innego komputera łączę się z serwerem WWW i php widzi mojego adresu ip tylko podaje jako mój adres drugi (eth0:0) adres ip serwera matki z którego porty są przekierowywane. To raczej nie powinno tak działać.

 

Kontener ma stworzonego bridga

auto br-0
iface br-0 inet static
        bridge_ports none
        bridge_fd 0
        bridge_maxwait 0
        address 192.168.1.1
        netmask 255.255.255.0

konfiguracja kontenera:

lxc.network.type = veth
lxc.network.name = eth0
lxc.network.flags = up
lxc.network.link = br-0
lxc.network.ipv4 = 192.168.1.2/24
lxc.network.ipv4.gateway = 192.168.1.1

Przekierowanie portów w csf.redirect:

publiczne_ip|80|192.168.1.2|80|tcp

Co dziwniejsze dodanie takiej reguły powoduje że jeśli np połączę się z matki z kontenerem po telnecie:

telnet 192.168.1.2 25

w logach mam też informacje o połączeniu klienta z adresu ip którym jest mój publiczny adres eth0:0.

 

Ma ktoś jakiś pomysł? Bo mi już nic do głowy nie przychodzi.

 

Podejrzewam, że wina leży po stronie csf, dokładniej tego jak generuje regułę iptables dla przekierowania portu. Chociaż jak znam życie na pewno ja coś skopałem i ustawiłem nie tak jak się to powinno robić, a wszystko mi działa bo głupi ma zawsze szczęście ...

 

EDIT:

Z WWW to taki przykład, problem trapi wszystkie usługi. Zdaję sobie również sprawę że NAT nadpisuje adres ip źródłowy i mapuje go sobie, ale chyba da się to obejść. W końcu jeśli mamy matkę i VPS to jakoś VPSy mają publiczne ip bez problemu i wszystko ładnie działa.

Edytowano Lipiec 28, 2016 przez Fizyda (zobacz historię edycji)

[hemi 20]

Wg dokumentacji CSF:

 

 

All redirections to another IP address will always appear on the destination
server with the source of this server, not the originating IP address.

 

W samej dokumentacji csf także nie ma jako tako opcji NATowania portu (a o to Ci w tym momencie chodzi).

Spróbuj zrobić to wg tej instrukcji: https://blackonsole.org/how-to-add-nat-iptables-rules-with-csf/

[Fizyda 34]

Wg dokumentacji CSF:

 

W samej dokumentacji csf także nie ma jako tako opcji NATowania portu (a o to Ci w tym momencie chodzi).

Spróbuj zrobić to wg tej instrukcji: https://blackonsole.org/how-to-add-nat-iptables-rules-with-csf/

 

Niestety nie pomogło, nawet wyłączyłem CSF i dodałem reguły z palca, nic się nie zmieniło cały czas widoczne jest ip matki.

[hemi 20]

Znalazłem jeszcze coś takiego (problem wydaje sie taki sam, jak Twój): http://serverfault.com/questions/452183/keep-source-ip-after-nat

 

Kurcze, nie mam akurat pod ręką żadnej matki z kontenerami lxc więc ciężko mi samemu sprawdzić Twój problem, ogólnie jednak pamiętam, że konfigurując kiedyś dla jednego klienta serwer (aczkolwiek bez CSF na matce) nie miałem takiego problemu, tzn adres źródłowy połączenia był poprawnie widziany przez np apache w kontenerze po utworzeniu odpowiedniej reguły iptables.

[Fizyda 34]

Nie zastosowałem jego rozwiązania bo miałem je już wpisane w csfpre.sh by contenery gdy łączą się same z internetem miały konkretny adres ip. Zastosowałem za to jego reguły przekierowania portów i poszło, wszystko działa jak powinno. Nie wiem czemu, ale już nie wnikam.

 

Dzięki za pomoc, jutro dam Ci plusy bo w nocy wyczerpałem limit :/.

 

Pytanie tylko czy będzie na tym działać https i reszta usług z (s).

[Kashi66 2]

Jak znajdziesz sposób na naprawienie tego to podziel sie tutaj nim.

Mam ten sam problem z LXC, każdy na moim kontenerze z teamspeakiem posiada adres ip matki.

[hemi 20]

Czemu mialyby nie dzialac? NAT działa na innym poziomie stacka TCP, NAT routuje Ci calutki ruch tak, jak sobie to skonfigurujesz przez iptables. Co innego jak byś się bawił w np proxowanie ruchu przez nginxa, squida czy inne aplikacje, które wtedy już działają na innym poziomie .

[Fizyda 34]

Czemu mialyby nie dzialac? NAT działa na innym poziomie stacka TCP, NAT routuje Ci calutki ruch tak, jak sobie to skonfigurujesz przez iptables. Co innego jak byś się bawił w np proxowanie ruchu przez nginxa, squida czy inne aplikacje, które wtedy już działają na innym poziomie .

Już tyle rzeczy mi nie działało pomimo iż powinno, że już wszystkiego się spodziewam .

 

 

Jak znajdziesz sposób na naprawienie tego to podziel sie tutaj nim.

Mam ten sam problem z LXC, każdy na moim kontenerze z teamspeakiem posiada adres ip matki.

 

Rozwiązanie jest w drugim linku. Ale łap tutaj jeszcze dodatkowo:

 

Porty przekierowujesz w csfpre.sh

# These are the forwards for 80 port
iptables -t nat -A PREROUTING -p tcp -s 0/0 -d xx.xx.xx.xx --dport 80 -j DNAT --to     192.168.42.3:80
iptables -t nat -A POSTROUTING -o eth0 -d xx.xx.xx.xx -j SNAT --to-source 192.168.42.3
iptables -A FORWARD -p tcp -s 192.168.42.3 --sport 80 -j ACCEPT

# These are the forwards for bind/dns
iptables -t nat -A PREROUTING -p udp -s 0/0 -d xx.xx.xx.xx --dport 53 -j DNAT --to 192.168.42.3:53
iptables -t nat -A POSTROUTING -o eth0 -d xx.xx.xx.xx -j SNAT --to-source 192.168.42.3
iptables -A FORWARD -p udp -s 192.168.42.3 --sport 53 -j ACCEPT

Abyś miał internet na kontenerze robisz maskarade tak by kontenery miały konkretny adres ip:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to XX.XX.XX.XX

lub dla wybranej podsieci

# iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o eth0 -j SNAT --to-source XX.XX.XX.XX

lub dla wszystkich ale z domyślnym ip matki:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Nie wiem tylko czy MASQUERADE nie psuje adresu ip klienta przy przekierowywaniu portów. Pisał o tym tutaj (link z posta hemi): http://serverfault.com/questions/452183/keep-source-ip-after-nat

 

dodatkowo by internet działał musisz zezwolić na forwarding pomiędzy interfejsem a bridgem:

iptables -A FORWARD -i eth0 -o br-0 -j ACCEPT
iptables -A FORWARD -i br-0 -o eth0 -j ACCEPT

I tyle. XX.XX.XX.XX to twoje publiczne IP z którego mają być przekierowane porty przychodzące, lub w drugiej części adres ip jaki mają mieć kontenery na zewnątrz.

 

Po # są reguły których nie używam.

Edytowano Lipiec 28, 2016 przez Fizyda (zobacz historię edycji)