znaczacy > comp.os.* > comp.os.linux.sieci

Mariusz Koniarz (17.05.2017, 15:58)
Witam.

Taka sytuacja:
4 lacza internetowe, stale publiczne IP, wszystkie z routerami od ISP, wszystkie ustawione z DMZ.

Na testy uruchomilem pfSense w ustawieniu jak na rysunku:


LoadBalancing dziala super, ale nie potrafie w takiej konfiguracji ustawic, aby serwery w LAN (www,poczta,dns,db) byly dostepne z zewnatrz.

Moge zmienic ustawienia LAN na routerach i adres DMZ, ale nie mammozliwosci przekierowania indywidualnie portów.

Moge zmienic wszystko po stronie LAN, zamiast pfSense moze byc cokolwiek linuksopodobne. Komputer od pfSense ma 5 sieciówek, wiec mozliwosci jest sporo, tylko nie potrafie tego poustawiac jak trzeba.

Jakie macie propozycje konfiguracji?
Musi dzialac loadBalancing i serwery powinny byc dostepne z zewnatrz z kazdego publicznego IP.
Piotr Lechowicz (18.05.2017, 16:59)
W dniu 2017-05-17 o 15:58, Mariusz Koniarz pisze:
> Witam.
> Taka sytuacja:
> 4 łącza internetowe, stałe publiczne IP, wszystkie z routerami od ISP, wszystkie ustawione z DMZ.
> Na testy uruchomiłem pfSense w ustawieniu jak na rysunku:
>
> LoadBalancing działa super, ale nie potrafię w takiej konfiguracji ustawić, aby serwery w LAN (www,poczta,dns,db) były dostępne z zewnątrz.
> Mogę zmienić ustawienia LAN na routerach i adres DMZ, ale nie mam możliwości przekierowania indywidualnie portów.
> Mogę zmienić wszystko po stronie LAN, zamiast pfSense może być cokolwiek linuksopodobne. Komputer od pfSense ma 5 sieciówek, więc możliwości jest sporo, tylko nie potrafię tego poustawiać jak trzeba.
> Jakie macie propozycje konfiguracji?
> Musi działać loadBalancing i serwery powinny być dostępne z zewnątrz z każdego publicznego IP.


Jeżeli dobrze zrozumiałem twój opis i schemat, to wszystkie 4 routery ISP robią NAT. Bez przekierowania portów (PAT) na routerach ISP nie widzę możliwości "wystawienia" serwerów na świat.
Ja bym ustawił te routery w tryb bridge tak, żeby mieć publiczne IP na interfejsach tego pfSense/linuxa/whatever. Wtedy w pełni kontrolujesz ruch w obie strony.

Ewentualnie
>> Mogę zmienić ustawienia LAN na routerach i adres DMZ, ale nie mam możliwości przekierowania indywidualnie portów. może na routerach ISP masz opcję typu "virtual server", która cały ruch przychodzący przekierowuje na wskazany adres w LAN (twój DMZ). I wtedy niech pfSense odpowiednio kieruje ruch dalej do LAN w zależności od portu docelowego.


Piotr
Olek (18.05.2017, 20:01)
W dniu 18.05.2017 o 16:59, Piotr Lechowicz pisze:
> Jeżeli dobrze zrozumiałem twój opis i schemat, to wszystkie 4 routery
> ISP robią NAT. Bez przekierowania portów (PAT) na routerach ISP nie
> widzę możliwości "wystawienia" serwerów na świat.


Poniższy opis na rysunku
"all destination DMZ to 192.168.100.1"
sugeruje, że na ruterach ISP jest dobra konfiguracja.
Piotr Lechowicz (19.05.2017, 12:20)
W dniu 2017-05-18 o 20:01, Olek pisze:
> W dniu 18.05.2017 o 16:59, Piotr Lechowicz pisze:
>> Jeżeli dobrze zrozumiałem twój opis i schemat, to wszystkie 4 routery ISP robią NAT. Bez przekierowania portów (PAT) na routerach ISP nie widzę możliwości "wystawienia" serwerów na świat.

> Poniższy opis na rysunku
> "all destination DMZ to 192.168.100.1"
> sugeruje, że na ruterach ISP jest dobra konfiguracja.


Nad tym się zastanawiałem.
Jeżeli router ISP robi dla ruchu przychodzącego z WAN coś w rodzaju "catch all" (opcja "virtual server" z mojego wcześniejszego posta) i pcha wszystko do 192.168.100.1, to na pfSense wystarczyłoby przekierowanie typu

iptables -t nat -A PREROUTING -i ethX_DMZ -p tcp -d 192.168.100.1 --dport 80 -j DNAT --to 192.168.200.6

Więc prawdziwym problemem w takiej sytuacji wydaje się być routing odpowiedzi z serwera 192.168.200.6, którą pfSense wysyła trasą domyślną. Wtedy odpowiedź wychodzi do WAN niekoniecznie tym łączem, z którego przyszło zapytanie, a do tego z innym publicznym adresem źródłowym niż ten, na który przyszło zapytanie.

Jeżeli tak jest, to dostęp do serwera w LAN powinien działać na adresie publicznym jednego z 4 WANów - tego, którym ruch wychodzi domyślnie z pfSense (i przy założeniu oczywiście, że pfSense odpowiednio przekierowuje ruch przychodzący).
Czy OP wykonywał taki test?

Piotr
Olek (20.05.2017, 11:55)
W dniu 19.05.2017 o 12:20, Piotr Lechowicz pisze:
> Więc prawdziwym problemem w takiej sytuacji wydaje się być routing
> odpowiedzi z serwera 192.168.200.6, którą pfSense wysyła trasą domyślną.
> Wtedy odpowiedź wychodzi do WAN niekoniecznie tym łączem, z którego
> przyszło zapytanie, a do tego z innym publicznym adresem źródłowym niż
> ten, na który przyszło zapytanie.


Czyli, w pigułce, trzeba to zrobić tak:
Podobne wątki