[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

помогите определится



Hi, All!

Строим локалку с выходом в инет.
Предполагается такая структура сети:

  |          |
  | Internet |
  #=====#====#
        |        #=====#
  #=====#====#   |     |   #==========#
  |          |   |  S  |   |          |
  | Server 1 #---#  w  #---# Server 2 |
  |          |   |  i  |   |          |
  #==========#   |  t  |   #==========#
                 |  c  |
                 |  h  |
                 |     |
                 #==#==#
                    |
              #=====#=====#
              | Local NET |
              |           |

"Server 1" - служит для выхода в инет,
Pentium III, RAM - 256MB (512 in future), HDD - 18GB SCSI.
"Server 2" - разные локальные сервисы (e-mail, DNS, FTP, etc, много игровых
сервисов - со слов начальства: "все, что найдешь"),
2 x Pentium4, RAM - 512MB (1GB in future), HDD - Raid 0 (1?) - 2 x 120GB IDE.
"Switch" - простой, неуправляемый коммутатор.
На серверах будет Debian.
Юзеров - до 300 человек.
Внешний канал - в будущем до 2 Mb/s.
Local NET - 172.16.0.0/16.

К "Server 2" доступ будет для всех юзеров локалки, в т.ч. каждый будет иметь свой почтовый ящик, в качестве SMTP предполагаю использовать postfix. Юзеров
предполагаю заводить виртуальных, базу данных юзеров хранить в mysql. Вот
только не понял, достаточно ли postfix-mysql, или postfix-ldap тоже необходим? Еще один момент, который я не могу уяснить для себя - связь по SMTP со внешним миром: 1) настроить postfix на "Server 1", чтобы он SMTP соединения из инета в
нашу сетку релеил на "Server 2", а запросы от "Server 1" в инет релеил на
сервер провайдера; или 2) сделать "Server 1" прозрачным в плане SMTP с помощью NAT'а, в результате чего все коннекты из инета на SMTP нашей сети буду натится
на "Server 2", а все коннекты от "Server 2" в инет текже будут выходить с
помощью ната. При этом postfix на "Server 1" настроить чтобы он всю локальную
почту отправлял на "Server 2", или просто необходимым демонам (типа cron)
указать, что письма нужно доставлять не локально, а на "Server 2"?
3) установить на "Server 1" что-то типа smtp-proxy.
Какой варант будет лучше?

Что лучше будет использовать в качестве POP3 демона на "Server 2":
qpopper, ipopd, courier-pop, popa3d, dovecot-pop3d, solid-pop3d, teapop или
cucipop? Може у кого есть какие советы, рекомендации, личный опыт?
Сам склюнаяюсь к teapop-mysql - дабы иметь с postfix-ом общую базу юзеров.

Юзера будут получать ip адреса от dhcp3-server на "Server 2" с привязкой к
MAC-адресам.

На "Server 1" для http будет стоять squid, для ftp - frox.
Все остальное будет закрыто, если понадобится что-то, что не умеет ходить
через прокси, но необходимо - будет натится.
Ограничивать выход в инет предполагаю или свойствами прокси-серверов, или
свойствами iptables. Какой вариант будет более предпочтительным в плане
производительности?
Или может стоит заморочится с [ppoe|pptp], [free|gnu]radius, etc. pppd умеет авторизировать юзеров через LDAP? А [free|gnu]radius можно скрестить с LDAP?
Где об этом популярно все написано?

На "Server 2" будет DNS (Bind9) для "Local NET", который должен все запросы на
внешние адреса отдавать на DNS "Server 1" (иле такое поведение не нужно?).
На "Server 1" - на знаю, ставить Bind, или обойтись чисто кеширующим dns'ом
типа rbldns, pdnsd, dnsmasq, totd или какой-то еще?

О разбиении винтов.
"Server 1":
/		 - 100 MB, ext2, ro
/tmp		 - 512MB, ext2, rw
/usr		 - 2GB, ext2, ro
/var		 - 1GB, ext3, rw
/var/tmp	 - 2GB, ext2, rw
/var/lib/frox	 - 2GB, reiserfs, rw
/var/spool/squid - 5GB, reiserfs, rw
swap		 - 512MB

"Server 2":
/		 - 100 MB, ext2, ro
/tmp		 - 1GB, ext2, rw
/usr		 - 3GB, ext2, ro
/usr/games	 - 5GB, ext3, rw
/var		 - 1GB, ext3, rw
/var/tmp	 - 5GB, ext2, rw
/var/lib/mysql	 - 1GB, reiserfs, rw
/var/spool/mail	 - 10GB, reiserfs, rw
/var/spool/news	 - 10GB, reiserfs, rw
/var/ftp	 - 80GB, reiserfs, rw
/var/www	 - 1GB, reiserfs, rw
swap		 - 1GB

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



Reply to: