FreeBSD - Linux - gateway

я бы ни то ни другое. openbsd однозначно. я бы даже думать не стал :)

вот мне везет, правда :P

почему? да потому что есть нормальный пакетный фильтр (Pf), потому
что ты, ставя шлюз, защищаешь внутреннюю сеть, сделовательно сам
шлюз не должен быть узким местом. потому что openbsd имеет самый
надежный tcp/ip стек, потому что openbsd при желании это лучший
шлюз IPsec среди opensource систем. ну и так далее...

если ты не знаком с Pf, убедительно советую познакомится. я например
смотреть не могу на рулезы iptables. они вообще для кого делаются?
для роботов, которым все пофигу или для людей, которые еще должны
разбирать с десяток опций....

вот пример рулесов pf на ближайшей машине с openbsd -- это не шлюз.
так тестовый сервачок с кучей сервисов. это конечно не совсем
нормальный рулсет, а скорее ради тестирования всякого разного, но
достаточно удобный...


# Interface?
#
int = "rl0"

# Serving finger, ftp, http, netbios and irc traffic
#
pub_tcp_serv = "{ finger, http, 6667 }"
file_tcp_serv = "{ 139, ftp, >= 49152 }"
file_udp_serv = "{ 137, 138 }"

# Trusted IPs
#
table <trusted> { 10.32.205.71, 10.32.205.72, 10.32.205.73, \
  10.32.205.74 }

# Don't allow this guys connect to server
#
table <blacklist> persist file "/etc/blacklist"

# Pf options
#
set limit { states 2000, frags 4000 }
set state-policy if-bound
set loginterface none
set block-policy return

# Packet normalisation
#
scrub in on $int all fragment reassemble max-mss 1460 min-ttl 15

# Packet queueing and prioritisation
#
#  Set low priority for file transfers through smb and limit
#  bandwidth to 20Mbit/s. FTP traffic gets 50Mb/s of bandwidth.
#  Yes, you are strongly advised to use FTP ;-)
#
altq on $int cbq bandwidth 50Mb queue { std_q, smb_files, ftp_files }
queue std_q cbq(default)
queue smb_files bandwidth 20% priority 0
queue ftp_files bandwidth 80% cbq(red)


# Block bad guys
#
block return in quick from <blacklist> to any

# Install a ``block all by default'' policy
#
block return log on $int all

# Pass out all traffic
#
pass out on $int proto tcp from any to any flags S/SA keep state
pass out on $int proto udp from any to any keep state
pass out on $int proto icmp from any to any keep state

# Pass in traffic from our network... and queue file transfers ;-)
#
pass in on $int proto tcp from $int:network to any port $pub_tcp_serv \
  flags S/SA keep state queue std_q

pass in on $int proto tcp from $int:network to any port $file_tcp_serv \
  flags S/SA keep state (max 100, source-track rule, max-src-nodes 12) \
  queue ftp_files

pass in on $int proto udp from $int:network to any port $file_udp_serv \
  keep state (max 200, source-track rule, max-src-nodes 20, \
  max-src-states 20, udp.first 45, udp.single 12, udp.multiple 20) \
  queue smb_files

# Pass in all traffic from trusted hosts
#
pass in on $int proto tcp from <trusted> to any flags S/SA keep state
pass in on $int proto udp from <trusted> to any keep state

> #  bandwidth to 20Mbit/s. FTP traffic gets 50Mb/s of bandwidth.

oops, коммент не соответствует действительности, осталься от
предыдущей попытки ;)

я просто сча систему на гейте обновляю... поставил 5.3 фряху - ту, в которую портировали тот самый пф - это действительно рульная вешь /в сочитании с альткью/

> int = "rl0"

это кстати тоже мимо ;)  я копировал просто с html странички с
разъяснениями =)  надо было сразу с pf.conf ;)))

Realtek это отстой. 30% интерраптов... ужас. сейчас гоняю для тестов
vr(4), тот, что VIA Rhine III (D-Link DFE-530TX), но по уму надо fxp =))

написано, что vr это почти Tulip (DEC 21x4x), посмотрим... пока, при
скачке по ftp имею 9-13%... думаю что неплохо, учтя, что fxp давал
около 10-12%...

PS.
раз уж я развел тут оффтопик, то посоветую тем, кто хочет заиметь много
портовый адаптер, карточку D-Link DFE-570TX. она уже не выпускается, и
в Питере ее уже не найти (хотя в Москве еще предлагают...), но это весчь.
4 (и 4 порта, соответственно) нормальных Tulip чипа. но и стоит она дофига
(~$250)..

>надо было сразу с pf.conf ;)))

не обязательно... у меня последнее время man pf.conf как Библия... :)

> 5.3 фряху

не занимайтесь ерундой. она там на уровне OpenBSD 3.5. и будет упдатится
только в 6.0-CURRENT... и уже не поддерживает ре курсивных anchors... :(
к тому же, как выяснилось, там много багов (в порте Pf'а на фрю).

смотрите: http://www.benzedrine.cx/pf/msg05801.html

и подпишитесь на pf лист: http://www.benzedrine.cx/pf/

Наверно, то, что Вам будет проще настроить и что лучше знаете. Насколько я понимаю, отличия будут только в настройке ip-фильтра. Службы то общие. Только поэтому я Linux ставлю.

>там много багов (в порте Pf'а на фрю)

это я заметил :)

я все жду, что вы оцените как я SMB трафик покоцал:

pass in on $int proto udp from $int:network to any port $file_udp_serv \
  keep state (max 200, source-track rule, max-src-nodes 20, \
  max-src-states 20, udp.first 45, udp.single 12, udp.multiple 20) \
  queue smb_files

этож блин на грани с маразмом =)))

>>там много багов (в порте Pf'а на фрю)
>
> это я заметил :)

сейчас самая лучшая ОС (IMO =) это предстоящий snapshot OpenBSD.
ну или следующий за ним =) вообще 3.7 должна быть супер системой =)
недавно туда gcc 3.3 засунули, из-за этого пара портов еще не
собирается...

а вот 3.6 это полное г. :(  ее патчить сильно надо... иногда даже
неоффициальными патчами... я пока все на 3.5-stable держу....

у меня ощущение, что openbsd вообще не везет с четными релизами
почему то.. 3.3, 3.5 не в пример лучше 3.4 и 3.6... хотя раньше
такой тенденции не было... вроде как 3.2 прямее 3.1... но это 
мои такие скромные (очень скромные) наблюдения... ту же 3.4 я
юзал с удовольствием... приперло бы сейчас сервак ставить,
поставил бы и 3.6, только тут сразу нужно -stable...

ну те там кто-то платит из openbsd, наверное... :)

> ну те там кто-то платит из openbsd, наверное... :)

вообще-то это чисто некоммерческая организация ;)
  http://www.openbsd.org/policy.html

так отож... так что фрю, 4-ку. для моих задач вполне хватает. шустро, сухо и комфортно.

кстати, вот dragonfly должна быть более правильной системой,
нежели чем FreeBSD 5.x.... туда и Pf недавно закоммитили...

Ежели ты бздун, то ставь бздю, а если ленуксоед, то ляпикс и это серьезно.

"должна быть" еще не значит, что будет. поглядим :)

Как насчет пробрасывания (маскарадинга) VPN (точнее pptp_nat)?
В линуксе ядро собирать надо и накладывать патчи.

> Как насчет пробрасывания (маскарадинга) VPN

я сам не использую PPTP, но судя по ответам в pf-лист,
нужно nat и rdr для протокола gre. все.

можно посмотреть тут:
http://www.mail-archive.com/pf@benzedrine.cx/msg05207.html

Спасибо буду изучать