Перенаправление для балансировки нагрузки

                      Перенаправление  основанное  на  балансировке  нагрузки  из  предыдущего   примера работает равно хорошо в режиме NAT, где публичный  адрес это внешний интерфейс

шлюза и перенаправление адресов происходит в частном диапазоне.

Это опредление для webpool:

table <webpool> persist { 192.168.2.7, 192.168.2.8, 192.168.2.9, 192.168.2.10 }

Главное различие между случаем маршрутизируемых адресов и NAT версией это то, что после того, как вы добавили определение для webpool, вы редактируете существующие правила проходят с перенаправлением, которое затем становится этим:

pass in on $ext_if inet proto tcp to $ext_if port $webports rdr-to <webpool> round-robin

Или для версий ранее OpenBSD 4.7 используйте это:

rdr on $ext_if proto tcp to $ext_if port $webports -> <webpool> round-robin

С этого момента ваш NATированный DMZ ведет себя так же, как один с официальными, маршрутизируемыми адресами.

Назад к единой NATированной сети                                        Это  может удивить вас, если вы услышите, что есть случаи, где  настройки  маленькой сети  гораздо  сложней чем  в  большой. Например,  вернемся  в  ситуацию  где  серверы находятся в той же физической сети, что  и клиенты, основываясь на  NATированной конфигурации,  работает  очень  хорошо  до  определенного  момента.  Фактически,  все работает прекрасно до тех пор, пока все в чем вы заинтересованы это получение трафика от хостов вне вашей локальной сети для достижения ваших серверов.

Вот полная конфигурация:

ext_if = "re0" # macro for external interface – use tun0 or pppoe0 for PPPoE int_if = "re1" # macro for internal interface

localnet = $int_if:network

# for ftp-proxy proxy = "127.0.0.1"

icmp_types = "{ echoreq, unreach }"

client_out = "{ ssh, domain, pop3, auth, nntp, http, https, \ 446, cvspserver, 2628, 5999, 8000, 8080 }"

udp_services = "{ domain, ntp }" webserver = "192.168.2.7" webports = "{ http, https }" emailserver = "192.168.2.5"

email = "{ smtp, pop3, imap, imap3, imaps, pop3s }"

# NAT: ext_if IP address could be dynamic, hence ($ext_if) match out on $ext_if from $localnet nat-to ($ext_if)

block all

# for ftp-proxy: Remember to put the following line, uncommented, in your

# /etc/rc.conf.local to enable ftp-proxy:

# ftpproxy_flags="" anchor "ftp-proxy/*"

pass in quick proto tcp to port ftp rdr-to $proxy port 8021 pass out proto tcp from $proxy to port ftp

pass quick inet proto { tcp, udp } to port $udp_services pass proto tcp to port $client_out

# allow out the default range for traceroute(8):

# "base+nhops*nqueries-1" (33434+64*3-1)

pass out on $ext_if inet proto udp to port 33433 >< 33626 keep state

# make sure icmp passes unfettered

pass inet proto icmp icmp-type $icmp_types from $localnet pass inet proto icmp icmp-type $icmp_types to $ext_if

pass in on $ext_if inet proto tcp to $ext_if port $webports rdr-to $webserver pass in on $ext_if inet proto tcp to $ext_if port $email rdr-to $mailserver pass on $int_if inet proto tcp to $webserver port $webports

pass on $int_if inet proto tcp to $mailserver port $email

Последние четыре правила здесь интересуют нас больше всего. Если вы  пытаетесь достичь сервиса на официальном адресе с хостов в вашей сети, вы вскоре увидите, что запросы для перенаправленных сервисов с машин в вашей локальной сети скорей всего не доходят на внешний интерфейс. Это потому,  что все перенаправление и перевод происходят на внешнем интерфейсе. Шлюз получает пакты из вашей локальной сети на внутренний   интерфейс,   с   адресом   назначения   для   внешнего   интерфейса.   Шлюз распознает адрес как один из своих и попытается обработать запрос как если бы он был направлен к локальному сервису, и как следствие, перенаправления совсем не работают с внутренней стороны.

Эквивалентная часть тех последних четырех строк из предыдущего набора правил для версий предшествующих OpenBSD 4.7 систем выглядят так:

rdr on $ext_if proto tcp to $ext_if port $webports -> $webserver rdr on $ext_if proto tcp to $ext_if port  $email -> $emailserver pass proto tcp to $webserver port $webports

pass proto tcp to $emailserver port $email

pass proto tcp from $emailserver to any port smtp

К  счастью,  возможны  несколько  способов  решения  данной  проблемы.   Проблема достаточно  распространена,  в  руководстве  пользователя  PF   перечисляется  четыре различных решения проблемы4, в том числе 4 перемещением ваших серверов в DMZ как описано ранее. Так как это книга о PF, мы сосредоточимся на решении основанном на PF (на самом деле довольно ужасный обход), который заключается в лечении локальной сети как   частный   случай   для   нашего   перенаправления   и   NAT   правил.   Нам   нужно перехватывать  сетевые  пакеты,  проходящие  в  локальную  сеть  и   управлять   этими соединениями правильно, убедившись, что любой обратный трафик направлен к партнеру по соединению и в том, что действительно  возникла связь. Это означает, что для того, чтобы перенаправить для работы как ожидается из локальной сети, нам нужно добавить правила  особого   перенаправления,  которые  отражают  то,  что  предназначено  для обработки     запросов     снаружи.     Во-первых,     вот     разрешающие     правила     с перенаправлениями для OpenBSD 4.7 и более новых версий:

pass in on $ext_if inet proto tcp to $ext_if port $webports rdr-to $webserver pass in on $ext_if inet proto tcp to $ext_if port $email rdr-to $mailserver pass in log on $int_if inet proto tcp from $int_if:network to $ext_if \

port $webports rdr-to $webserver

pass in log on $int_if inet proto tcp from $int_if:network to $ext_if \ port $email rdr-to $mailserver

match out log on $int_if proto tcp from $int_if:network to $webserver \ port $webports nat-to $int_if

pass on $int_if inet proto tcp to $webserver port $webports

match out log on $int_if proto tcp from $int_if:network to $mailserver \ port $email nat-to $int_if

pass on $int_if inet proto tcp to $mailserver port $email

Первые два правила идентичны оригинальным. Следующие два перехвата  трафика из локальной сети и rdr – к действиям в обоих перезаписать адрес назначения, так же как это сделано для соответствующих правил, которые  берут свое начало в другом месте. Разрешающие правила для $int_if   служат  той же цели, что и в предыдущей версии. Совпадают правила с nat как вокруг работающая маршрутизация. Без них, веб-сервер и почтовый сервер маршрутизировали бы обратный трафик, который нужно перенаправлять напрямую к хостам в локальной сети, где трафик мог бы не соответствует  исходящим соединениям. В месте, где nat, серверы рассматривают шлюз в качестве источника

4.Смотрите    «Перенаправление    и    Отражение»    раздел    в    руководстве    пользователя    PF    (http://www.openbsd.org/    faq/pf/rdr.html#reflect)

трафика  и  направят  его  обратно  тем  же  путем,  что  она  пришел  изначально.  Шлюз совпадающий  обратный  трафик  для  состояний  созданных  соединений  от  клиентов  в локальной   сети   и   применяет   соответствующие   меры   для   возвращения   трафика корректным клиентам. Эквивалентные правила для версий предшествующих OpenBSD 4.7, на первый взгляд немного более запутанный, но конечный результат тот же:

rdr on $int_if proto tcp from $localnet to $ext_if port $webports -> $webserver rdr on $int_if proto tcp from $localnet to $ext_if port $email -> $emailserver

no nat on $int_if proto tcp from $int_if to $localnet

nat on $int_if proto tcp from $localnet to $webserver port $webports -> $int_if nat on $int_if proto tcp from $localnet to $emailserver port $email -> $int_if

Таким образом, мы прикручиваем перенаправление и трансляцию адресов, чтобы делать то, что нам нужно, и нам не нужно трогать разрешенный правила вообще. (Я имел счастье наблюдать через электронную почту или IRC реакции нескольких администраторов сети в момент, когда правда около 5 строк реконфигурации затонули.)

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий