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

Архивные статьи в категории ‘FreeBSD’

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

ЗАМЕТКА

В рамках поднятия IPTV в сети столкнулись с приставкой D-Link DIB-120.

Симптомы

Приставка D-Link DIB-120 при загрузке показывает логотип Alpha и потом черный экран и больше ничего.

Выяснилось

Компания Dlink завезла в Россию партию DIB-120, залитых безбраузерной прошивкой.
Отличить такую приставку можно по ее серийному номеру. Он начинается с Р1Т818.
В приставке прошит статический IP-адрес 192.168.1.1 и она слушает мультикаст группу с адреса 239.60.8.1:37732

Решение проблемы

Существуют два способа решения проблемы:

1. Если у вас есть сервер с OS Linux, то можно запустить вещание файла прошивки на  мультикаст адрес 239.60.8.1:37732 с помощью проги amfus.

Положите файлы прошивки и amfus в одну папку, затем создайте в этой же папке конфиг:

DIB120.conf:

a0_rootfs a-fs-cramfs.img V4.03.009 14299136 e6d0e447beed049bb2d41798721f29d7
kernel vmlinuz-7402c0 V4.03.009 1602656 7cc07013cc6ff0ea8f078920175791c1

Затем запустите:

./amfus -d DIB120.conf -m 239.60.8.1:37732 -i 1000 -t 32

2. Можно закачать прошивку с помощью HTTP сервера.  Как это сделать было описано в этой статье, процитирую ее:

По умолчанию IP STB D-Link DIB-120 поставляется без прошивки (при загрузке отображается ALPHA и черный экран).

На форумах говорят, что это «бракованная» партия, а на самом деле это «чистый» аппарат без странички.

Чтобы исправить это можно загрузить в него следующую прошивку 4.04.013_multicast.rar (доступна обновленная прошивка для DIB-120 от 6.11.09 4.05.004_multicast.rar).

Для перепрошивки понадобиться любой WEB сервер (например Apache).

В корневую директорию сервера необходимо сохранить два файла, которые находятся в архиве (a-fs-cramfs.img и vmlinuz-7402c0).

В качестве примера установлен IP сервера (компьютера с установленным Apache) – 192.168.1.2.

Устройство по умолчанию имеет IP 192.168.1.1, для этого в командной строке нужно выполнить команду telnet 192.168.1.1 на запрос имени пользователя необходимо указать root, а пароль пустой.

В командной строке DIB-120 нужно выполнить следующие команды:

cd /tmp

wget http://192.168.1.2/vmlinuz-7402c0
eraseall /dev/mtd2 ; dd if=vmlinuz-7402c0 of=/dev/mtd2

wget http://192.168.1.2/a-fs-cramfs.img
eraseall /dev/mtd0 ; dd if=a-fs-cramfs.img of=/dev/mtd0

reboot

Внимание! После перезагрузки пароль root’a будет изменен (см. файл password.txt в архиве), пароль можно изменить выполнив команду passwd

Оригинал статьи тут: http://cworld.org.ua/2009/09/16/firmware-d-link-dib-120/

Большое спасибо Hades за данную публикацию,  а то у меня FreeBSD и я уже чуть было не озадачился поднятием эмулятора Linux 🙂

Сделал все как описано в статье, за исключением того, что поднял не Apache, а по быстрому поставил  nginx (/usr/ports/www/nginx).

Все получилось, после прошивки и ребута приставка начала стучаться по DHCP и успешно получила от моего сервера DHCP IP-адрес.

Вот конфиг  nginx.conf:

user   www www;
worker_processes  1;

error_log  logs/error.log;
pid         /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       192.168.1.2:80;
        server_name  localhost;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

Вот пример вывода с приставки при перепрошивке:

# cd /tmp
# wget http://192.168.1.2/vmlinuz-7402c0
Connecting to 192.168.1.2[192.168.1.2]:80
vmlinuz-7402c0 100% |*****************************| 1565 KB --:--:-- ETA
# eraseall /dev/mtd2 ; dd if=vmlinuz-7402c0 of=/dev/mtd2
Erasing 128 Kibyte @ 1e0000 -- 93 % complete.
3130+1 records in
3130+1 records out
# wget http://192.168.1.2/a-fs-cramfs.img
Connecting to 192.168.1.2[192.168.1.2]:80
a-fs-cramfs.img 100% |*****************************| 13964 KB 00:00:00 ETA
# eraseall /dev/mtd0 ; dd if=a-fs-cramfs.img of=/dev/mtd0
Erasing 128 Kibyte @ 11e0000 -- 99 % complete.

27928+0 records in
27928+0 records out
#
# reboot
# Connection closed by foreign host.

Уверен, что данная заметка пригодится не только мне.

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

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

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)
Загрузка...
Отправить на почту Отправить на почту

Автообзвон

Есть задачи реализация которых возможна через автоматический обзвон. Например ?

Например вы сис.админ, у вас есть локальная сеть и куча оборудования в ней, но вы же не 24/7 на работе, а раз так, то в сети может что то произойти, например событие в системе мониторинга, а вас нет на рабочем месте. Конечно можно отправлять себе SMS, если такая вожможность есть, а имея сервер Asterisk можно и позвонить и самому себе рассказать что же случилось 😉

Или вам необходима система callback, что бы позвонив на номер заведенный на Asterisk, вы могли получить с него обратный звонок и набрать другой номер.

Итак, считаем что у вас у уже есть установленный и настроенный сервер Asterisk, который имеет выход в город.

Что бы совершить автоматический звонок нам потребуется следующие вещи:

  • сформировать call файл
  • иметь в диалплане (dialplan (определяется в /usr/local/etc/asterisk/extensions.conf)) контекст (context) со списком действий

Начнем с call файла, его основной синтаксис:

  • Channel: <channel> — Какой канал использовать для звонка
  • CallerID: «name» <number> — Установить Caller ID, проще сказать тут мы можем выставить АОН (номер с которого мы звоним).
  • MaxRetries: <number> — Максимальное кол-во попыток дозвониться, по умолчанию 0, что является одной попыткой.
  • RetryTime: <number> — Время в секундах между попытками дозвона, по умолчанию 300 (5 минут).
  • WaitTime: <number> — Сколько секунд ожидаем поднятия трубки, по умолчанию 45.
  • Context: <context-name> — Какой контекст используем из extensions.conf
  • Extension: <ext> — Какой экстеншн используем в выбранном контексте (так же в extensions.conf).
  • Priority: <priority> — С какого приоритета начинаем.

Я привел не полный список, полный список доступен тут. Лично я, для каждого номера, создаю свой контекст в extensions.conf.

Соответственно зная синтаксис мы теперь сможем сформировать call файл, на примере звонка через SIP канал:

Channel: SIP/89161112233@sip-provider
Callerid: 9998877
MaxRetries: 2
RetryTime: 20
WaitTime: 60
Context: outgoing_to_89161112233
Extension: s
Priority: 1

Для тех кто в танке 🙂 разберем call файл построчно:

  • позвонить на SIP номер 89161112233 через провайдера sip-provider (имя из /usr/local/etc/asterisk/sip.conf для выхода в город)
  • использовать АОН 9998877
  • Максимальное кол-во попыток дозвона 2
  • Пауза между попытками 20 секунд
  • Ожидать поднятия трубки 60 секунд
  • Использовать контекст (context) с именем outgoing_to_89161112233
  • Начинать с экстеншена (ext) s
  • И начинать с приоритета 1 в экстеншене s

Сформировав call файл, его необходимо положить в папку:  /var/spool/asterisk/outgoing/ сервер Asterisk обнаружив в этой папке файл сразу же попытается отработать его.

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

Сервер Asterisk смотрит на дату создания call файла и если изменить дату создания на дату в будущем, то Asterisk не будет отрабатывать call файл, пока не наступит эта самая дата.

Как это сделать ? Очень просто, для этого воспользуемся командой touch, которая есть во всех unix системах.

После того как создали сам call файл берем и меняем дату его создания, шаблон даты такой:

ГОДМЕСЯЦДЕНЬЧАСЫМИНУТЫ.СЕКУНДЫ (внимание: перед секундами стоит символ точки, это так и нужно, а не опечатка).

Для примера выставим дату в будущем, скажем это 09.07.2010 19:18:55:

/usr/bin/touch -t 1007091918.55 /path/to/call/file.call

Дата создания call файла изменится и если переместить файл в /var/spool/asterisk/outgoing/, то соответственно Asterisk его не обработает до тех пор пока не наступит выставленная дата.

Совет: генерить call файл лучше в какой то tmp директории, выполнять над ними все необходимые и действия и затем мувить (переносить) в /var/spool/asterisk/outgoing/.

Теперь посмотрим на сам контекст (context), для системы мониторинга он может быть таким:

[outgoing_to_89161112233]
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/welcome)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/Down)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/provider-a)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/bye)
exten => s,n,hangup

Исходя из данного контекста Asterisk дозвонившись до 89161112233 (человек взял трубку) выполнит следущее:

  • поднимет трубку со своей стороны
  • секунду подождет
  • проиграет записанные вами звуковые файлы (полные пути к файлам указаны)
  • повесит трубку

Как записать голосовые файлы (то что вы будете проигрывать) вы можете узнать из этой статьи.

После того как Asterisk полностью отработает call файл, он его удаляет из директории /var/spool/asterisk/outgoing/.

Специальный экстеншен ‘failed
Если на вызов не ответили, и существует стандартный экстеншен с именем failed и команда с приоритетом 1 в заданном (в .call файле) контексте, управление будет передано этой команде.

exten => failed,1,Set(NumberDialed=${CUT(PassedInfo,,1)})
exten => failed,n,SetCDRUserField(${NumberDialed})

[Добавлено 11.02.2011]

Может появится ещё одна задача, а именно: если при автодозвоне трубку так и не подняли, то сразу набрать другой номер. Пример такой конструкции:

  • сначала набираем внутренний SIP  номер (6003) человека
  • если внутренний SIP номер не отвечает/занят/недоступен — набираем мобильный номер

Кажется, ну что может быть проще, написать:

exten => failed,1,Dial(SIP/89161112233@sip-provider)

А вот тут то и выяснилось, что не все так просто. На такое действо вы в консоле (выставив core set verbose 3) увидите подобное сообщение:

— Executing [failed@dialsip:1] Dial(«OutgoingSpoolFailed», «SIP/6003») in new stack
[Feb 11 16:57:44] WARNING[94371]: channel.c:3441 ast_request: No translator path exists for channel type SIP (native 65535) to 0
[Feb 11 16:57:44] WARNING[94371]: app_dial.c:1296 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 58 — Bearer capability not available)
== Everyone is busy/congested at this time (1:0/0/1)
== Auto fallthrough, channel ‘OutgoingSpoolFailed’ status is ‘CHANUNAVAIL’
[Feb 11 16:57:54] NOTICE[94371]: pbx_spool.c:356 attempt_thread: Call failed to go through, reason (8) Congestion (circuits busy)

Усе… приехали…. Лазая по результатам поиска в гугле я натыкался на сообщения:

Канал получается OutgoingSpoolFailed и именно в него пытается звонить и Dial и играть Playback. Как мне находясь в failed сделать звонок на SIP и проиграть сообщение?

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

Так же как и я народ пытался реализовать подобное через failed c Goto, System и т.п., но результат получался таким же — никаким 🙁

Получается из starndart extention failed сделать набор (Dial) другого номера не получится…..

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

core*CLI> core show channeltypes
Type        Description                              Devicestate  Indications  Transfer
----------  -----------                              -----------  -----------  --------
Skinny      Skinny Client Control Protocol (Skinny)  no           yes          no
SIP         Session Initiation Protocol (SIP)        yes          yes          yes
Console     OSS Console Channel Driver               no           yes          no
MGCP        Media Gateway Control Protocol (MGCP)    yes          yes          no
Local       Local Proxy Channel Driver               yes          yes          no
Zap         DAHDI Telephony Driver w/PRI             no           yes          no
Agent       Call Agent Proxy Channel                 yes          yes          no
----------
7 channel drivers registered

core*CLI> core show channeltype Local
-- Info about channel driver: Local --
Device State: yes
Indication: yes
Transfer : no
Capabilities: -1
Digit Begin: yes
Digit End: yes
Send HTML : yes
Image Support: no
Text Support: yes
core*CLI>

Создаем call-файл уже чуть другого содержания:

Channel: Local/1@autocaller
Callerid: 9998877
Context: outgoing_to_89161112233
Extension: s
Priority: 1

Где autocaller это название контекста, а 1-ца это приоритет в этом контексте. Соответственно делаем в extensions.conf этот контекст:

[autocaller]
exten => 1,1,Macro(call6003user,6003)

Тем самым мы как бы набираем уже не номер, а конкретный exten  в контексте и в нем передаем вызов в макро, создаем и макро, которое используется в этом контексте:

[macro-call6003user]
exten => s,1,Dial(SIP/${ARG1},15,t)
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,Dial(SIP/89161112233@sip-provider)
exten => s-NOANSWER,n,VoiceMail(${ARG1},u)
exten => s-NOANSWER,n,Hangup()
exten => s-BUSY,1,VoiceMail(${ARG1},b)
exten => s-BUSY,n,Hangup()
exten => _s-.,1,Goto(s-NOANSWER,1)

Собственно этот макро дает нам возможность уже управлять куда и в каком случае пойдет вызов. Пример конечно «грубый», но главное ведь принцип, а дальше уже ваше творчество 😉

И вот таким образом мы получаем искомый результат.

[Конец добавленного 11.02.2011]

Callback

Он работает по тому же принципу, что и описанный выше автообзвон, за некоторыми исключениеми:

  • генерация call файла происходит при звонке человека на номер выделенный под callback.
  • в контексте (context) мы не просто проигрываем звуковые, а предлагаем пользователю ввести номер, на который он хочет позвонить

Что нам потребуется в этом случае:

  • выделить номер для callback и создать контекст (context) под него в  extensions.conf.
  • «передать»  звонок в AGI скрипт, который проверит АОН звонящего на предмет разрешен ли этому номеру callback
  • если  callback разрешен, то сформирует call файл.

AGI — это Asterisk Gateway Interface.
Asterisk Gateway Interface это возможность расширить функционал Asterisk`а с помощью использования скриптов на многих языках программирования. Например Perl, PHP, C, Pascal, Bourne Shell.

Начнем с номера, допустим это будет гор. номер 84955556677. Добавим в extensions.conf в контекст (context) куда поступают все входящие звонки:

exten => 84955556677,1,AGI(sms-callback.php)
exten => 84955556677,n,Hangup()

Т.е. звонок на экстеншн (ext) 84955556677 будет передан AGI скрипту callback.php, а затем звонок будет сразу же завершен.

AGI скрипты для Asterisk располагаются в директории  /usr/local/share/asterisk/agi-bin/.

Почему скрипт на PHP ? PHP был выбран для AGI, т.к. callback является неотъемлимой частью проекта написанного на PHP + MySQL, потому решили и AGI пусть на PHP будет.
Сам скрипт: http://subnets.ru/files/callback.php.txt

Что происходит с скрипте ?

  • определяем необходимые переменные
  • получаем данные от Asterisk`а.
  • логи, куда же без них. В лог мы поместим все то, то получил AGI скрипт от Asterisk`а, это для дебага, потом можно выключить логирование.
  • проверяем номер (АОН) звонящего на доступ к callback
  • смотрим нет ли уже call файла для  данного номера, если нет, то создаем его

В переменной $agivar[‘agi_callerid’] и содержится АОН (телефонный номер) звонящего переданного нам Asterisk`ом, что в других передаваемых переменных вы сможете увидеть в log файле.
Если установить $debug в ноль, то тем самым выключите логирование.
В массиве  $permit_num содержатся номера для которых разрешен callback.

Ну и осталось дело за малым, а именно что бы был контекст (context) под звонящий номер в extensions.conf.

Допустим наш callback номер 84955556677 набрали с мобильного 89105647899 и ему разрешен callback (номер84955556677 указан в массиве  $permit_num в скрипте), то его контекст может выглядеть вот так:

[outgoing_to_89105647899]
exten => s,1,Set(CallbackNumTries=0)
exten => s,n,Set(CALLERID(num)="9998877")
exten => s,n(start),Background(vo-vvedite-ton-num-abonent)
exten => s,n,WaitExten(10)
exten => 100,1,Dial(SIP/8495${EXTEN}@sip-provider,120)
exten => _XXXXXXX,1,Dial(SIP/8495${EXTEN}@sip-provider,120)
exten => _8X.,1,Dial(SIP/${EXTEN}@sip-provider,120)
exten => i,1,Set(CallbackNumTries=$[${CallbackNumTries} + 1])
exten => i,n,Playback(vo-nomer-nabran-ne-verno)
exten => i,n,GotoIf($["${CallbackNumTries}" < "3"]?s|start)
exten => i,n,Playback(vo-dosvidaniya)
exten => t,1,Set(CallbackNumTries=$[${CallbackNumTries} + 1])
exten => t,n,GotoIf($["${CallbackNumTries}" < "3"]?s|start)
exten => t,n,Playback(vo-dosvidaniya)
exten => t,n,Hangup()
  • устанавливаем число попыток в ноль
  • выставляем АОН (под исх. звонок)
  • проигрываем записанный текст: «переведите ваш телефон в тональный набор…. бла… бла.. бла…»
  • 10 сек. ждем от человека набора номера
  • указываем возможный набор номеров: 100 (узнать время ;)), 7-ми значный номер, 8-рка и далее сколько угодно цифр
  • даем человеку три попытки на набор номера, если истек таймаут набора номера или номер был набран не верно, то человеку это озвучивается и кол-во попыток увеличивается на 1-цу и наше мини голосовое меню начинается сначала (возврат к метке start)
  • если кол-во попыток исчерпано, то Asterisk вешает трубку

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 19, среднее: 4,95 из 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)
Загрузка...
Отправить на почту Отправить на почту