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

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

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

IPIP tunnel Juniper MX480 & M7i Routers + static route via IPIP tunnel interface

Появилась тут задача прокинуть между Juniper MX480 и FreeBSD сервером IPIP туннель и пророутить через него подсеть IP-адресов.

Ось: JUNOS Base OS Software Suite [8.5R3.4]

Как водится начал с чтения документации:

Но как и в предыдущей статье толи я  тупой, толи лыжи не едут, толи они так пишут мануалы  🙁

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

Сначала возник вопрос: «а где взять необходимый интерфейс в джунике ?».

Читаю Tunnel Services Overview:

ipip
Internally generated IP-over-IP interface. This interface is generated by the JUNOS software to handle IP-over-IP encapsulation. It is not a configurable interface.

Смотрю есть ли у меня на джунипере такой. Да  есть, обнаружен интерфейс:

root@juniper> show interfaces ipip

Physical interface: ipip, Enabled, Physical link is Up
Interface index: 11, SNMP ifIndex: 9
Type: IPIP, Link-level type: IP-over-IP, MTU: Unlimited, Speed: Unlimited
Device flags   : Present Running
Interface flags: SNMP-Traps
Input packets : 0
Output packets: 0

Но меня очень напрягают слова «It is not a configurable interface«. Смотрю далее:

ip-0/0/0
Configurable IP-over-IP encapsulation (also called IP tunneling) interface. IP tunneling allows the encapsulation of one IP packet over another IP packet.

Вот это уже ближе, хотя бы указано, что он «Configurable«, но что делать если по show interfaces такого интерфейса нет ??? Блин, приплыли….

Решил попробовать все же отконфигурить интерфейс ipip. Конфигурю его так:
root@juniper# show interfaces ipip

unit 0 {
    tunnel {
        source XX.XX.XX.XX;
        destination YY.YY.YY.YY;
    }
    family inet {
        address 10.255.255.5/30;
    }
}

Где XX.XX.XX.XX это один из внешних IP-адресов джуника, YY.YY.YY.YY внешний IP-адрес FreeBSD сервера, а 10.255.255.5 IP-адрес на туннеле со стороны джунипера.

Коммитим конфигурацию на джунипере и идем на FreeBSD. Конфигуим её:

ifconfig gif0 create mtu 1480 link2 tunnel YY.YY.YY.YY  XX.XX.XX.XX 10.255.255.5 10.255.255.6 netmask 255.255.255.252

С IP-адресами все тоже самое, за исключением того, что ессно они «зеркальные», т.е. идут в другом порядке. 10.255.255.6 IP-адрес на туннеле со стороны FreeBSD.

После этого посмотрим создался ли туннель:
ifconfig gif0

gif0: flags=c051 mtu 1480
        tunnel inet YY.YY.YY.YY --> XX.XX.XX.XX
        inet 10.255.255.6 --> 10.255.255.5 netmask 0xfffffffc

Пробую попинговать с обеих сторон туннельные адреса (10.255.255.X) и результат успешен, с двух сторон пинг ходит.

«УРА !!! Задача решена и так просто !»  — подумал я, но не тут то было…….

Мне же необходимо выполнить вторую часть задачи, а именно пророутить через созданный туннель подсеть  IP-адресов.

Делаю это, добавляю мой статический маршут для подсети, которую я хочу роутить через туннель. Прописываю маршрут в секции routing-options static:

route ZZ.ZZ.ZZ.0/29 {
    next-hop 10.255.255.6;
    retain;
}

коммичу изменения и получаю не совсем ожидаемый результат 🙁

А именно, что с джунипера любой IP-адрес из пророученной подсети пингуется, а вот если пробовать попинговать этот же адрес снаружи, то получаем ответ от джунипера о недоступности сети.

Хм…. что за хрень ? Маршрут для подсети в таблице маршрутизации присутствует и по команде:

root@juniper> show route terse

маршрут виден….. Получается что джунипер отказывается роутить (форвардить) пакеты до этой подсети через себя. Почему ? Потому что ipip «It is not a configurable interface» ?

Лезу в гугл и нахожу похожую проблему: PFE-forwarded IPv6. Не смотря на то, что тут IPv6, а у меня вопрос по IPv4, ответ был найден:

Otherwise the ipip.0 tunnel is only from the RE, which can’t forward transit traffic.

Ну собственно так себя мой джуник и ведет, не форвардит транзитный трафик….

Но я не сдался, лезу снова курить мануалы….. Смотрю в пример «Example: Configuring Unicast Tunnels«:
Configure two unnumbered IP-IP tunnels:

[edit interfaces]
ip-0/3/0 {

    unit 0 {

        tunnel {
            source 192.168.4.18;
            destination 192.168.4.253;
        }

        family inet;
    }

    unit 1 {

        tunnel {
            source 192.168.4.18;
            destination 192.168.4.254;
        }

        family inet;
    }

}

To configure a numbered tunnel interface, include an address under family inet:

[edit interfaces]
ip-0/3/0 {
    unit 0 {
        tunnel {
            source 192.168.4.18;
            destination 192.168.4.253;
        }
        family inet {
            address 10.5.5.1/30;
        }
    }
    unit 1 {
        tunnel {
            source 192.168.4.18;
            destination 192.168.4.254;
        }
        family inet {
            address 10.6.6.100/30;
        }
    }
}

И снова задаюсь вопросом, а откуда они взяли интерфейс ip-0/3/0 ? Почему у них такой интерфейс есть,а у меня нет ! Ведь написано ж, что в MX-серии это встроено:

The MX-series routers support Dense Port Concentrators (DPCs) with built-in Ethernet ports and therefore do not support Tunnel Services PICs. To create tunnel interfaces on an MX-series router, you configure a DPC and the corresponding Packet Forwarding Engine to use for tunneling services at the [edit chassis] hierarchy level. You also configure the amount of bandwidth reserved for tunnel services. The JUNOS software creates tunnel interfaces on the Packet Forwarding Engine. To create tunnel interfaces on MX-series routers, include the following statements at the [edit chassis] hierarchy level

Так, получается, что я должен взять реальный интерфейс и настроить его для работы с tunneling services. Но стоп, у меня нет свободных интерфейсов, все что есть сейчас работают как Ethernet интерфейсы.

Возникает новый резонный вопрос,  а что будет если на отконфигуренном Ethernet интерфейсе добавить настройки и для tunneling services ?

Нашел ответ на этот вопрос вот тут:

The Packet Forwarding Engine of a 10-Gigabit Ethernet 4-port DPC supports either tunnel interfaces or Ethernet interfaces, but not both.

Мда…. опять приплыли… не может интерфейс быть и тунельным и эзернет интерфейсом 🙁

Неужели сделать то что мне надо невозможно если нет свободного физического интерфейса ?

М.б. меня не отпускали слова «встроенный», а м.б. остатки памяти напомнили текст предыдущей статьи, я не знаю, но полез я выполнять команду:

root@juniper> show chassis hardware

...........
FPC 5            REV 08   XXX-XXXXXX   KDXXXX            DPCE 4x 10GE R
...........
PIC 3                   BUILTIN      BUILTIN           1x 10GE(LAN/WAN)

Опа ! А это уже кое что. Встроенный интерфейс fpc 5 pic 3.
Такс… Снова возникает вопрос: «А м.б. именно этот интерфейс и поможет нам создать туннельный интерфейс ?»

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

Для начала сношу все настройки с интерфейса ipip, который я конфигурил выше, затем приступаю к действиям по мануалу:

root@juniper# set chassis fpc 5 pic 3 tunnel-services bandwidth 10g

Получил в конфиге:
root@juniper# show chassis

fpc 5 {
    pic 3 {
        tunnel-services {
            bandwidth 10g;
        }
    }
}
network-services ip;

Так, интерфейс под tunnel services я задал, идем далее.

Попробую создать сам интерфейс:
root@juniper# set interfaces ip-5/3/0 unit 0

Ошибок эта команда не вызвала и интерфейс появился в конфиге. Значит я иду в правильном направлении.

Зададим IP-адреса, по которым и будет строится IPIP туннель:
root@juniper# set interfaces ip-5/3/0 unit 0 tunnel source XX.XX.XX.XX destination YY.YY.YY.YY

Теперь зададим IP-адрес на конце туннеля со стороны джунипера:
root@juniper# set interfaces ip-5/3/0 unit 0 family inet address 10.255.255.5/30

Смотрим что получилось:
root@juniper# show interfaces ip-5/3/0

unit 0 {
    tunnel {
        source XX.XX.XX.XX;
        destination YY.YY.YY.YY;
    }
    family inet {
        address 10.255.255.5/30;
    }
}

Выполняем заветную:
root@juniper# commit check
и получаю радостный для меня ответ:

configuration check succeeds

Ну вот вроде и все. Коммитим изменения и смотрим.

Вот теперь все работает как надо и поставленная задача полностью выполнена:

  • IPIP туннель между  Juniper и FreeBSD создан и работает
  • подсеть IP-адресов статически пророучена через туннель
  • джунипер  форвардит трафик до пророученной статическим маршрутом через IPIP туннель подсети

——

Добавлено 19.04.2011

Потребовалось поднять IPIP туннель, но уже на Juniper M7i .

Ось:  JUNOS Base OS Software Suite [9.4R1.8]

Производим почти аналогичные действия:

root@m7i> show chassis hardware

...........
FPC 1                                                    E-FPC
  PIC 2                   BUILTIN      BUILTIN           1x Tunnel

root@m7i# show interfaces ip-1/2/0

unit 0 {
    tunnel {
        source XX.XX.XX.XX;
        destination YY.YY.YY.YY;
    }
    family inet {
        address 10.255.255.5/30;
    }
}

После commit все завелось, я даже проверил работу BGP по IPIP туннелю — усё арбайтн.

——

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

 

Добавлено 21.07.2011

З.Ы.Ы. Как в последствии выяснилось реальный интефейс все же занимается ( как минимум на MX480) 🙁

Когда я писал статью в том порту, на котором производилась настройка, реального PIC`а (в FPC 5 pic-slot 3) не было, т.е. порт был пуст.

Как выглядел список hardware на MX480 до установки реального PIC`а :

Hardware inventory:
Item             Version  Part number  Serial number     Description
......
  PIC 3                   BUILTIN      BUILTIN           1x 10GE(LAN/WAN)
Fan Tray                                                 Left Fan Tray

# show chassis fpc pic-status

Slot 5   Online       DPCE 4x 10GE R
  PIC 0  Online       1x 10GE(LAN/WAN)
  PIC 1  Online       1x 10GE(LAN/WAN)
  PIC 2  Online       1x 10GE(LAN/WAN)
  PIC 3  Online       1x 10GE(LAN/WAN)

#show chassis pic fpc-slot 5 pic-slot 3

FPC slot 5, PIC slot 3 information:
  Type                             1x 10GE(LAN/WAN)
  State                            Online
  PIC version                  0.0
  Uptime                         196 days, 4 hours, 57 minutes, 6 seconds

Именно столько проработал туннель 🙂
При этом на самом PIC`е линка не было, в списке интерфейсов он не значился, горела только лампочка «tunnel». Иными словами вновь вставленный PIC не работал.

Пришлось сносить все изменения связанные с туннелем и после этого вот что стало видно:
#show chassis hardware

Hardware inventory:
Item             Version  Part number  Serial number     Description
......
  PIC 3                   BUILTIN      BUILTIN           1x 10GE(LAN/WAN)
    Xcvr 0       REV 02   740-014279   T09J61368         XFP-10G-LR
Fan Tray                                                 Left Fan Tray

Интерфейс появился в конфигурации, лампочка «tunnel» погасла и появился линк.

Так что имейте это в виду…

Автор: Николаев Дмитрий (virus (at) subnets.ru)

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

По многочисленным наблюдениям системных администраторов различных компаний
предоставляющих доступ к сети интернет, с начала февраля 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)
Загрузка...
Отправить на почту Отправить на почту

От админа:

Гугля по Инету наткнулся на толковую статью, решил скопировать в блог, дабы сохранить.

ipfw это удобный и гибкий пакетный фильтр, но без внешних средств решение он может принимать только на основе данных в заголовке пакета (ip и udp/tcp). Иногда этого недостаточно и нужно учитывать содержимое пакета. Например у меня возникло желание зафильтровать DNS-запросы MX-записей, которые в большом количестве делают зараженные спамерскими троянами клиентские компьютеры, чем вызывают повышенную загрузку DNS-сервера. В случае если клиентские компьютеры за NAT, почтовых серверов на них быть не должно, и MX-записи им спрашивать не нужно. Правильно ли так делать это отдельный вопрос, здесь будет рассмотрен только технический аспект — как это сделать.

Для решения данной задачи есть как минимум три варианта:
Из ipfw через divert-сокет отправлять пакеты процессу работающему в userspace, который будет слушать divert-сокет и фильтровать приходящие на него пакеты. Главный минус такого варианта — большие накладные расходы и как следствие низкая производительность. Другой минус — этот демон еще нужно написать. Хотя не исключено, что кто то уже написал демон слушающий divert и фильтрующий пакеты через bpf.
ng_bpf — узел Netgraph использующий bpf для фильтрации пакетов
ng_bpf можно подключить непосредственно к ng_ether.
пакеты в ng_bpf можно отправлять из ipfw через ng_ipfw, при выполнении определенного правила через.

Я выбрал последний вариант (ng_ipfw+ng_bpf), несмотря на то, что он несколько сложнее (ниже напишу почему), чем ng_ether+ng_bpf. Во-первых связка ng_ipfw+ng_bpf теоретически должна работать немного быстрее (тесты не проводил), а во вторых из ipfw удобно рулить тем какие пакеты отправлять на дальнейшую обработку в bpf, а какие нет.

bpf

Для начала нужно определиться по какому bpf-выражению будем фильтровать пакеты. Исходная задача звучала так: DNS-запросы (бит QR установлен в 1). Тип запроса — MX. Со вторым сложнее — в одном пакете может быть запрос на несколько записей разных типов, а сами запросы имеют переменную длину, и начинаются со строки заканчивающейся на 0 длина которой не указана в полях. Парсить такой запрос полностью в bpf очень неудобно. Впрочем это и не нужно — запросы посылаемые спамботами содержать запрос только на одну запись типа MX и можно просто заглянуть в конец пакета — там будут поля Type (MX — 0x000f)и Class (IN — 0×0001). Если это проверять, то под правило будут подпадать любые пакеты у которых в конце запрос на MX-запись.

При составлении выражения удобно пользоваться описанием формата пакетов с сайта networksorcery.com 1).

udp[10] & 0×80 = 0 - проверяем, что 1-й бит, байта со смещением 102) выставлен в 1, т. е. то, что это запрос, а не ответ.
udp[udp[4:2]-4 : 4] = 0x000f0001 - последние 4 байта UDP пакета 0x000f0001. udp[4:2] это длинна UDP пакета в байтах (вместе с заголовком).

В результате получается выражение:

udp dst port 53 and udp[10] & 0x80 = 0 and udp[udp[4:2]-4 : 4] = 0x000f0001

Но для ng_bpf нужно не выражение, а bpf-программа — набор низкоуровневых инструкций, которые нужно выполнить для проверки пакета. Чем то напоминает упрощенный и усеченный ассемблер.

В какие инструкции нужно преобразовать выражение зависит от того, что подается на вход bpf-фильтра — IP пакеты (начиная с заголовка IP-пакета без каких либо дополнительных заголовков), ethernet-фреймы (т. е. заголовок канального уровня и далее IP пакет) или пакет какого либо другого канального уровня.

В случае если ng_bpf подключен к ng_ether на его вход подаются ethernet фреймы, и для получения bpf-кода можно воспользоваться способом описанным в man ng_bpf — tcpdump -ddd и последующее приведении в формат который нужен для netgraph с помощью awk.

В случае подключения ng_bpf к ng_ipfw на вход подаются IP пакеты и такой способ не подойдет — в начале будет пара команд проверяющих поле в заголовке ethernet-фрейма которого в нашем случае нету, а в последующих командах будет использовано смещение на 14 байт больше чем нужно.

Поэтому есть два способа — составить программу руками заглядывая в man bpf и /usr/include/net/bpf.h (за основу можно взять вывод tcpdump -ddd, но с нуля написать не сложнее чем вручную дизассемблировать вывод tcpdump -ddd, изменить и потом снова перевести это в bpf-код). Это процесс сильно напоминает программирование на ассемблере с последующим переводом этого в машинные коды.

Или можно написать небольшую программку для компиляции выражения в bpf-код проверки IP пакетов (в libpcap это тип DLT_RAW, т. е. “сырой” IP пакет без каких либо дополнительных заголовков).

Cначала я составил bpf-код вручную, потом решил, что такой способ хорошо только в учебных целях, поскольку отнимает много времени и для повседневной работы не годится.

Потом написал маленькую программку которая это делает используя libpcap:

/*
 * to compile type:
 * gcc -lpcap bpf_comp.c -o bpf_comp
 */

#include <err.h>
#include <pcap.h>
#include <stdio.h>
#include <sysexits.h>

int main(int argc, char *argv[])

{
        struct bpf_program bp;
        unsigned int i;

        if (argc != 2)
                errx(EX_USAGE, "Usage %s 'filter expression'", argv[0]);

        if(pcap_compile_nopcap(65535, DLT_RAW, &bp, argv[1], 1, 0)) {
                errx(EX_USAGE, "filter syntax error");
        }

        printf("bpf_prog_len=%d bpf_prog=[ ", bp.bf_len);

        for (i = 0; i < bp.bf_len; i ++) {
                printf("{ code=%d jt=%d jf=%d k=%d } ",
                        bp.bf_insns[i].code, bp.bf_insns[i].jt, bp.bf_insns[i].jf, bp.bf_insns[i].k);
        }

        printf("]\n");

        exit(0);
}

Для тестирования этой программы можно посмотреть bpf-программу для фильтрации udp пакетов:

:~> ./bpf_comp udp
bpf_prog_len=5 bpf_prog=[ { code=0 jt=0 jf=0 k=0 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=1 k=17 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ]

Если у Вас получится программа, не 5 команд (bpf_prog_len=5), а 7, значит libpcap собран с поддержкой IPv6 которая пока реализована не очень хорошо. В результате для DLT_RAW создается фильтрующий код, который кроме интересующих нас пакетов может поймать и лишние (это происходит в libpcap до версии 0.9.5 включительно, а в 0.9.6 это должно быть исправлено, но в любом случае если в сети используется только IPv4, то лучше собирать libpcap без поддержки IPv6, чтобы bpf-программа была короче и быстрее). Поэтому если у вас получилось 7 команд для udp, рекомендую пересобрать без поддержки IPv6:

echo 'NO_INET6=true' >> /etc/make.conf
cd /usr/src/lib/libpcap/
make clean
make
make install

Для интересующего нас выражения получается такая bpf-программа:

:~> ./bpf_comp 'udp dst port 53 and udp[10] & 0x80 = 0 and udp[udp[4:2]-4 : 4] = 0x000f0001'
bpf_prog_len=18 bpf_prog=[ { code=0 jt=0 jf=0 k=0 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=14 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=12 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=72 jt=0 jf=0 k=2 } { code=21 jt=0 jf=9 k=53 } { code=80 jt=0 jf=0 k=10 } { code=69 jt=7 jf=0 k=128 } { code=72 jt=0 jf=0 k=4 } { code=20 jt=0 jf=0 k=4 } { code=12 jt=0 jf=0 k=0 } { code=7 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=0 } { code=21 jt=0 jf=1 k=983041 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ]

(первая команда в данном случае лишняя и её можно выкинуть, но можно ли это делать зависит от того какая команда стоит за ней, в общем случае проще оставлять программу как есть).

Netgraph

Для использования узлов типа ng_bpf и ng_ipfw нужно загрузить соответствующие модули (если они не были включены в ядро):

:~# kldload ng_ipfw
:~# kldload ng_bpf

Чтобы после перезагрузки они загружались автоматически нужно добавить в /boot/loader.conf:

ng_ipfw_load="YES"
ng_bpf_load="YES"

При загрузке модуля ng_ipfw автоматически создается одни узел с именем ipfw (дополнительные узлы типа ipfw создавать нельзя). Создаем узел типа bpf и подключаем его к ipfw:

:~# ngctl mkpeer ipfw: bpf 1 main

Задаем созданному узлу имя:

~# ngctl name ipfw:1 dns_mx_q_filter

Конфигурируем его:

:~# ngctl msg dns_mx_q_filter: setprogram { thisHook="main" ifMatch="" ifNotMatch="main" bpf_prog_len=17 bpf_prog=[ { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=14 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=12 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=72 jt=0 jf=0 k=2 } { code=21 jt=0 jf=9 k=53 } { code=80 jt=0 jf=0 k=10 } { code=69 jt=7 jf=0 k=128 } { code=72 jt=0 jf=0 k=4 } { code=20 jt=0 jf=0 k=4 } { code=12 jt=0 jf=0 k=0 } { code=7 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=0 } { code=21 jt=0 jf=1 k=983041 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }

thisHook — хук, входящие пакеты с которого будут фильтроваться заданной программой. ifMatch — хук куда будут отправляться пакеты для которых выполнено условия фильтра. Если задать пустым, то пакеты будут отбрасываться (что в данном случае и требовалось — фильтровать определенные пакеты). ifNotMatch — все остальные пакеты отправляем обратно в ipfw3)

Можно посмотреть, что программа действительно задана:

:~# ngctl msg dns_mx_q_filter: getprogram "main"

Теперь осталось интересующие нас пакеты отправить из ipfw через хук с именем 1 в netgraph. Т. к. к хуку с именем 1 подключен узел типа ng_bpf, то пакеты попадут к нему:

:~# ipfw add 123 netgraph 1 udp from 192.168.0.0/16 to me 53

Для просмотра статистики есть сообщение getstats:

:~# ngctl msg dns_mx_q_filter: getstats "main"
Rec'd response "getstats" (3) from "[4fa]:":
Args:   { recvFrames=16333 recvOctets=977179 recvMatchFrames=9133 recvMatchOctets=512317 xmitFrames=7200 xmitOctets=464862 }

Из 16333 пакетов отправленных правилом ipfw в ng_bpf, 9133 пакетов были запросами на mx-записи.

Для конфигурации ng_ipfw+ng_bpf при загрузке можно положить скрипт в /usr/local/etc/rc.d/ (расширение .sh нужно только во FreeBSD 4, 5. Для 6-ки его лучше убрать).

комментарии по поводу этой заметки можно писать в ЖЖ

1) первоисточник этой информации RFC, но в RFC эта информация представлена не так наглядно и удобно
2) 8 байт, заголовок UDP и 2 байта идентификатор DNS запроса
3) что с ними будет дальше зависит от значения sysctl net.inet.ip.fw.one_pass — либо будет разрешен, либо продолжится проверка следующих правил

Автор: Антон Южанинов, Оригинал: http://citrin.ru/freebsd:ng_ipfw_ng_bpf

От админа:

таким же способом можно отфильтровывать uTP (torrent), пакеты можно увидеть выполнив:

tcpdump -ni IFACE_NAME -n "ip[40:4]=0x7FFFFFFF"

Еще полезные ссылки по теме:

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

Засада

Столкнулись тут с засадой на одном из серверов.

В сервер вставили дуальную карту Intel Gigabit ET Dual Port Server Adapter, сервер работает шлюзом.

pciconf -lv

igb0@pci0:4:0:0: card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
vendor = ‘Intel Corporation’
class = network
subclass = ethernet
igb1@pci0:4:0:1: card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
vendor = ‘Intel Corporation’
class = network
subclass = ethernet

Что получили ? А получили вместо ожидаемого улучшения, т.к. встроенные карточки похуже будут, тотальное ухудшение.

Если качать с самого сервера, то закачка идет в полную скорость канала (т.е. можно и более 20 МБ/с выжать),

а вот если качать как клиент (через этот сервер), то скорость закачки 50 килобайт и выше ну никак не идет :(((((

Пробовали драйвера и самой FreeBSD 7.2 так и дрова от Yandex, так и дрова с официального сайта Intel.

Но ситуация не изменялась ни на грамм………

Чего мы тока не делали…… даже бубном стучали админским 🙂 ничего не помогало, даже накатили сервер до  FreeBSD 7.3 PRERELEASE — результат тот же.

Трындец подумали мы……. но:

Сами понимаете, гуглили мы изрядно и вот появился луч надежды, наткнулись на описание той же проблемы на lists.freebsd.org, которая датируется аж:

Mon Jun 8 10:53:08 UTC 2009

Где человек пишет, что ему помогло. А именно:

в /etc/sysctl.conf пишем:

dev.igb.0.enable_lro=0
dev.igb.1.enable_lro=0
dev.igb.0.rx_processing_limit=2048
dev.igb.1.rx_processing_limit=2048

Затем перегружаем сервер, а не правим это налету через sysctl, а иначе не заработает, у нас не заработало, как чел и писал.

И вауля ! Сервер возвращается из ребута и наконец то  все становится как надо ! А именно получаем нормальную скорость через него как клиент.

Если по команде:

sysctl dev.igb.0.enable_lro=0
Вылезает:

sysctl: unknown oid ‘dev.igb.0.enable_lro’

Тогда попробуйте так:

ifconfig igb0 -lro

Итог:

  1. Драйвера с сайта Intel
  2. правка переменных sysctl

Ссылки:

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

Авторы: Панфилов Алексей (lehis (at) subnets.ru), Николаев Дмитрий (virus (at) subnets.ru), Будимиров Максим (madmax (at) subnets.ru)

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

От админа:
В продолжение статьи «Теория и настройка DNS сервера (bind) на FreeBSD» один из наших блогеров (vasily86) написал следующую статью, которую и представляю вам с некоторыми моими дополнениями.

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

Примеры:

  • .ru
  • .com
  • .edu

Полный список доменов первого уровня я видел здесь.

Чтобы зарегистрировать там свой домен второго уровня нужно заплатить небольшую денежку (например регистратору www.nic.ru) и вам, при условии незанятости, предоставят его, к примеру yandex.ru.

Домены первых уровней принадлежат организации ICANN, которая и следит за ними.
Наша цель — создать домен первого уровня в нашей локальной сети и заодно настроить DNS сервер.
Итак приступаем! Создадим корневую зону «.vrn«.

В системах UNIX самым популярным DNS сервером является named (bind).

За его функционирование отвечает файл named.conf, который расположен в папке /var/named/etc/namedb (или символическая ссылка /etc/namedb).

options {
         directory       "/etc/namedb";
         pid-file        "/var/run/named/pid";
         dump-file       "/var/dump/named_dump.db";
         statistics-file "/var/stats/named.stats";
         forwarders {
                    195.98.64.65;
                    195.98.64.66;
                    };
         listen-on  {
                    192.168.0.101;
                    127.0.0.1;
                    };
};

zone "." {
         type hint;
         file "named.root";
};

zone "vrn" {
         type master;
         file "vrn.zone";
};

zone "0.168.192.in-addr.arpa" {
         type master;
         file "vrn-reverse.zone";
};

В разделе options основные настроики программы,  здесь нужно изменить ip напротив forwarders вписываем DNS провайдера и listen-on — сюда ip, которые необходимо слушать.

От админа:

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

Далее описываем файлы зон:

Самая главная зона — это зона точка (.) ,  данный файл уже создан и менять его нет необходимости.

А вот следующую зону мы создаём для локальной сети, здесь она называется vrn и описана она в файле vrn.zone ниже:

$TTL 86400
vrn.    IN      SOA     ns1.vrn. n2.vrn. (
                        2009121101
                        86400
                        7200
                        8640000
                        86400 )
        IN      NS      ns1.vrn.

ns1     IN      A       192.168.0.101
ns2     IN      A       192.168.0.101

server  IN      A       192.168.0.101
kil     IN      A       192.168.0.100
roma    IN      A       192.168.0.114
nikita  IN      A       192.168.0.109
katya   IN      A       192.168.0.90
pasha   IN      A       192.168.0.10
dima    IN      A       192.168.0.50

Здесь идёт перечисление соответствия имени и ip.

На этом конфигурирование можно закончить, но для того чтобы задать обратное соответствие мы создали ещё одну зону 0.168.192.in-addr.arpa (т.е. ip следует потом вычислять в обратном направлении 192.168.0.      и последнее число прописывается в файле зоны с именем домена)

От админа:

Подробнее можно прочитать в статье: Записи типа «Pointer». Домен IN-ADDR.ARPA. Делегирование «обратных» зон. Инверсные запросы.

$TTL    3600

@       IN      SOA     ns1.vrn. ns2.vrn. (
                        2009121102
                        3600
                        900
                        3600000
                        3600 )
        IN      NS      ns1.vrn.
        IN      NS      ns2.vrn.

10      IN      PTR     pasha.vrn.
50      IN      PTR     dima.vrn.
90      IN      PTR     katya.vrn.
101     IN      PTR     server.vrn.
100     IN      PTR     kil.vrn.
109     IN      PTR     nikita.vrn.
114     IN      PTR     roma.vrn.

Обратите внимание на имена доменов с точкой!!! roma.vrn. иначе ничего не сработает.

Теперь осталось сохраниться. И пробуем запустить named

/etc/rc.d/named onestart

если на консоли не выпали ошибки, значит всё нормально, исправляем файл /etc/resolv.conf

domain vrn
nameserver 192.168.0.101

где 192.168.0.101 — это ip данной машины. И протестируем командами

ping yandex.ru

ping server.vrn

Если пинг прошёл успешно, то добавим наш named в автозагрузку /etc/rc.conf

named_enable=»YES»

и настроем DNS(указав ip данного сервера) у машин, которые находятся в локальной сети. =)

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

Автор: vasily86

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