forum.lissyara.su

Andy писал(а):

npu3pak писал(а):что то мне этот MicroTikOS напоминает поделку Stonesoft Stonegate - ядро линюкса, фаер ipchains плюс виндовая администрялка к ней = коммерческий продукт с мегалицензиями. Не понравился он мне - консолька привычнее

Там и консолька есть. Что за привычка, хаить не попробовав?

npu3pak писал(а):дык провбовав сэр, сыт по горло и видеть его больше не желаю. Про то что не пробовал - не пишу

npu3pak писал(а):Andy, что именно? переключение каналов? могу порыться в своих архивах - поискать старые конфиги, но скорый результат не гарантирую.
вот одна из ссылок которыми я пользовался когда учился работать с этим счастьем

http://www.dreamcatcher.ru/docs/quagga_rus_cut.html
ну и оргигнал:
http://www.quagga.net/docs/quagga.html

Отказоустойчивость Интернета. Точки над и.
Частенько, на разных форумах посвященных системному администрированию, появляется
вопрос отказоустойчивости соединения с интернетом. Путем коллективного наступания
на грабли по этому вопросу и, как следствие, последующего коллективного изобретения
велосипеда на тему постоянного соединения с Интернетом, хотелось показать возможные
способы решения данной проблемы, а каждый сам выберет тот вариант, который его устраивает.

1. Как правило, первое что приходит в голову, хотя наверное не самое очевидное, это
написание скрипта, который пингует с определенной частотой один канал и, в случае,
отсутствия ответа, переключает сервер на пользование вторым каналом (данный скрипт
выложил o2x на форуме Лиссяры, в разделе "Скрипты написанные на коленке", за что
автору выражается благодарность, я лишь немного подробнее его откомментировал):

Код: Выделить всё

#! /bin/sh
# пути к используемым программам
route="/sbin/route"
ping="/sbin/ping"
natd="/sbin/natd"
sleep="/bin/sleep"
killall="/usr/bin/killall"
touch="/usr/bin/touch"

# внешние сетевые карты
lan_isp1="rl0"
lan_isp2="rl1"

# первый и второй шлюзы
GW1=194.242.118.61
GW2=83.218.237.45

# утилита запускается с ключами "безмолвного" вывода (ключ -q) и отправкой и
# получением двух пакетов (ключ -c 2) на первый шлюз ($GW1), перенаправляя потоки
# stderr и stdout в никуда 

$ping -q -c 2 $GW1 > /dev/null 2>&1

# Если код завершения пинга 1 = error
if [ $? !=0 ]; then
        # пингуем второй канал
        $ping -q -c 2 $GW2 > /dev/null 2>&1
        # если код завершение true =0
        if [ $? =0 ]; then
                # Если файла gw2.changed нет, создаем его.
                # Он определяет переход на основной канал,
                # даже если есть и резервный
                # GW2 будет маршрутом по умолчанию
                if [ ! -f /tmp/gw2.changed ]; then
		# удаляем путь по умолчанию
                $route delete default
		# завершаем работу демона трансляции
                $killall natd
		# добавляем новый путь по умолчанию
                $route add default $GW2
		# создаем файл
                $touch /tmp/gw2.changed
		# ждем 15 секунд
                $sleep 15
		# производим трансляцию адресов на другой интерфейс
                $natd -n ${lan_isp2}
		# запускаем правила файрвола для другого интерфейса
                . /etc/fwrules2.sh
                exit 0;
                fi
        else
                echo "Оба канала не доступны";
                exit 1;
        fi
else
        # Если пинганулся первый шлюз
        # Если файл gw2.changed найден, удаляем его
        # GW1 будет маршрутом по умолчанию
        if [ -f /tmp/gw2.changed ]; then
                $route delete default
                $killall natd
                $route add default $GW1
                $rm /tmp/gw2.changed
                $sleep 15
                $natd -n ${lan_isp1}
                . /etc/fwrules1.sh
                exit 0;
        fi
        echo "Основной канал работает и установлен по умолчанию";
        exit 0;
fi

Как видно, скрипт написан для применения с ipfw. Пользующиеся pf, как я,
придется воспользоваться примерно схожим скриптом, немного видоизмененным,
с учетом той возможности, что pf сам умеет транслировать адреса, в следствии чего остается только остановить файрвол, загрузить другие правила и заново его запустить.

Код: Выделить всё

#! /bin/sh
route="/sbin/route"
ping="/sbin/ping"
pfctl="/sbin/pfctl"
grep="/usr/bin/grep"
awk="/usr/bin/awk"  

GW1=192.168.0.170
GW2=192.168.0.207

$ping -q -c 2 $GW1 > /dev/null 2>&1

if [ $? != 0 ]; then 
  echo "Канал ${GW1} не работает"
    $ping -q -c 2 $GW2 > /dev/null 2>&1
      if [ $? != 0 ]; then 
         echo "Канал ${GW2} тоже не работает."
         exit 1;
      fi     
         $route delete default
         $route add default $GW2 
         $pfctl -f /etc/pf2.conf
         echo "Теперь используется канал ${GW2}"
         exit 0;
else 
         $route -n get default | grep gateway | awk '{print$2}'
          if [ $? != $GW1 ]; then 
           $route delete default
           $route add default $GW1 
           $pfctl -f /etc/pf.conf
           echo "Вернулись на основной канал ${GW1}"
          else 
            echo  "Основной канал работает!"
          fi  

fi

2. Как безскриптовый вариант, можно рассмотреть балансировку нагрузки на оба канала.
Явное достоинтсво этого метода заключается в том, что не приходится следить за
доступностью шлюзов, ибо при отказе какого-то одного из них, полоса пропускания сужается и пакеты начинают уходить через другой шлюз. Разумеется, не стоит забывать
о присвоении конкретному адресу, конкретного гейта (пример ниже для использующих
pf):

Код: Выделить всё

lan_net = "192.168.0.0/24"
int_if  = "fxp0"
ext_if1 = "xl0"
ext_if2 = "fxp1"
ext_gw1 = "212.34.53.105"
ext_gw2 = "81.195.215.53"

#  nat outgoing connections on each internet interface
nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

#  default deny
block in  from any to any
block out from any to any

#  pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net
#  pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if
#  load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
    { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
    proto tcp from $lan_net to any flags S/SA modulate state
#  load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
    { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
    proto { udp, icmp } from $lan_net to any keep state

#  general "pass out" rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if1 proto { udp, icmp } from any to any keep state
pass out on $ext_if2 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if2 proto { udp, icmp } from any to any keep state

#  route packets from any IPs on $ext_if1 to $ext_gw1 and the same for
#  $ext_if2 and $ext_gw2
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any

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

3. Существуют промышленные стандарты для построения отказоустойчивых серверов. Одним из таких является VRRP (Virtual Router Redundancy Protocol), на данный протокол существует RFC (http://www.faqs.org/rfcs/rfc2338.html). Протокол позволяет объединить два компьютера, с разными каналами в интернет в один виртуальный роутер, присваиванием двум компьютерам одного виртуального ip адреса. Один из двух комьютеров назначается Master'ом, а другой - Slave'ом. При отключении Master'а, его обязанности берет на себя Slave, для пользователей все прозрачно, ибо адресом шлюза назначается виртуальный ip. В портах существует утилита freevrrp, реализующая возможность построения отказоустойчивого кластера. Установим ее:

cd /usr/ports/net/freevrrpd/ && make install clean

По умолчанию, freevrrpd читает свой конфигурационный файл по адресу /usr/local/etc/freevrrpd.conf. Создаем конфигурационный файл для master'а и записываем в него следующее:

[VRID]
# определяем идентификатор виртуального роутера 1
serverid = 1
# интерфейс, на который будут отправляться уведомления vrrp
interface = xl0
# приоритет = 255 - это Master
priority = 255
# устанавливаем ip адрес
addr = 192.168.0.248/24
# аутентификация vrrp пакетов.
password = vrid1

На компьютере с другим каналом, создаем slave'а. Кофигурационный файл будет схожим,
с тем отличием, что переменная priority будет выставляться для backup'а.

[VRID]
# определяем идентификатор виртуального роутера 1
serverid = 1
# интерфейс, на который будут отправляться уведомления vrrp
interface = xl0
# приоритет = 255 - это Master
priority = 254
# устанавливаем ip адрес
addr = 192.168.0.248/24
# аутентификация vrrp пакетов.
password = vrid1

Переименуем скрипт запуска frevrrpd:
cp /usr/local/etc/rc.d/freevrrpd.sh.sample /usr/local/etc/rc.d/freevrrpd.sh
Вставим строку запуска freevrrpd в /etc/rc.conf:
freevrrpd_enable="YES"

Перезагрузим компьютер и убедимся в том, что freevrrp демон загрузился:
ps -ax | grep freevrrp

Мы должны получить примерно следующее:
898 ?? Ss 0:00,16 /usr/local/sbin/freevrrpd

В фарволе, необходимо разрешить прохождение пакетов vrrp/carp (номер
протокола 112, согласно /etc/protocols). Далее, на клиентских машинах указываем в качестве шлюза, виртуальный адрес нашего кластера.

Во FreeBSD, начиная с версии 5.24, есть возможность создания отказоустойчивого роутера, благодаря перенесенному с OpenBSD протоколу CARP. CARP является
свободной альтернативой протоколу VRRP, на который Cisco наложила грабли. Вначале,
необходимо создать интерфейс carp.





В процессе подготовки статьи, использовалась следующая литература:

Перевод документации на carp, Михаила Сгибнева - http://dreamcatcher.ru/index.php?option ... 6&Itemid=6

Сайт Евгения Миньковского - http://house.hcn-strela.ru/BSDCert
Раздел документации по VRRP в Mikrotik - http://www.mikrotik.com/testdocs/ros/2.9/ip/vrrp.php
Документация на pf, с сайта OpenBSD - http://www.openbsd.org/faq/pf/filter.html

Andy писал(а): Как видно, скрипт написан для применения с ipfw. Пользующиеся pf, как я,
придется воспользоваться примерно схожим скриптом, немного видоизмененным,
с учетом той возможности, что pf сам умеет транслировать адреса, в следствии чего остается только остановить файрвол, загрузить другие правила и заново его запустить.

paradox писал(а):в линухе там свои методы утилитой

paradox писал(а):а в bsd токо патчами

paradox писал(а):routed это не то как по мне

freeman писал(а):

paradox писал(а):в линухе там свои методы утилитой

название оной в студию можно ?

freeman писал(а):

paradox писал(а):а в bsd токо патчами

Патч или методику настройки роутинга по метрикам простые есть ?

freeman писал(а):

paradox писал(а):routed это не то как по мне

Чем не то ? Идеальный (простой, эффективный, интегрированный в базовую ОС) способ достижения отказоустойчивости путём задания нескольких дефолт гатевеев с различными метриками. Вот только в bsd с этим туго как я понимаю.
А если хочется чего то более крутого то ставим зебру и рулим bgp, ospf, etc.
Ещё вариант CARP in PF.
Вот только для сети с десятком шлюзов и таким же большим кол-вом возможных маршрутов это одно. А для единичного шлюза с двумя интерфейсами смотрящими в инет
Хотя с удовольствием прочитаю, постараюсь поучавствовать в "обкатке" статью для такого примера с применением зебры

zingel писал(а):Зарегистрируй сетку, потом AS, укажи анонсы....