Пошаговые инструкции: Собираем свой первый сервер ALT 5.0.

[Tovbor]

Ой примеров там очень много - посмотрите /usr/share/doc/etcnet.../examples

Если Вы имеете ввиду /usr/share/doc/echnet-0.9.10/examples/Complex-without-Qos/iface/office-net..., то там очень замудрено...

[ruslandh]

а зачем вообще вам всё это, если альтератор сам умеет всё настраивать. После его настройки можно и руками подрихтовать то, что вам не нравиться в /etc/net/fw

 /usr/share/doc/echnet-0.9.10/examples/Complex-without-Qos/iface/office-ne.. - это настройка Qos, а не iptables.

смотрите, например
/usr/share/doc/etcnet-0.9.10/examples/firewall-hiddenman/ifaces/default/fw/iptables

[Tovbor]

смотрите, например
/usr/share/doc/etcnet-0.9.10/examples/firewall-hiddenman/ifaces/default/fw/iptables

к сожалению информации там еще меньше.

Больше интересует как правила раскидать по интерфейсам, что бы правила были для каждого интерфейса "свои" и применялись они при поднятии этого интерфейса, как пробрасывать порты "внутрь" локальной сети. Таких примеров в документации нет.

[black_13]

А если тут почитать?
http://ru.wikipedia.org/wiki/Iptables

что бы правила были для каждого интерфейса "свои" и применялись они при поднятии этого интерфейса

Про if-up if-down неслыхивали чтоли?

Таких примеров в документации нет.

Впервые слышу что iptables плохо документирован  :D Что за наглая ложь ?

[ruslandh]

Вот пример правила конкретно для eth0
http://www.altlinux.org/Etcnet/firewall

/etc/net/ifaces/eth0/fw/iptables/filter/FRIEND-NET
policy reject

[greyzy]

Впервые слышу что iptables плохо документирован  :D Что за наглая ложь ?

Человек не про iptables вообще, а как это дело использовать внутри etcnet, там свои хитрости

[ruslandh]

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

Правила для iptables можно писать с помощью синтаксиса, подобного синтаксису ipfw и других. Сделано это с помощью простой замены слов на опции iptables. Сами замены описаны в файле /etc/net/ifaces/default/fw/iptables/syntax (там также описано некоторое количество вспомогательных слов, так что правила можно писать практически на литературном английском :). Синтаксис правила можно совмещать (то есть использовать и заданный в etcnet синтаксис и реальные опции команды iptables)
 Во всех правилах нельзя использовать названия цепочки и/или таблицы; они будут добавляться автоматически
 В правилах можно использовать любые переменные окружения, выполнять любые команды shell (они должны быть указаны в одну строку). Переменная $NAME содержит имя текущего интерфейса. Переменные $IPV4ADDRESS и $IPV6ADDRESS содержат массив IPV4/IPV6 адресов текущего интерфейса (это обычные bash arrays, можно обращаться к ним по индексу: ${IPV4ADDRESS[2]} или просто $IPV4ADDRESS для первого значения). Для удобства можно использовать файлы options, в которых прописывать какие-либо переменные, к примеру, адреса gateway, ISP, сетей и т. д.
 Во всех файлах можно использовать комментарии (строка должна начинаться с символа #)
 Вам не нужно копировать все файлы настроек в каталог каждого интерфейса. Сначала будут считаны настройки виртуального интерфейса default, а уже потом у текущего интерфейса, соответственно, можно переопределять какие-то параметры для определенного интерфейса
 Описания всех правил в настройках виртуального интерфейса default достаточно для поднятия простого сетевого экрана. При наличии же большого количества правил и интерфейсов есть смысл разделить логически все правила по каждому интерфейсу (опять же, не будет нагружаться процессор вхолостую, если интерфейс, к которому относится много правил, сейчас не «поднят»)
 В начале каждого правила можно указать, что с этим правилом делать. Может быть одно из трёх значений:
-A — добавление в конец списка правил (при включенном «читабельном» синтаксисе соответствует команде append)
-I [num] — добавление в начало списка правил; если указан необязательный параметр num, то правило будет вставлено в строку правил с таким номером (будьте внимательны, iptables считает несуществующий номер строки ошибкой и не добавляет правило); (при включенном «читабельном» синтаксисе соответствует команде insert [num])
-D — удаление правила из списка правил (соответственно, при «остановке» интерфейса правило наоборот будет добавлено); (при включенном «читабельном» синтаксисе соответствует команде delete)
 Если никакое действие не указано, то правило добавляются в цепочку в соответствии со значением переменной IPTABLES_RULE_EMBEDDING
 Если вы изменяете какое-то правило в конфигурационных файлах при уже загруженных правилах iptables, то для того, чтобы в памяти не остались старые правила, необходимо или выгрузить все правила для текущего интерфейса (если вы настраиваете для конкретного интерфейса, а не default) перед изменением файлов или после изменения использовать команду efw default restart (она полностью удалит все правила; однако пользовательские цепочки других интерфейсов не будут затронуты) и далее загрузить заново правила для нужного или всех интерфейсов.

ps люди совсем по ссылкам не ходят

[Salomatin]

Первое, уже не понятно, где у вас bind стоит, на гостевом сервере alt4.1 или на алт5.1, потому что пакеты вроде альт5, а инструкция опять же для 4.1.

В данном случае BIND (назовем его  BIND_№_1) устанавливаем на реальном сервере.
Для обозначения использую вывод:

Код: [Выделить]

[root@server ~]#т.е являюсь рутом, на server, в домашней директории, что показывал с самого начала. По этому выводу можно узнать кого администрируешь. Так как консолей обычно открыто много и чтобы не путать.

не понимаю вашу концепцию, но для чего это вообще?

Реальный сервер является маршрутизатором, который подключается к провайдерам, питает виртуальные сервера и локальную сеть, если в последней будут хосты, которые должны получать интернет напрямую.

BIND_№_1 ретранслятор DNS серверов провайдеров. И больше ничего. Для удобства.

Может существовать еще и BIND_№_2. На котором мы можем разместить  primary DNS-сервер, для поддержания нашего домена второго уровня, например, такого как salomatin.ru

BIND_№_2 будет самым авторитетным для  Seconadary DNS -серверов и всего  интернета. Так как только он знает  какой актуальный IP адрес у домена salomatin.ru в настоящее время.
Seconadary DNS -сервера, располагаются далеко за пределами нашей локальной сети и даже нашего провайдера и являются аварийными, на случай временной пропажи из сети   BIND_№_2.
Seconadary DNS -сервера периодически опрашивают primary DNS-сервер, не изменил ли он свои данные. Увидев прежнее цифровое значение, успокаиваются. Если значение увеличено, считывают новые данные и принимают их за объективные.
 
При изменении данных на  BIND_№_2  цифровое значение увеличивают и весь интернет узнает о новом значении IP адреса, для домена salomatin.ru


Может существовать еще и BIND_№_3. Допустим это тот самый LDAP на Альт Линукс 5.0 Ковчег Сервер.

Они могут сосуществовать как отдельно, так и объединены в одном.

Решение принимает администратор.

Предлагается BIND_№_1 разместить на реальном сервере.
Все остальное ниже, на виртуальных.  Если вы хотите поднимать связку ddns+dhcp, там это  лучше и делать.
Фактически  у вас в сети будет не один DNS-сервер. Ваш DHCP-сервер объяснит, кто для хостов назначается главным.   

[greyzy]

В данном случае BIND (назовем его  BIND_№_1) устанавливаем на реальном сервере.
Для обозначения использую вывод:

Код: [Выделить]

[root@server ~]#т.е являюсь рутом, на server, в домашней директории, что показывал с самого начала. По этому выводу можно узнать кого администрируешь. Так как консолей обычно открыто много и чтобы не путать.

Вы для лучшей читабельности указывайте реальный/виртуальный, а то ведь это вы помните, как у вас сервак обзывается, я бы вообще везде # (что команда от рута) ставил и все ;)

Реальный сервер является маршрутизатором, который подключается к провайдерам, питает виртуальные сервера и локальную сеть, если в последней будут хосты, которые должны получать интернет напрямую.

BIND_№_1 ретранслятор DNS серверов провайдеров. И больше ничего. Для удобства.

То есть у вас dns на шлюзе? И он сообщает машинам сети dns провайдера. Вроде понятно

Может существовать еще и BIND_№_2. На котором мы можем разместить  primary DNS-сервер, для поддержания нашего домена второго уровня, например, такого как salomatin.ru

Простите за возможно некоторую зашоренность, просто если есть "фирменная" локалка, в ней желательно иметь dns-сервер, который организовывает домен (локальный). Ваш salomatin.ru это домен, видный из Интернет, то есть дальше вы расскажете о регистрации доменного имени и хостинге на собственном физическом сервере? Я то имел ввиду следующим шагом локальную зону.

BIND_№_2 будет самым авторитетным для  Seconadary DNS -серверов и всего  интернета. Так как только он знает  какой актуальный IP адрес у домена salomatin.ru в настоящее время.
Seconadary DNS -сервера, располагаются далеко за пределами нашей локальной сети и даже нашего провайдера и являются аварийными, на случай временной пропажи из сети   BIND_№_2.
Seconadary DNS -сервера периодически опрашивают primary DNS-сервер, не изменил ли он свои данные. Увидев прежнее цифровое значение, успокаиваются. Если значение увеличено, считывают новые данные и принимают их за объективные.

самый авторитетный звучит как "пива совсем нет"  ;D Вот в локальной и надо авторитетный и secondary настроить

Seconadary DNS -сервера периодически опрашивают primary DNS-сервер, не изменил ли он свои данные. Увидев прежнее цифровое значение, успокаиваются. Если значение увеличено, считывают новые данные и принимают их за объективные.
 
При изменении данных на  BIND_№_2  цифровое значение увеличивают и весь интернет узнает о новом значении IP адреса, для домена salomatin.ru

Ну эт если каждый секондари считал номер версии зоны

Может существовать еще и BIND_№_3. Допустим это тот самый LDAP на Альт Линукс 5.0 Ковчег Сервер.
Они могут сосуществовать как отдельно, так и объединены в одном.
Решение принимает администратор.

Что вы имеете ввиду? Что зона будет в LDAP? И что это за dns? Резервный? Какое от будет иметь отношение к salomatin.ru? "Они могут сосуществовать отдельно, так и объединены в одном" - тут я не успеваю вообще за мыслью кто с кем будет сосуществовать в одном :)

Если вы хотите поднимать связку ddns+dhcp, там это  лучше и делать.
Фактически  у вас в сети будет не один DNS-сервер. Ваш DHCP-сервер объяснит, кто для хостов назначается главным.

Я про это и спрашивал, что мы ретранслируем dns хостам в сети, а хосты непонятно где, все сами по себе или в одной организации, если второй случай, то нужен dhcp, и может даже первее доступа в Инет, ну а заним и ddns

[Salomatin]

На вкус и цвет, все фломастеры разные.
Можно иметь много доменов.ru, быть для кого-то авторитетом, Seconadary.
Поставить внутри сети Альт Линукс 5.0 Ковчег Сервер и там создать домен firma.local
При этом, когда из локалки обратятся на домен.ru , могут попадать на вашу Joomla , по адресу 192.168.0.254. а не через улицу.

Решение принимает администратор.

Не смогу описать все случаи жизни.
Пока предложен BIND_1. Как есть.

[ruslandh]

Выделена тема Ошибка в центре управлеия

[greyzy]

На вкус и цвет, все фломастеры разные.

Не смогу описать все случаи жизни.
Пока предложен BIND_1. Как есть.

Я забыл, какие вы ставили задачи

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

Все, тогда вопрос снимается, просто в локальной сети фирмы имхо желательно иметь dns (для внутренней для локальных компов сети) и опять же чтобы руками не проставлять адреса, то dhcp. У вас пока эта тема не раскрыта

[Salomatin]

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

У вас пока эта тема не раскрыта

Как раз наоборот. Стремился к этому. Считал, что основное уже сделано. Надо подчистить хвосты. Еще 5-6 инструкций и писать будет не о чем.
Что не раскрыто?
Файловый сервер и сервер печати. Там все по инструкциям 4.0. Дойду до них 

Может быть вы имеете в виду:

, просто в локальной сети фирмы имхо желательно иметь dns (для внутренней для локальных компов сети) и опять же чтобы руками не проставлять адреса, то dhcp. У вас пока эта тема не раскрыта

DNS прекрасно работает. 
Так сервер DHCP уже писал как ставить.
http://forum.altlinux.org/index.php/topic,964.msg16575.html#msg16575
Лучше ставить его на виртуальный, можно на реальный.

Вы, наверно, путаете домен.ru и домен виндос. Если вас интересует:

Фишка как раз бы была разобраться с преднастроенным коробочным альтсервером 5.0, с тем самым ldap, с готовыми файлами зоны и т.п.

Так на это уже отвечал.
Это всего лишь одна из задач, которую не брался решать сейчас.

Еще раз про общую концепцию:
 
Берем физический сервер, делаем его продвинутым коммуникатором между интернетом, локальной сетью и виртуальными серверами.

А дальше по принципу игрушки "Лега" - кубики. В Apache их  называют контейнерами. На этом все строится.

Общий сервер вроде работает, хотя его надо еще причесать.  Для наглядности десктопная система наиболее удачная. 

Вопрос в том, какие кубики использовать. Считаю, что на сегодняшний день можно ALT 4.0 сервер и показал как примерно это делать. Количество создаваемых виртуальных серверов ограничивается только здравым смыслом.

Вопрос может быть только то, что есть лучшая платформа для сервера и не хватает кубиков.
Но она для новичка не такая самая дружелюбная.

[Salomatin]

Продолжаем собирать свой первый сервер.

Грош цена нашему надежному шлюз-серверу, если он подключен к одному провайдеру.
Аварию на линии провайдер может устранять неделю.
Нужен второй провайдер. Сразу начинаются вопросы.
А если надо чтобы сервер был виден снаружи сразу по двум адресам? Или белый IP всего один, а второй провайдер дает дешевый доступ по серому адресу.
Все это решается и достаточно просто. 
Рассмотрим  вариант подключения к двум провайдерам, когда у нас есть два белых статических IP - адреса. Остальные варианты, а то: один белый - один серый и тому подобное, будем считать частными случаями первого, где меньше возможностей и, соответственно, настроек.
Аналогично  можно подключить три и более провайдеров.

Шаг № 1: Подключаемся к провайдерам
Подключаемся к провайдерам любым удобным вам способом, используя штатные настройки ALT Linux 5.0.0 Desktop KDE.

Предупреждение: Обязательно переходим на сетевую подсистему etcnet

В ALT Linux 5.0.0 Desktop KDE изначально активизирована NetworkManager.
Заходим: Пуск - Компьютер - Центр управления системой - вводим пароль рута - Ethernet-интерфейсы - Дополнительно - Сетевая подсистема - Etcnet ( для eth0; eth1 и т.д. Для каждого рабочего интерфейса отдельно)

Подключаемся и тестируем соединение по очереди.
Технические условия подключения к провайдеру могут быть различными: PPTP, PPPoE, DHCP -клиент.
В любом случае у вас появятся каталоги либо /etc/net/ifaces/ethN, либо /etc/net/ifaces/pppN
Либо то и другое.

Шаг № 2: Получаем исходные данные подключений
Изучая выводы команд для каждого подключения в отдельности:

Код: [Выделить]

[root@server ~]#ip a s
[root@server ~]#ip r sв некоторых случаях:

Код: [Выделить]

[root@server ~]#cat /etc/net/ifaces/ethN/ipv4address
[root@server ~]#cat /etc/net/ifaces/ethN/resolv.conf
[root@server ~]#cat /etc/resolv.confа также запросив информацию у провайдера, можно узнать основные исходные данные:

Шаг № 3: Само подключение
Для наглядности на примере статического подключения это будет выглядеть так:
eth0 – 81.81.81.81 – оптика  (можно ppp0); 81.81.81.1 – шлюз провайдера оптики
eth1 – 192.168.1.33 – ADSL-модем ; 192.168.1.1 – модем ADSL, все порты проброшены на 192.168.1.33
 
1:  настройки провайдера оптики
file /etc/net/ifaces/eth0/ipv4address 
81.81.81.81/24
#ответ на входящий на eth0 трафик снаружи
file /etc/net/ifaces/eth0/ipv4route 
212.119.96.33 via 81.81.81.1 src 81.81.81.81 #dns-1   
212.119.96.34 via 81.81.81.1 src 81.81.81.81 #dns-2
default via 81.81.81.1 src 81.81.81.81 table optic 
default via 81.81.81.1
#посылаем весь трафик с адреса 81.81.81.81 в таблицу optic
file /etc/net/ifaces/eth0/ipv4rule 
from 81.81.81.81 table optic 
 
2:  настройки провайдера ADSL
file /etc/net/ifaces/eth1/ipv4address 
192.168.1.33
#ответ на входящий на eth1 трафик снаружи
file /etc/net/ifaces/eth1/ipv4route 
195.54.2.1 via 192.168.1.1 src 192.168.1.33 #dns-1   
195.54.2.2 via 192.168.1.1 src 192.168.1.33 #dns-2
default via 192.168.1.1 src 192.168.1.33 table adsl 
#посылаем весь трафик с адреса 192.168.1.33 в таблицу adsl
file /etc/net/ifaces/eth1/ipv4rule 
from 192.168.1.33 table adsl 
 
3: Добавляем 2 таблицы маршрутизации ( adsl optic)
#cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
200 optic
199 adsl
0 unspec
#
# local
#
#1 inr.
 
4:

Код: [Выделить]

#service network restart
Главное достоинство такого подключения:  Сервер виден снаружи по двум адресам одновременно.
Выход изнутри регулируется. В примере по оптике. Обращение к DNS провайдеров по своим каналам.   
 
Динамические подключения

В принципе все тоже самое.
Главные подсказки:
Любой клиент DHCP, PPPoE,  PPTP имеет опцию не получать default и не получать DNS. То есть сервер выдает, но мы можем настроить наш клиент так, что он получит IP- адрес шлюза, но записывать у себя не будет. Также DNS. Если мы их уже знаем, то отключаем, чтобы ничего не путать.
В DHCP file /etc/net/ifaces/ethX/options добавляем строку

Код: [Выделить]

DHCP_ARGS="-G -R"опция -G не получать шлюз, -R  DNS 
В PPPoE,  PPTP file /etc/net/ifaces/pppX/options удаляем строки

Код: [Выделить]

defaultroute
usepeerdns
Файлы регулирующие ответ на входящий трафик просто создаем сами.
/etc/net/ifaces/ethX/ipv4route 
/etc/net/ifaces/ethX/ipv4rule
или
/etc/net/ifaces/pppX/ipv4route 
/etc/net/ifaces/pppX/ipv4rule
и записываем аналогично статического подключения данные провайдера.

Если оба IP адреса белые, то шлюзы всегда одни и те же. DNSы  вообще всегда постоянные.
Все настраивается просто и работает.
 
А если один адрес серый, но шлюз всегда тот же, то тоже нет проблем.

Бывает, когда  провайдер меняет каждый раз адрес шлюза. Тут останется применить такой канал как default, только для получения интернета.

Некоторые команды для  прямого изменения маршрутов:

ip ro del default  # удалить старый default, каким бы он не был.
ip ro add default via 10.0.1.1 # задать ip-адрес шлюза по умолчанию (default gateway)
ip ro del default  via 10.0.1.1 # удалить
ip ro add  192.168.0.0/16 via 192.168.1.1 - добавить статический маршрут в сеть 192.168.0.0/16 через шлюз с ip-адресом 192.168.1.1
ip ro del  192.168.0.0/16 via 192.168.1.1 - удалить этот маршрут
ip ro add  192.168.0.0/16 via 192.168.1.1 src 192.168.1.16 -добавить статический маршрут в сеть 192.168.0.0/16 через шлюз с ip-адресом 192.168.1.1 через сетевой адрес192.168.1.16
ip ro del 192.168.0.0/16 via 192.168.1.1 src 192.168.1.16 - удалить этот маршрут

[greyzy]

Файловый сервер и сервер печати. Там все по инструкциям 4.0. Дойду до них 

Может быть вы имеете в виду:

, просто в локальной сети фирмы имхо желательно иметь dns (для внутренней для локальных компов сети) и опять же чтобы руками не проставлять адреса, то dhcp. У вас пока эта тема не раскрыта

DNS прекрасно работает. 
Так сервер DHCP уже писал как ставить.
http://forum.altlinux.org/index.php/topic,964.msg16575.html#msg16575

Вы, наверно, путаете домен.ru и домен виндос.

Так вы много чего уже писали... Часто получается перепись... Что значит DNS работает? Да я имею ввиду домен windows, и dns в котором есть файл зоны.
отсюда http://ru.wikipedia.org/wiki/Домен_Windows_NT
Домен Windows NT — группа компьютеров одной сети, имеющих единый центр (который называется контроллером домена), использующий единую базу пользователей (то есть учётные записи находятся не на каждом в отдельности компьютере, а на контроллере домена, т.н. сетевой вход в систему), единую групповую и локальную политики, единые параметры безопасности (применимо к томам с файловой системой NTFS), ограничение времени работы учётной записи и прочие параметры, значительно упрощающие работу системного администратора организации, если в ней эксплуатируется большое число компьютеров. Также становится возможным сделать для каждого аккаунта перемещаемый профиль, сетевой путь к которому хранится в одном месте — на контроллере домена. В результате пользователи могут работать со своим «рабочим столом», «моими документами» и прочими индивидуально настраиваемыми элементами с любого компьютера домена.

Или домен для линукс. Внутренний. Я вас уже спрашивал, кто у вас клиенты, винды или линуксы? Вы ответили "Для локальных и сервер, который виден снаружи. Клиенты любые." Получается у вас в сетке типа рабочая группа чтоли? В которой и линуксы и виндовсы? Просто когда запускаешь альтсервер 5.0, то при первом входе в веб-интерфейс просят обозначить имя домена. При этом на сервере создается зона с именем например mydomain.local. Так вот что это за домен такой? Статьи Домен_linux в википедии я не нашел. ruslandh утверждает, что альсервер 5.0 из коробки заточен под клиенты линуксы, то есть по идее если на рабочих станциях (на которых установлен альтинукс_десктоп 5.0) укажу, что машина должна входить в этот самый домен mydomain.local, то будет у меня линуксовый домен, который из внешнего мира не видно, это локальный домен фирмы. Этот домен конфигурируется в bind, и dns конфигурируется как primary. И ваш bind будет легко по запросам компов, входящих в домен mydomain.local резолвить имена. Я про это говорю.
 

Еще раз про общую концепцию:
Берем физический сервер, делаем его продвинутым коммуникатором между интернетом, локальной сетью и виртуальными серверами.

Я бы все равно шлюз делал на отдельной машине