IPTables - przekierowanie ruchu z jednego interfejsu na drugi.

[Gość]

Cześć,

Próbuję ukryć swój serwer dedykowany za VPSem z blazingfast, ustawiłem tunelowanie GRE i wszystko działa, maszyny pingują się.

 

Obecnie interfejs "blazing" nie ma wyjścia na świat. Chcę przekierować ruch na kilku portach udp/tcp, np. na port 80 udp/tcp z inferfejsu "blazing" na "eth0" w obie strony, połączenia przychodzące i wychodzące.

 

Czy jest ktoś w stanie mi pomóc? Support blazingfast coś tam wczoraj odpisywał, dzisiaj od 12 godzin zero odzewu... opisywałem problem po angielsku oczywiście. Mints też nie bardzo chcę mi w tym pomóc (tam mam dedyka).

Mam nadzieję że nic nie namieszałem, opisuję ten problem już któryś raz, nie tylko tutaj - nigdzie na razie nie znalazłem pomocy, moje usługi są offline (atak kilka razy dziennie). Tak, wiem że będę musiał zmienić IP dedyka, bo atakujący już go znają.

 

Powoli staje się to co raz bardziej męczące, a ja jestem bezradny, jestem zielony w konfiguracji sieci, iptables to dla mnie czarna magia.

 

Bardzo proszę o pomoc.

 

Jeżeli o czymś zapomniałem to do dopiszę oczywiście

Edytowano Marzec 31, 2016 przez Gość (zobacz historię edycji)

[Fizyda 34]

Nie lepiej przejść na dedyka z anty ddos? Ukrycie go za VPS niewiele Ci da, jak VPS zostanie ubity to usługi też padną, więc korzyści z tego żadnych, a dodatkowo musisz pilnować dwóch serwerów oraz zwiększasz tak naprawdę czas odpowiedzi serwera ze względu na opóźnienia spowodowane przekierowywaniem ruchu przez VPS. Dla niektórych usług będzie miało to znaczenie.

 

Dedyka i tak musisz zmienić, a przynajmniej adres IP. Więc osobiście zmieniłbym firmę hostingową na taką która oferuje anty ddos. Tylko pamiętaj takie zabezpieczenie nie dają 100% pewności że serwer nie padnie. Nie da się w 100% zabezpieczyć przed DDoS, jedyne skuteczne zabezpieczenie to odpięcie wtyczki od internetu, ewentualnie praca tylko w sieci lokalnej w pełni kontrolowanej przez nas.

[Gość]

Nie lepiej przejść na dedyka z anty ddos? Ukrycie go za VPS niewiele Ci da, jak VPS zostanie ubity to usługi też padną, więc korzyści z tego żadnych, a dodatkowo musisz pilnować dwóch serwerów oraz zwiększasz tak naprawdę czas odpowiedzi serwera ze względu na opóźnienia spowodowane przekierowywaniem ruchu przez VPS. Dla niektórych usług będzie miało to znaczenie.

 

Dedyka i tak musisz zmienić, a przynajmniej adres IP. Więc osobiście zmieniłbym firmę hostingową na taką która oferuje anty ddos. Tylko pamiętaj takie zabezpieczenie nie dają 100% pewności że serwer nie padnie. Nie da się w 100% zabezpieczyć przed DDoS, jedyne skuteczne zabezpieczenie to odpięcie wtyczki od internetu, ewentualnie praca tylko w sieci lokalnej w pełni kontrolowanej przez nas.

 

Tak, wiem że opóźnienia będą większe. Na razie nie mogę sobie pozwolić na zmianę hostingu, bo nie mam na to pieniędzy w obecnej chwili. Ze zmianą IP raczej nie powinno być problemu, nawet o tym pisałem wyżej

 

Na razie tymczasowo chcę ustawić to tak jak opisałem w pierwszym poście, w najbliższym czasie pomyślę nad zmianą hostingu.

Edytowano Marzec 31, 2016 przez Gość (zobacz historię edycji)

[SchErk 16]

Jaką uslugę chcesz ochronić?

[Gość]

Jaką uslugę chcesz ochronić?

Serwery gier csgo oraz www (fast download)

[Fizyda 34]

Moim zdaniem serwer cs:go odpada. Tutaj mają znaczenie pingi a wzrosną co najmniej o 50%.

[Gość]

Moim zdaniem serwer cs:go odpada. Tutaj mają znaczenie pingi a wzrosną co najmniej o 50%.

 

Ale ja o tym doskonale wiem... chcę na razie przetestować jak będzie się to zachowywać. Jeżeli pingi bedą w granicach 50-80 to dla mnie nie będzie to problemem, obecnie są na poziomie 20-40.

 

Proszę o nie robienie off topicu, ja naprawdę zdaje sobię sprawę z potencjalnych problemów które może powodować takie ustawienie.

[Fizyda 34]

Na VPS musisz skonfigurować sobie tabele NAT w iptables.

 

Tutaj masz opisany przykład: https://www.debuntu.org/how-to-redirecting-network-traffic-to-a-new-ip-using-iptables/

[Gość]

Na VPS musisz skonfigurować sobie tabele NAT w iptables.

 

Tutaj masz opisany przykład: https://www.debuntu.org/how-to-redirecting-network-traffic-to-a-new-ip-using-iptables/

 

Ustawiłem wszystko zgodnie z poradnikiem z tego linku: http://wiki.buyvm.net/doku.php/gre_tunnel

Z tego co widzę to te poradniki są podobne

VPS:
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p
iptunnel add blazing mode gre local 185.6X.138.2X remote 91.19X.49.17X ttl 255
ip addr add 10.0.1.1/24 dev blazing
ip link set blazing up

Mintshost:
iptunnel add mints mode gre local 91.19X.49.17X remote 185.6X.138.2X ttl 255
ip addr add 10.0.1.2/24 dev mints
ip link set mints up

echo '100 BLAZING' >> /etc/iproute2/rt_tables
ip rule add from 10.0.1.0/24 table BLAZING
ip route add default via 10.0.1.1 table BLAZING

VPS:
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 ! -o eth0 -j SNAT --to-source 185.6X.138.2X

iptables -t nat -A PREROUTING -d 185.6X.138.2X -j DNAT --to-destination 10.0.1.2
iptables -A FORWARD -d 10.0.1.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Gdzie robię błąd? Coś niby załapało, ale dlaczego nie pobiera pliku?

wget http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-CD-7.iso --bind-address=10.0.1.2
--2016-04-01 16:20:59--  http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-CD-7.iso
Translacja cdimage.debian.org (cdimage.debian.org)... 130.239.18.173, 130.239.18.165, 2001:6b0:e:2018::173, ...
Łączenie się z cdimage.debian.org (cdimage.debian.org)|130.239.18.173|:80...

Dodatkowo, mimo dodania tych 3 regułek, pod iptables --list wyświetla się... jedna:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             10.0.1.2             state NEW,RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Próbowałem też takich regułek:

iptables -t nat -A PREROUTING -s 10.0.1.0/24 -j DNAT --to-destination 10.0.1.2
iptables -t nat -A POSTROUTING -j MASQUERADE

Dalej nic..

Edytowano Kwiecień 1, 2016 przez Gość (zobacz historię edycji)

[Gość]

Ustawiłem tak:

 

VPS:

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p
iptunnel add blazing mode gre local 185.6X.138.2X remote 91.19X.49.17X ttl 255
ip addr add 10.0.1.1/24 dev blazing
ip link set blazing up

 

Dedyk:
iptunnel add mints mode gre local 91.19X.49.17X remote 185.6X.138.2X ttl 255
ip addr add 10.0.1.2/24 dev mints
ip link set mints up

echo '100 MINTS' >> /etc/iproute2/rt_tables
ip rule add from 10.0.1.0/24 table MINTS
ip route add default via 10.0.1.1 table MINTS

 

VPS:
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j SNAT --to-source 185.6X.138.2X
iptables -t nat -A PREROUTING -d 185.6X.138.2X -j DNAT --to-destination 10.0.1.2
iptables -A FORWARD -d 10.0.1.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Działa, może to komuś kiedyś pomoże.

Co do pingów przez tunel blazingfast - ja sam na serwerze mam ping w okolicach 70-75, inni podobnie, niektórzy powyżej 100.

[SchErk 16]

Ustawiłem tak:

 

VPS:

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

sysctl -p

iptunnel add blazing mode gre local 185.6X.138.2X remote 91.19X.49.17X ttl 255

ip addr add 10.0.1.1/24 dev blazing

ip link set blazing up

 

Dedyk:

iptunnel add mints mode gre local 91.19X.49.17X remote 185.6X.138.2X ttl 255

ip addr add 10.0.1.2/24 dev mints

ip link set mints up

 

echo '100 MINTS' >> /etc/iproute2/rt_tables

ip rule add from 10.0.1.0/24 table MINTS

ip route add default via 10.0.1.1 table MINTS

 

VPS:

iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j SNAT --to-source 185.6X.138.2X

iptables -t nat -A PREROUTING -d 185.6X.138.2X -j DNAT --to-destination 10.0.1.2

iptables -A FORWARD -d 10.0.1.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

 

Działa, może to komuś kiedyś pomoże.

 

Co do pingów przez tunel blazingfast - ja sam na serwerze mam ping w okolicach 70-75, inni podobnie, niektórzy powyżej 100.

Podziwiam Twoją osobę, gdyż napisałeś rozwiązanie. 3/4 Os9b tak nie robi