Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов. Часть 33 мин для чтения

Настройка Linux GW: настройка консольного дружественного маршрутизатора и настройка статических IP-адресов DHCP

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

 

Перемещение файлов конфигурации DHCP

Поскольку мы хотим сохранить все вместе для удобства администрирования, мы перенесем файлы конфигурации для DHCP в /home/router/dhcp. Изменить сам файл dhcpd.conf легко, просто переместите объявления подсетей и добавьте следующую строку:

include "/home/router/dhcp/subnets.conf";
include "/home/router/dhcp/static_hosts.conf";

 

Как мы делали раньше с bind, нам нужно настроить apparmor. vim /etc/apparmor.d/usr.sbin.dhcpd и добавьте следующие две строки:

/home/router/dhcp/ rw,
/home/router/dhcp/** rw,

 

Перезапустите службу apparmor, затем перезапустите dhcpd. Все должно работать просто отлично.

 

Настройка статических IP-адресов

Помните файл static_hosts, который мы создали ранее? Мы можем использовать его для определения статического IP. Добавьте следующее для установки статического IP-хоста:

host HostName {
hardware ethernet 00:00:00:00:00:00
fixed-address 192.168.25.50;
}

 

После этого просто перезапустите службу DHCP и обновите IP-адрес вашего клиента. Готово, теперь это статично!

Подождите минутку: как вы находите MAC для своего хоста? Нам лень копировать и печатать, поэтому мы сделали следующее:

cd /home/router/dhcp
ln -s /var/lib/dhcp leases

 

Затем вы можете проверить аппаратный адрес в файле leases/dhcpd.leases. Мы создали символическую ссылку, чтобы держать этот каталог под рукой, так как он дает вам статус текущей аренды.

 

Настройка Linux GW: весело с iptables, настройка переадресации портов

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

iptables -t nat -A PREROUTING -i eth0 -p tcp
--dport PORT -j DNAT --to INTERNAL_IP:INTERNAL_PORT
# This rule may not be needed, depending on other chain confings
iptables -A INPUT -i eth0 -p tcp -m state --state NEW
--dport PORT -j DNAT --to INTERNAL_IP:INTERNAL_PORT

 

Этого достаточно, чтобы показать частный сервер всему миру, но это не будет очень полезно при изменении динамического IP-адреса, поэтому вам нужно установить INTERNAL_IP в качестве статического IP-адреса.

Конечно, эти команды немного меньше, чем черная магия. iptables довольно сложен и довольно сложен в освоении, но в качестве краткого описания можно сказать, что он является способом применения набора правил для входящих сетевых пакетов. В iptables у вас есть разные таблицы правил (в этом случае мы используем -t [able] nat) и указываем, что мы хотим, чтобы наше правило применялось на этапе PREROUTING. -i указывает, что это правило должно применяться только к пакетам, поступающим от eth0, а -dport означает, что это правило применяется только к пакетам, поступающим с определенного порта. Конечно, если вы собираетесь указать порт, вам нужно указать протокол (в данном случае, tcp).

Теперь мы повторили в нашей настройке почти все функциональные возможности, которыми обладает небольшой маршрутизатор COTS. В следующий раз мы увидим, как это улучшить, добавив прокси.

 

Предыдущие части:

• Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов. Часть 1
• Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов. Часть 2
• Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов. Часть 4