ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘netgraph’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Продолжая тему туннелей привожу ещё один способ поднять туннель между серверами под OS FreeBSD — это netgraph туннели.

Netgraph туннель как и OpenVPN туннель позволяет выбрать порт и протокол по которому будет устанавливаться туннель.

Их основное отличие в том, что netgraph туннель реализован на уровне ядра системы и использует все доступные ядра CPU, а OpenVPN реализован в userland`е и использует только одно ядро CPU.

Задача

Поднять netgraph туннель между двумя FreeBSD серверами и пророутить через туннель некоторые подсети.

Дано

  • Внешний IP-адрес сервера FreeBSD1: 1.1.1.1
  • Внешний IP-адрес сервера FreeBSD2: 2.2.2.2
  • Тунельный IP-адрес сервера FreeBSD1: 10.0.0.1
  • Тунельный IP-адрес сервера FreeBSD2: 10.0.0.2

Настройка

Туннель устанавливается между двумя внешнему IP-адресами по выбранному нами порту 2000 и протоколу UDP,  на туннеле назначаются IP-адреса из серой подсети 10.0.0.0/30.

Я приведу настройку только одной стороны, т.к. вторая сторона это просто зеркальное отражение первой.

Создадим интерфейс ng:
# ngctl mkpeer iface dummy inet

Укажем что будем использовать протокол UDP:
# ngctl mkpeer ng0: ksocket inet inet/dgram/udp

Укажем внешний IP сервера FreeBSD-1 (с которого мы и начали настройку) и зададим порт:
# ngctl msg ng0:inet bind inet/1.1.1.1:2000

Укажем внешний IP сервера FreeBSD-2 и порт, на которой мы и устанавливаем туннель:
ngctl msg ng0:inet connect inet/2.2.2.2:2000

Назначим IP-адреса на сам туннель (созданный интерфейс ng0):
ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252

Теперь можно посмотреть что получилось:

# ifconfig ng0

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc

Туннель с одной стороны готов, настройте зеркально вторую сторону (сервер FreeBSD-2) и вы должны «увидеть» (пинговать) туннельные IP-адреса с обоих сторон.
После чего можно уже роутить что угодно через установленный вами туннель.

Команда для уничтожения netgraph туннеля:

# ngctl shutdown ng0:

Внимание ! Символ двоеточия в конце это не очепятка, как многие думают, он должен там быть.

Для автозапуска туннеля заглянем в предоставленный нам пример /usr/share/examples/netgraph/udp.tunnel и создадим свой стартовый скрипт /usr/local/etc/rc.d/ng_tun_start.sh

#!/bin/sh

case "$1" in
stop)
        if ifconfig ng0 >/dev/null 2>&1; then
                ifconfig ng0 inet down delete >/dev/null 2>&1
                ngctl shutdown ng0:
                echo "tunnel ng0 was destroyed";
        fi
        ;;
start)
        LOC_EXTERIOR_IP=1.1.1.1
        REM_EXTERIOR_IP=2.2.2.2

        LOC_INTERIOR_IP=10.0.0.1
        REM_INTERIOR_IP=10.0.0.2

        UDP_TUNNEL_PORT=2000
        if ifconfig ng0 >/dev/null 2>&1; then
                echo "tunnel ng0 already up";
        else
                ngctl mkpeer iface dummy inet
                ngctl mkpeer ng0: ksocket inet inet/dgram/udp
                ngctl msg ng0:inet bind inet/${LOC_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ngctl msg ng0:inet connect inet/${REM_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ifconfig ng0 ${LOC_INTERIOR_IP} ${REM_INTERIOR_IP} netmask 255.255.255.252
        fi
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        ;;
esac

Теперь при старте сервера туннель будет автоматически создан и у вас есть возможность в ручную стартовать туннель:
# /usr/local/etc/rc.d/ng_tun_start.sh start

или разрушать его:
# /usr/local/etc/rc.d/ng_tun_start.sh stop

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 4,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

По многочисленным наблюдениям системных администраторов различных компаний
предоставляющих доступ к сети интернет, с начала февраля 2010 года наблюдается
ежедневный лавинообразный рост количества пакетов в сети, их фрагментация, а
также существенный рост исходящего трафика. Данная проблема связана с новой
версией торрент-клиента uTorrent вышедшего 3 февраля 2010 года с поддержкой
протокола uTP, работающего поверх UDP. Призванный снизить нагрузку на
провайдеров протокол uTP в результате привел к обратному эффекту.

Для относительно безболезненной для клиента фильтрации uTP на шлюзе под
управлением Linux рекомендуется использовать следующее правило:

/sbin/iptables -I FORWARD -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp \
      --from 40 --to 44 -m statictic --mode random --probability 0.90 -j DROP

Мониторинг работы правила:

iptables -L FORWARD -nv | grep statist

Для FreeBSD правило будет выглядеть следующим образом:

ngctl mkpeer ipfw: bpf 2 main
   ngctl name ipfw:2 utp_filter
   ngctl msg utp_filter: setprogram { thisHook=\"main\" ifMatch=\"\" ifNotMatch=\"main\" bpf_prog_len=12 bpf_prog=[
      { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 }
      { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 }
      { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }

   ipfw add 2 netgraph 2 udp from any to any iplen 0-128

Мониторинг:

ngctl msg utp_filter: getstats \"main\"

Оригинал: http://www.opennet.ru/tips/info/2304.shtml

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

Наткнулся в Инете, возьмем на заметочку. Надо будет как нить попробовать :)

И еще раз переписал firewall …

1. Зачем это надо?
1.1 Уменьшение русрсов процессора, «поедаемого» tasq, поцессом отвечающим за обработку трафика проходящим ч/з интерфейсы em
1.2 Отимизация правил IPFW
1.3 Возможность изменять список безлимитных клиентов без перезагрузки списка правил полностью.
1.4 Снятие ограничений на варианты возможных тарифных планов.
1.5 Устранение задержки при прохождении пакетами через pipe и queue при использовании ipfw.

Извините друзья — спать хочу, комментариев будет мало:
2. Как работает:
2.1 Для каждого абонента должна быть создана отдельная нода в netgraph с заданной пропускной способностью;
2.2 Абоненты «загоняются» в соответствующие ноды, по номерам хуков (tablearg) в таблицах. Последнее возможно без особых трудностей, поскольку ipfw имеет собственную ноду в netgraph.

Пока рассматривается случай только с одним абонентом в таблице — тариф 64Kbit/s.
>cat /etc/rc.firewall
#!/bin/sh
# 1. Global variables
# 1.1 My Interfaces
# 1.1.1 Uplink interface
uif=»fxp1″
unet=»194.128.23.252/30″
uip=»194.128.23.253″

# 1.1.2 Client Interface
cif=»fxp0″
cnet=»172.16.2.252/30″
cip=»172.16.2.253″

# 1.1.3 Contol Interface
mif=»vr0″
mnet=»192.168.23.0/24″
mip=»192.168.23.71″

# 1.2 IPFW executable
fwcmd=’/sbin/ipfw -q’

# 2. Functions (empty by now)
# Suck in tables
if [ -r /etc/rc.firewall.d/unlim64.conf ]; then
. /etc/rc.firewall.d/unlim64.conf
fi

# 3. Default ruleset
# 3.1 Flushing all rules
echo «Flushing all rules.»
${fwcmd} -f flush
${fwcmd} -f pipe flush

# 3.2 Shaper
# 3.2.1 Rules :: Shape IT
# Outgoing traffic — NG_CAR Upstream
${fwcmd} add netgraph tablearg ip from «table(11)» to any out via ${uif}
# Incoming traffic — NG_CAR Downstream
${fwcmd} add netgraph tablearg ip from any to «table(10)» out via ${cif}

>ipfw table 10 list
172.16.2.248/29 14

>ipfw table 11 list
172.16.2.248/29 15

Конфигурируем ноду в netgraph:
>kldload ng_ipfw
>kldload ng_car
>ngctl:
mkpeer ipfw: car 14 upper
name ipfw:14 rate_64
connect rate_64: ipfw: lower 15


Конфигурируем пропускную способность ноды:
# Аналог Cisco Rate-Limit
msg rate_64: setconf { upstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=2 } }

# Аналог Cisco Traffic Shape:
msg rate_64: setconf { upstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=8192 ebs=8192 cir=65536 greenAction=1 yellowAction=1 redAction=2 mode=3 } }

В первом случае:
если полоса не забита:
>ping -s 1472 -i 0.2 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.246/1.340/1.576/0.048 ms


при переполнении полосы:
>ping -s 1472 -i 0.1 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 117 packets received, 41% packet loss
round-trip min/avg/max/stddev = 1.150/1.309/1.495/0.061 ms

То есть как и положено — срезаются пики нагрузки при использовании RateLimit.

Во втором случае:

если полоса не забита:
>ping -s 1472 -i 0.2 -c 200 -S 172.16.2.250 194.128.23.254

200 packets transmitted, 200 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.246/1.340/1.576/0.048 ms


при переполнении полосы:
>ping -s 1472 -i 0.1 -c 200 -S 172.16.2.250 194.128.23.254

PING 194.128.23.254 (194.128.23.254) from 172.16.2.250: 1472 data bytes
1480 bytes from 194.128.23.254: icmp_seq=0 ttl=63 time=1.585 ms
1480 bytes from 194.128.23.254: icmp_seq=1 ttl=63 time=1.247 ms
1480 bytes from 194.128.23.254: icmp_seq=2 ttl=63 time=1.211 ms
1480 bytes from 194.128.23.254: icmp_seq=3 ttl=63 time=1.306 ms
1480 bytes from 194.128.23.254: icmp_seq=4 ttl=63 time=1.269 ms
1480 bytes from 194.128.23.254: icmp_seq=5 ttl=63 time=1.233 ms
1480 bytes from 194.128.23.254: icmp_seq=6 ttl=63 time=1.319 ms
1480 bytes from 194.128.23.254: icmp_seq=7 ttl=63 time=1.289 ms
1480 bytes from 194.128.23.254: icmp_seq=8 ttl=63 time=1.246 ms
1480 bytes from 194.128.23.254: icmp_seq=9 ttl=63 time=1.217 ms
1480 bytes from 194.128.23.254: icmp_seq=10 ttl=63 time=5.671 ms
1480 bytes from 194.128.23.254: icmp_seq=11 ttl=63 time=87.592 ms
1480 bytes from 194.128.23.254: icmp_seq=12 ttl=63 time=170.640 ms
1480 bytes from 194.128.23.254: icmp_seq=13 ttl=63 time=252.565 ms
1480 bytes from 194.128.23.254: icmp_seq=14 ttl=63 time=334.611 ms
1480 bytes from 194.128.23.254: icmp_seq=15 ttl=63 time=416.532 ms
1480 bytes from 194.128.23.254: icmp_seq=16 ttl=63 time=499.581 ms
1480 bytes from 194.128.23.254: icmp_seq=17 ttl=63 time=581.503 ms
1480 bytes from 194.128.23.254: icmp_seq=18 ttl=63 time=663.551 ms
1480 bytes from 194.128.23.254: icmp_seq=19 ttl=63 time=745.473 ms
1480 bytes from 194.128.23.254: icmp_seq=20 ttl=63 time=828.516 ms

То есть как и положено — растет задержка при использовании Traffic Shape.

Как все это автоматизировать — пока понятия не имею, в netgraph не разобрался до конца.

3. Что читать чтобы до конца разобраться:
Про классовые и бесклассовые дисциплины обслуживания очередей.
man 8 ipfw
Все о Netgraph
man 4 netgraph
man 4 ng_ipfw
Cisco — QOS для начинающих
man 4 ng_car
Заголовочные файлы к коду ng_car

Автор: Дмитрий Шевченко

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 5,00 из 5)
Loading...Loading...
Отправить на почту Отправить на почту