pf 2 ipfw

[Андрей]

"Выпускаем локальную сеть в Интернет используя сервер на FreeBSD и NATD"

Раз уж о NATD зашла речь.
Хотел бы узнать насколько хорош NATD?
Что лучше natd или ng_nat?

Я вроде слышал, что natd больше 100 подключений не отрабатывает, а если и отрабатывает, то начинает глючить очень сильно. Правда ли?

Заранее благодарю за ответ.

[root]

Раз уж о NATD зашла речь.

речь о нем не шла, просто в этой статье описан иной метод использования firewall_type вот и все

Хотел бы узнать насколько хорош NATD?

смотря о каком кол-ве мбит для ната идет речь

Что лучше natd или ng_nat?

ng_nat, т.к. ест меньше ресурсов проца для ната

Я вроде слышал, что natd больше 100 подключений не отрабатывает, а если и отрабатывает, то начинает глючить очень сильно. Правда ли?

полный бред
что есть "100 подключений" ? 100 пакетов, которые нужно натить ? 100 клиентов (клиент клиенту рознь)? что то иное ?
хотя не суть, т.к. работоспособность того или иного вида NAT`а измеряется в кол-ве мбит/с и нагрузкой на проц.
natd дает большую нагрузку на проц, например при 200-300 мбит, но будет ли на 100% загружен сервер с natd зависит от того проца что в нем стоит, но он не глючит, просто из-за высокой нагрузки на проц ессно все начинает подтормаживать.
в любом случае можно начать с natd, а когда кол-во мбит для NAT`а будет расти, то будет расти и нагрузка на проц сервера, как только она (нагрузка) перестанет тебя устраивать, то можно заменить natd на ng_nat или даже ipnat.
лично мне больше нравится ng_nat чем ipnat, но это дело вкуса. Но это и не означает что natd я не использую. Я его юзаю в тем местах где трафика не очень много и сервер по процу прекрасно себя чувствует.

[Андрей]

но будет ли на 100% загружен сервер с natd зависит от того проца что в нем стоит

Сервер Dell 2850, 2 CPU по 3ГГц каждый + 4Гб ОЗУ.
Справится на 30 человек по 1 мбит/с и 2х клиентах по 3 мбит/с при условии что ширина канала 60 мбит/с?
Не учитывая меньшие скорости.

[root]

Справится на 30 человек по 1 мбит/с и 2х клиентах по 3 мбит/с при условии что ширина канала 60 мбит/с?

легко справится

[Андрей]

Привет всем.
Тему не стал новую создавать, по этому спрашиваю сдесь.

вопрос у меня следующего характера.
Есть 2 машины с одинаково настроенным pf, но на одной машине при выполнении

Код: Выделить всё

pfctl -t vpn -T delete ip/cidr

vpn прекращает кидать пакеты на "vpn", а на другой, буд-то эти правила не выполняются.

Вот конфиг:

Код: Выделить всё

table <rfcnets> {10.0.0.0/8, !192.168.1.0/24, 192.168.0.0/16, !172.16.0.0/24, 172.16.0.0/12 }
table <vpn>     persist
table <me>      { self, 172.16.0.1}

# Options: tune the behavior of pf, default values are given.
set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 5 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }
set limit { states 50000, frags 5000 }
set loginterface none
#set optimization normal
set block-policy drop
set require-order yes
set fingerprints "/etc/pf.os"
#set state-policy if-bound

# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
scrub in all

nat on em0 from 172.16.0.0/16 to any -> em0

# Разрешаем loopback
pass quick on lo from any to any

# ЗДЕСЬ ОПИСЫВАЕМ ВСЕ IN ПРАВИЛА
#запрещаем локальные сети на внешнем интерфейсе
block in quick on em0 from <rfcnets> to any

# Этот блок правил обеспечивает работу только сервисов на самом сервере
# icmp
#pass in quick inet proto icmp from any to <me> icmp-type echoreq keep state
pass in quick inet proto icmp from any to 10.10.2.2 icmp-type echoreq keep state
# ssh
#pass in quick proto tcp from any to <me> port ssh flags S/SA keep state
pass in quick proto tcp from any to 10.10.2.2 port ssh flags S/SA keep state
# http,https
pass in quick proto tcp from any to 10.10.2.2 port {443, 80} flags S/SA keep state
# dns
pass in quick proto {tcp, udp} from any to <me> port domain flags S/SA keep state
# pptp
pass in quick proto tcp from any to <me> port 1723 flags S/SA keep state
# GRE наружу
pass in quick proto gre from any to <me> keep state
# MPD
pass in quick proto tcp from any to 10.10.2.2 port 5006 flags S/SA keep state

# Все остальное ко мне закрываем
block in quick from any to <me>

block quick from 172.16.0.0/16 to 172.16.0.0/16
# Разрешаем ВПН
pass in quick inet from <vpn> to any
pass in quick inet from any to <vpn>

# остатки входящего блокируем
block in quick all

# ЗДЕСЬ ОПИСЫВАЕМ ВСЕ OUT ПРАВИЛА
# запрещаем RFC сети на исходящем интерфейсе.
block out quick on em0 from <rfcnets> to any

#от меня
pass out quick from <me> to any keep state

# навыход пускаем всё что дошло до сюда
pass out quick from <rfcnets> to <rfcnets>

# и от клиентов
pass out quick from any to <vpn>
pass out quick from <vpn> to any
# Не описанное на выход - блокируем
block out quick all


Так выглядит таблица до удаления ip из таблицы:

Код: Выделить всё

nas# pfctl -t vpn -Ts | grep 10.10.10.99
   10.10.10.99
nas# pfctl -t vpn -Ts | grep 172.16.0.99
   172.16.0.99


После удаления:

Код: Выделить всё

nas# pfctl -t vpn -Ts | grep 10.10.10.99
nas# pfctl -t vpn -Ts | grep 172.16.0.99


Но трафик продолжает идти.

Код: Выделить всё

nas# pfctl -s s | grep 172.16.0.99
all tcp 91.203.99.45:80 <- 172.16.0.99:3372       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:3372 -> xxx.xxx.xxx.251:50703 -> 91.203.99.45:80       ESTABLISHED:ESTABLISHED
all tcp 91.203.99.45:80 <- 172.16.0.99:3374       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:3374 -> xxx.xxx.xxx.251:54822 -> 91.203.99.45:80       ESTABLISHED:ESTABLISHED
all tcp 91.203.99.45:80 <- 172.16.0.99:4404       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:4404 -> xxx.xxx.xxx.251:52846 -> 91.203.99.45:80       ESTABLISHED:ESTABLISHED
all tcp 91.203.99.45:80 <- 172.16.0.99:4408       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:4408 -> xxx.xxx.xxx.251:60220 -> 91.203.99.45:80       ESTABLISHED:ESTABLISHED
all tcp 205.188.8.25:5190 <- 172.16.0.99:4553       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:4553 -> xxx.xxx.xxx.251:59798 -> 205.188.8.25:5190       ESTABLISHED:ESTABLISHED
all tcp 91.203.99.45:80 <- 172.16.0.99:1949       ESTABLISHED:CLOSING
all tcp 172.16.0.99:1949 -> xxx.xxx.xxx.251:58803 -> 91.203.99.45:80       CLOSING:ESTABLISHED
all udp 62.165.32.250:53 <- 172.16.0.99:62070       MULTIPLE:MULTIPLE
all udp 172.16.0.99:62070 -> xxx.xxx.xxx.251:64518 -> 62.165.32.250:53       MULTIPLE:MULTIPLE
all udp 62.165.33.250:53 <- 172.16.0.99:62070       MULTIPLE:MULTIPLE
all udp 172.16.0.99:62070 -> xxx.xxx.xxx.251:60306 -> 62.165.33.250:53       MULTIPLE:MULTIPLE
all tcp 66.102.13.17:80 <- 172.16.0.99:2136       ESTABLISHED:ESTABLISHED
all tcp 172.16.0.99:2136 -> xxx.xxx.xxx.251:53631 -> 66.102.13.17:80       ESTABLISHED:ESTABLISHED

Подскажите, что не так, что не то?
Я перековырял все правила, сравнивал их с исходными и наоборот. Но получаю, что на одной машине оно работает, а на другой нет.

Заранее благодарю за ответ.

[root]

Но трафик продолжает идти.

продолжает он идти или нет тебе 100% покажет tcpdump, я не понимаю почему ты не пользуешся этим инструментом

ESTABLISHED:ESTABLISHED

показвает что соединение уже установлено, кто тебе сказал что timeout уже истек ?
новые соединения появляются ?

[Андрей]

покажет tcpdump

Он и показывает тоже. я и им смотрел.

показвает что соединение уже установлено, кто тебе сказал что timeout уже истек ?

Я же говорю, что конфиг 1 в 1 с рабочего. на нем сразу отсекает.

новые соединения появляются ?

Соединение VPN не падает, а остается. Любой трафик по нему продолжает идти.
В винде новое соединение не устанавливается, пока висит старое.

[Андрей]

Все, решил вопрос.
3 дня не хотел сервер перезапускать. Все таки перезапустил. В итоге все заработало.
Странно почему pfctl -f /etc/pf.conf не помог.
После него пробовал pfctl -d и pfctl -e но тоже без результатов.

[root]

если трафик проходит, значит есть правило под которое он попадает
раз есть правило, то нуна его найти и понять почему трафик под него попадает
чудес не бывает