znaczacy > comp.os.* > comp.os.bsd

Grzegorz Maśluch (16.06.2005, 13:17)
Cześć.
Właśnie testuję konfigurację jak w temacie.

system: FreeBSD/sparc64 5.4-RELEASE

Konfigurcja PF prawie jak w FAQ:

lan_net = "192.168.20.0/24"
int_if = "fxp1"
ext_if1 = "hme0"
ext_if2 = "fxp0"
ext_gw1 = "192.168.1.1"
ext_gw2 = "192.168.10.1"

# nat outgoing connections on each internet interface
nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

# default deny
block in from any to any
#pass in from any to any
block out from any to any
#pass out from any to any

# pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net
# pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if

# load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin
sticky-address \
proto tcp from $lan_net to any flags S/SA modulate state
# load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin
sticky-address \
proto { udp, icmp } from $lan_net to any keep state

# general "pass out" rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if1 proto { udp, icmp } from any to any keep state
pass out on $ext_if2 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if2 proto { udp, icmp } from any to any keep state

# route packets from any IPs on $ext_if1 to $ext_gw1 and the same for
# $ext_if2 and $ext_gw2
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any

Jedyna różnica w porównaniu z konfiguracją z FAQ to dodane w dwóch
regółkach sticy-address.

Pamiętam, że przy load balancingu ktoś pisał o problemach z połaczeniami
"trzymajcymi sesję", np ftp, https (serwer dostaje pakiety z dwóch
różnych IP i durnieje)i że sticky-address nie rozwiązuje tego problemu.
No więc u mnie rozwiązuje i działa bardzo ładnie (to tak na potrzeby
archiwum).

Mój problem polega na tym, że w przypadku padu któregos z łącz pf nadal
routuje pakiety na oba interfejsy. Przez to mniej więcej połowa połaczeń
nie może być zrealizowana. Zależy mi na tym, aby pad łącza był
niezuważalny dla użytkownika. Myslałem o napisaniu jakiegoś demona albo
skryptu odpalanego z crona, który monitorowałby łączą (np. icmp) i
modyfikował reguły pf'a.

I teraz pytanie: Czy ktoś już robił coś podobnego i może się podzielić
doświadczeniami?
~OutSideR~ (16.06.2005, 21:11)
Witam,

W Twoim poscie datowanym 16 czerwca 2005 (13:17:43) mozna przeczytac:
> Mój problem polega na tym, że w przypadku padu któregos z łącz pf nadal
> routuje pakiety na oba interfejsy. Przez to mniej więcej połowa połaczeń
> nie może być zrealizowana. Zależy mi na tym, aby pad łącza był
> niezuważalny dla użytkownika. Myslałem o napisaniu jakiegoś demona albo
> skryptu odpalanego z crona, który monitorowałby łączą (np. icmp) i
> modyfikował reguły pf'a.
> I teraz pytanie: Czy ktoś już robił coś podobnego i może się podzielić
> doświadczeniami?


Polecam zapoznac sie z:

Pozdrawiam
Stanisław Halik (16.06.2005, 21:47)
~OutSideR~ <newsNoSpaM#outKROPAhome.pl> wrote:

> Polecam zapoznac sie z:


możliwe, że się mylę, ale to nie wygląda na rozwiązanie problemu -- w
protokole CARP routery współdzielą te same adresy IP, wymieniają między sobą
stany połączeń w obrębie tych adresów. nie wygląda mi to na to, by dało się
tym przełączać pomiędzy interfejsami:

,,one interface connects to a hub on the external, Internet side''

jedynym rozwiązaniem, jakie przychodzi mi do głowy jest BGP, ale z
poprzednich postów nie wynika, jakoby zestawienie BGP ze swoim ISP było w
ogóle możliwe.
Grzegorz Maśluch (17.06.2005, 09:23)
Użytkownik ~OutSideR~ napisał:

> Witam,
> W Twoim poscie datowanym 16 czerwca 2005 (13:17:43) mozna przeczytac:
> Polecam zapoznac sie z:


Możesz rozwinąć?
Zapoznałem się z w/w tekstem i nie bardzo widzę związek z moim problemem.
Jacek 'Szumak' Kotlarski (17.06.2005, 10:01)
On Thu, 16 Jun 2005 13:17:43 +0200
Grzegorz Maśluch <prawdziwy> wrote:

> Mój problem polega na tym, że w przypadku padu któregos z łącz pf
> nadal routuje pakiety na oba interfejsy. Przez to mniej więcej połowa
> połaczeń nie może być zrealizowana. Zależy mi na tym, aby pad łącza
> był niezuważalny dla użytkownika. Myslałem o napisaniu jakiegoś
> demona albo skryptu odpalanego z crona, który monitorowałby łączą
> (np. icmp) i modyfikował reguły pf'a.


Inna metoda nie przychodzi mi do głowy, najprościej byłoby zrobić to
pisząc demona monitorującego te łącza (mniejszy czas reakcji). Zastanów
się nad użyciem w PF tablic adresów i sterowaniem ruchu z ich
wykorzystaniem - dynamiczna modyfikacja tych tablic z programu/skryptu
zewnętrznego jest prosta łatwa i przyjemna i nie musisz przeładowywać
zestawu regułek za każdym razem... niemniej jednak konfigurację musisz
dobrze przemyśleć i pewnie się przy niej nagimnastykujesz ;) Trzeba
przemyśleć również jak zrobić monitorowanie padniętego łącza po
przekierowaniu ruchu na drugą bramę.
Piotrek Kapczuk (17.06.2005, 11:21)
In news:d8rne9$j6j$1,
Grzegorz Maśluch <prawdziwy> typed:

> Cześć.
> Właśnie testuję konfigurację jak w temacie.
> system: FreeBSD/sparc64 5.4-RELEASE
>[...]


> Mój problem polega na tym, że w przypadku padu któregos z łącz pf
> nadal routuje pakiety na oba interfejsy. Przez to mniej więcej połowa
> połaczeń nie może być zrealizowana. Zależy mi na tym, aby pad łącza
> był niezuważalny dla użytkownika. Myslałem o napisaniu jakiegoś
> demona albo skryptu odpalanego z crona, który monitorowałby łączą
> (np. icmp) i modyfikował reguły pf'a.
> I teraz pytanie: Czy ktoś już robił coś podobnego i może się podzielić
> doświadczeniami?


Ja na OpenBSD robie failover, ale bez load balancingu. Używam do tego
nagiosa + skrypciki.

Żeby dynamicznie zmieniać konfiguracje PFa, potrzebowałbys zamiast tych
regułek:

# load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin
sticky-address \
proto tcp from $lan_net to any flags S/SA modulate state
# load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin
sticky-address \
proto { udp, icmp } from $lan_net to any keep state

wstawić kotwicę (anchor) w pf.conf. Potem możnaby podmieniać sobie te
regułki skryptem.

Poczytaj najpierw w manach o tych kotwicach.

man pf.conf
man pfctl
~OutSideR~ (17.06.2005, 18:29)
Witam,

W Twoim poscie datowanym 17 czerwca 2005 (09:23:31) mozna przeczytac:
> Możesz rozwinąć?
> Zapoznałem się z w/w tekstem i nie bardzo widzę związek z moim problemem.


Oj - troche opacznie przeczytalem Twoj tekst. Wydawalo mi sie ze mowisz o
padzie jednej z maszynek na ktorym jest cos odpalone, a nie padzie jednego z
lacz. W/w protokol nadaje sie do zastosowania w sytuacji o ktorej myslalem.
Przepraszam za zamieszanie.

Pozdrawiam
Tomasz Piłat (17.06.2005, 20:17)
Grzegorz Maśluch <prawdziwy> wrote:

> Mój problem polega na tym, że w przypadku padu któregos z łącz pf nadal
> routuje pakiety na oba interfejsy. Przez to mniej więcej połowa połaczeń
> nie może być zrealizowana. Zależy mi na tym, aby pad łącza był
> niezuważalny dla użytkownika.


Nie da się. Każde nawiązane połączenie zostanie i tak zerwane (bo zmieni
się adres na który jest robiony NAT).

Czas pomyśleć o adresach PI i BGP.

Ponc
Podobne wątki