Укрощение двухголового змия

Andrey Matveev

Хакер, номер #092, стр. 092-110-3

КОД

# vi /etc/nat.conf

192.168.1.2/32

192.168.1.4/32

192.168.1.7/32

Проверяем конфиги на наличие ошибок:

# pfctl -n -f /etc/pf.conf

И активируем набор рулесетов файрвола:

# pfctl -e -f /etc/pf.conf

Поднимаем надежный ретранслятор

Возложив ответственность за разрешение доменных имен на провайдерские DNS-серверы, мы, во-первых, обеспечим избыточность DNS, и, во-вторых, сведем объем внешнего DNS-трафика к минимуму:

КОД

# vi /var/named/etc/named.conf

// Определяем списки управления доступом:

acl clients {

127.0.0.1;

192.168.1/24;

};

// Задаем глобальные параметры конфигурации сервера имен:

options {

version "Stay off my DNS-server";

listen-on { any; };

listen-on-v6 { none; };

allow-transfer { none; };

allow-query { clients; };

allow-recursion { clients; };

// Указываем доступные DNS-серверы основного и резервного провайдеров:

forwarders { 212.34.XX.1; 212.34.XX.39; 81.13.XY.97; };

forward first;

};

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

# rndc reload

Постконфигурационные нотки

Осталось только написать сценарий командного интерпретатора, который будет периодически опрашивать заданные узлы (/sbin/ping -c 2 -w 2 -I <основной IP-адрес> <IP-адрес проверяемого хоста>) и при необходимости изменять дефолтный маршрут (/sbin/route change default <резервный шлюз>). Простейший пример подобного скрипта можно найти на прилагаемом к журналу диске.

Распределение сетевой нагрузки

Достичь максимальной пропускной способности можно двумя способами: настроить трафик-шейпинг (смотри статью «Нарезаем трафик ломтиками» в мартовском «Хакере» за 2006 год) или объединить два доступных канала в один виртуальный, как показано ниже:

// Балансировка исходящего TCP-трафика:

pass in on $int_if route-to \

{ ($ext_if_a $ext_gw_a), ($ext_if_b $ext_gw_b) } round-robin \

inet proto tcp from <users> to any flags S/SA keep state

// Балансировка исходящего UDP- и ICMP-трафика:

pass in on $int_if route-to \

{ ($ext_if_a $ext_gw_a), ($ext_if_b $ext_gw_b) } round-robin \

inet proto { udp, icmp } from <users> to any keep state

Умный форвардинг

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

// Переадресовываем входящие RDP-соединения на IP-адрес 192.168.1.254 и порт 3389:

rdr on $ext_if_a inet proto tcp to port 3389 tag EXT_IF_A -> 192.168.1.254

rdr on $ext_if_b inet proto tcp to port 3389 tag EXT_IF_B -> 192.168.1.254

// Устанавливаем маршрут для ответа на входящие пакеты для переадресованных RDP-запросов:

pass in reply-to ($ext_if_a $ext_gw_a) inet proto tcp flags S/SA \

tagged EXT_IF_A keep state

pass in reply-to ($ext_if_b $ext_gw_b) inet proto tcp flags S/SA \

tagged EXT_IF_B keep state

Тонкости трансляции сетевых адресов

За счет системы NAT пограничный шлюз может выполнять следующие задачи:

* перехват клиентских запросов из доверенной подсети;

* подмена исходного порта и адреса источника своим непривилегированным портом и адресом своего внешнего сетевого интерфейса;