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

Версия для печати Версия для печати

Кто то уже знает, кто-то нет и спит спокойно, точнее пока что спит спокойно.

Как давно вы читали логи своего Asterisk сервера ?

Некоторые из вас или уже видели или ещё увидят в логах строчки:

  • Registration from ‘»100″<sip:100@sip.mydomain.ru>’ failed for ‘188.165.215.79′ – No matching peer found
  • Registration from ‘»111″ <sip:111@sip.mydomain.ru>’ failed for ‘188.165.215.79′ – Wrong password

Догадываетесь к чему они ведут ? К тому что вас сканят и пытаются подобрать пароль к вашим SIP аккаунтам.

Большинство пользователей безалаберно относятся к своим паролям, это факт, а раз так то проверте что на ваших SIP номерах не стоят пароли аля 123 или 1234.

Если пароль таки подберут, то вы (или ваш клиент) попадете на деньги, т.к. через вас пустят звонки забугор, например на Кубу или Северную Корею.

Давайте разберемся как они это делают и попробуем усложнить им жизнь помимо смены паролей к своим SIP аккаунтам.

В сети есть набор утилит sipvicious:

The 4 tools that you should be looking at are:
svmap
svwar
svcrack
svreport
svcrash

The tools:
svmap – this is a sip scanner. When launched against
ranges of ip address space, it will identify any SIP servers
which it finds on the way. Also has the option to scan hosts
on ranges of ports.

svwar – identifies working extension lines on a PBX. A working
extension is one that can be registered.
Also tells you if the extension line requires authentication or not.

svcrack – a password cracker making use of digest authentication.
It is able to crack passwords on both registrar servers and proxy
servers. Current cracking modes are either numeric ranges or
words from dictionary files.

svreport – able to manage sessions created by the rest of the tools
and export to pdf, xml, csv and plain text.

svlearnfp – allows you to generate new fingerprints by simply running
the tool against a host. It will attempt to guess most values and allow
you to save the information to the local fingerprint db. Then you can
choose to upload it to the author so that it can be added to the database.

svcrash – responds to svwar and svcrack SIP messages with a message that
causes old versions to crash.

Так вот с их помощью нас и сканят.  Эти же утилиты помогут нам просканить самих себя и  усложнить жизнь уродам жаждущих халявы.

Начнем с того что скачаем этот набор утилит (сохраненная у нас копия).

Распакуйте архив в какую нить папку и можно приступать к скану.

Будет считать что IP-адрес нашего Asterisk сервера это 192.168.1.1  и запустим сканер:

cd /home/virus/sipvicious

./svmap.py -p5060 192.168.1.1 -m INVITE

Получаем результат:

| SIP Device        | User Agent   | Fingerprint |
--------------------------------------------------
| 192.168.1.1:5060 | Asterisk PBX | disabled    |

Идем далее, посканим теперь на аккаунты:
./svwar.py –force -e100-999 192.168.1.1

Ответ может быть таким:

| Extension | Authentication |
------------------------------
| 210       | reqauth        |
| 300       | reqauth        |
| 666       | reqauth        |
| 241       | reqauth        |
| 242       | reqauth        |
| 222       | reqauth        |

Можно ли как то обломать их ? Можно. Для этого отредактируем /usr/local/etc/asterisk/sip.conf и добавим или раскоментируем строчку в секции [general]:
alwaysauthreject = yes

Описание:

When an incoming INVITE or REGISTER is to be rejected, for any reason, always reject with ‘401 Unauthorized’ instead of letting the requester know whether there was a matching user or peer for their request.

Т.е. наш сервер будет всегда при любых ошибках авторизации будет отвечать «401 Unauthorized» и не сообщать подробностей.

После изменения sip.conf зайдите в консоль Asterisk`а:
asterisk -r

и примените изменения:
asterisk*CLI> sip reload

Теперь посканим снова:
./svwar.py –force -e100-999 192.168.1.1

Ответ от сканера изменился и выглядит примерно так:

WARNING:TakeASip:Bad user = SIP/2.0 401  - svwar will probably not work!
WARNING:TakeASip:We got an unknown response
ERROR:TakeASip:Response: 'SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/UDP 192.168.1.1:5061;branch=z9hG4bK-3613016185;received=192.168.1.1;rport=5061\r\n
From: "100"; tag=31303001333430333334313736\r\n
To: "100";tag=as47e73e29\r\nCall-ID: 2008271273\r\n
CSeq: 1 REGISTER\r\n
User-Agent: Asterisk PBX\r\n
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO\r\n
Supported: replaces\r\n
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3b652f8d"\r\n
Content-Length: 0\r\n\r\n'

Как видите списка с номерами более не выдается, то что нам и надо.

Что ещё мы можем сделать ?

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

Добавим в  /usr/local/etc/asterisk/extensions.conf в секцию где у вас происходит выход в город:

exten => _810X.,1,playback(pbx-invalid)
exten => _810X.,n,Hangup()

Так же мы можем скриптом анализировать логи Asterisk сервера и всех уродов, подбирающих пароль, банить фаирволом (ipfw) сервера.
Нашу версию подобного скрипта можно увидеть пройдя по ссылке: http://subnets.ru/files/protect_aster.txt
Инсталляция скрипта:
1. Сохраните код скрипта на своем сервере
2. Переименуйте файл в protect_aster.sh
3. Сделайте скрипт исполняемым:
chmod a+x protect_aster.sh
4. Добавте в ваш firewall ipfw правило:
ipfw add XXX reject ip from «table(56)» to me
(где ХХХ это номер правила)
5. Добавте скрипт на исполнение по crontab, отредактируйте /etc/crontab:

*/5    *       *       *       *       root    /full/path/to/script/protect_aster.sh

Забаненый IP-адрес попадает в таблицу ровно на сутки, через сутки он автоматически будет удален из таблицы.

Надеемся, что эти не хитрые приемы помогут вам остаться при деньгах и сэкономить ваши нервы.

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Делалось по статье http://tuxnotes.ru/articles.php?a_id=18
Тут приведу её полностью, со своими комментариями и дополнениями [в квадратных скобках].

В конце статьи будут приведены мои конфиги сервера и клиента.
—————————————————————————————————————

Создание сервера OpenVPN в FreeBSD

Однажды передо мной предстала задача реализации безопасного доступа из внешнего мира к внутренней корпоративной сети. На выходе из корпоративной сети стоял FreeBSD 7.0, в качестве реализации был выбран OpenVPN.
В данной статье я на примере из личной практики опишу процесс создания OpenVPN сервера на системе FreeBSD, с возможностью подключения к нему удаленных пользователей (с различных операционных систем: Windows, Linux, MacOS etc.).

Настройка проводилась на системе FreeBSD версии 7.0, настройка на других версиях аналогична данной.

Адрес внутренней сети – 192.168.1.0/24

1. Установка OpenVPN, создание сертификатов и ключей

Устанавливаем OpenVPN из портов:

cd /usr/ports/security/openvpn
make install clean

Далее создаем сертификаты и ключи:

cd /usr/local/share/doc/openvpn/easy-rsa/
[при моей инсталляции требуемые файлы лежали в /usr/local/share/doc/openvpn/easy-rsa/2.0]

Редактируем файл vars, содержащий переменные окружения:

chmod +w vars
vi vars

[также нужно отчмодить и скрипты в каталоге, за исключением файлов *.cnf и текстовых Makefile и README]

затем добавляем в файле vars к переменной export KEY_DIR=$D/keys еще каталог server (для удобства). Должно получиться так:

export KEY_DIR=$D/keys/server
[я не добавлял дополнительный каталог]

Загружаем переменные в оболочку:

sh
. ./vars

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

создаем каталог keys и в нем подкаталог server

mkdir -p keys/server

создаем сертификат для сервера:

chmod +x build-ca
./build-ca

Пример ввода данных:

#./build-ca
Generating a 1024 bit RSA private key
....................++++++
...++++++
writing new private key to 'ca.key'
----- You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----

Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:

Создаем файлы index.txt и serial:

touch /usr/local/share/doc/openvpn/easy-rsa/keys/server/index.txt
echo «00″>/usr/local/share/doc/openvpn/easy-rsa/keys/server/serial

Затем создаем сертификат X.509 для сервера. Всё необходимо заполнить аналогично и добавить строки с указанием пароля и имени организации:

chmod +x build-key-server
./build-key-server server

#./build-key-server server
Country Name (2 letter code) [UA]:UA
State or Province Name (full name) [Kiev]:Kharkov
Locality Name (eg, city) [Kiev]:Kharkov
Organization Name (eg, company) [x]:server
Organizational Unit Name (eg, section) []:server
Common Name (eg, your name or your server's hostname) []:server
Email Address [root@localhost]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: your_password
An optional company name []:server

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

Создаём ключ для клиента:

chmod +x build-key
./build-key client

# ./build-key client
Generating a 1024 bit RSA private key
........++++++
...................................++++++
writing new private key to 'client.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [KG]:UA
State or Province Name (full name) [NA]:Kharkov
Locality Name (eg, city) [BISHKEK]:Kharkov
Organization Name (eg, company) [OpenVPN-TEST]:server
Organizational Unit Name (eg, section) []:client
Common Name (eg, your name or your server's hostname) []:client
Email Address [me@myhost.mydomain]:root@localhost
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:your_password
An optional company name []:client

Стоит заметить, что поле organizationName должно совпадать с тем, которое мы ввели при создании сертификата сервера. В нашем случае это будет имя server.

Создаем ключ Диффи-Хелмана (необходим для безопасной авторизации двух сторон):

chmod +x build-dh
./build-dh

выходим из sh:

exit

Создаем ключ для tls-аутентификации:

openvpn –genkey –secret keys/server/ta.key

создаем каталоги для нашего openvpn-сервера:

cd /usr/local/etc/
mkdir openvpn
cd openvpn/
mkdir keys
mkdir ccd

Переходим в каталог /usr/local/etc/openvpn/keys и копируем в него необходимые для сервера ключи и сертификаты:

cd /usr/local/etc/openvpn/keyscp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ca.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/dh1024.pem
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.crt
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/server.key
cp /usr/local/share/doc/openvpn/easy-rsa/keys/server/ta.key

Когда сертификаты и ключи созданы, переходим к настройке OpenVPN-сервера.

2. Настройка сервера

в каталоге /usr/local/etc/openvpn создаем файл конфигурации нашего openvpn-сервера

touch server.conf

#указываем порт, на котором будет работать наш сервер
port 2000
# протокол будет использоваться udp (по идее он работает быстрее чем tcp)
proto udp
# используемый тип устройства и номер
dev tun0
#указываем файл CA
ca /usr/local/etc/openvpn/keys/ca.crt
#указываем файл с сертификатом сервера
cert /usr/local/etc/openvpn/keys/server.crt
#указываем файл с ключем сервера
key /usr/local/etc/openvpn/keys/server.key
#указываем файл Диффи Хельман
dh /usr/local/etc/openvpn/keys/dh1024.pem

#задаем виртуальный IP-адрес сервера и маску подсети, которые будут использоваться в нашем туннеле между сервером и удаленным клиентом
server 10.0.0.0 255.255.255.0

#указываем клиенту маршрут к серверу по виртуальному интерфейсу
push «route 10.0.0.0 255.255.255.0″

# указываем где хранятся файлы с настройками клиентов
client-config-dir ccd

# включаем TLS аутентификацию
tls-server
# указываем tls-ключ, и указываем 0 для сервера, а 1 для клиента
tls-auth keys/ta.key 0
# таймаут до реконекта
tls-timeout 120
auth MD5
# включаем шифрацию пакетов с использованием алгоритма симметричного шифрования Blowfish. Пока не было известно ни одно случая взлома данного алгоритма + он быстрее DES
cipher BF-CBC
[в моём случае шифрование не использовалась и поэтому этот пункт закомменчен]

#указывем, что каждые 10 секунд пинговать удаленный хост, и в случае если, в течении 120 секунд не будет ответа – то разрывать соединение
keepalive 10 120

# сжатие трафика
comp-lzo
[если эта опция используется на одной из сторон, она должна обязательно использоваться и другой стороной. иначе коннект будет рваться на этапе согласования MTU туннеля
между сервером и клиентом
]

# максимум клиентов
max-clients 100

#по умолчанию используется аутентификация пользователей по файлам сертификатов, то есть пользователь у себя хранит файлы сертификатов, соответственно пароль в таком случае не используется. На мой взгляд это не совсем безопасно (т.к. если кому-то удастся заполучить эти сертификаты, то он легко сможет получить доступ к нашей корпоративной сети). Я решил добавить к аутентификации по сертификатам еще и аутентификацию по паролю. Будет использоваться пара логин/пароль пользователя в системе FreeBSD ( которого необходимо заранее создать).
[разумеется, используется пользователь с паролем и без шелла - /usr/sbin/nologin
в случае автора эти логин-пароль при установлении соединения нужно ввести вручную, как сделать это автоматически рассмотрено ниже
]

Для добавления аутентификации по паролю подключаем плагин openvpn-auth-pam (который обычно идет вместе с пакетом OpenVPN):

plugin /usr/local/lib/openvpn-auth-pam.so loginuser nobody
group nobody

# Не перечитывать ключи после получения
# SIGUSR1 или ping-restart
persist-key
# Не закрывать и переоткрывать TUN\TAP
# устройство, после получения
# SIGUSR1 или ping-restart
persist-tun
# логирование (не забудьте создать дирректорию /var/log/openvpn/)
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log

# Уровень информации для отладки
verb 3

затем создаем в каталоге ccd файл с настройками удаленного клиента (имя файла должно строго совпадать с именем сертификата, то есть в нашем случае это имя client) следующего содержания:

push «route 192.168.1.0 255.255.255.0″

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

добавляем в файл /etc/rc.conf следующие строчки, для атоматического запуска openvpn-сервера при загрузке системы

openvpn_enable=»YES»
openvpn_if=»tun»
openvpn_configfile=»/usr/local/etc/openvpn/server.conf»
openvpn_dir=»/usr/local/etc/openvpn»

Если у вас стоит фаервол, то не забудьте открыть в нем порт. У меня стоит pf, я добавляю следующие правила:

set skip on tun0
pass in inet proto udp from any to $ext_if port 2000 keep state
pass quick on tun0

Не забудьте указать в /etc/rc.conf:

gateway_enable=»YES»

для того, что что бы ваше сервер мог перенаправлять пакеты.

[если до этого момента gateway_enable не было в /etc/rc.conf, то что бы применить изменения без перезагрузки выполните: sysctl net.inet.ip.forwarding=1]

Все. На этом настройка нашего сервера закончена.

3. Настройка клиента

С сервера необходимо скопировать созданные ранее сертификаты, но не все, а только необходимые пользователю, а именно: ca.crt, client.crt, client.key, dh1024.pem, ta.key.

В рабочем каталоге OpenVPN на стороне клиента создаем папку keys, куда и копируем вышеприведенные файлы. Затем создаем конфигурационный файл с любым именем, например client.ovpn, со следующим содержимым:

dev tun
proto udp
remote 11.11.11.11
#(вместо 11.11.11.11 необходимо указать внешний IP вашего сервера)
port 2000 #(порт к которому устанавливать соединение)
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5

auth-user-pass
# команда, указывающая клиенту использовать авторизацию по паролю
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun

#proxy 192.168.1.50:3128 #Раскомментируйте эту строчку, если вы работаете через прокси-сервер

status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

На этом настройка закончена. Все конфиги брались с рабочего сервера.
Процесс создания OpenVPN-сервера на других системах (Debian, Gentoo, Slackware, *BSD) будет аналогичен данному.
Тем и хорош OpenVPN.

Алексей Михайлов
Специально для tuxnotes.ru

[Мои конфиги сервера и клиента]
——————————————————————————-

Сервер:

local 77.87.200.10
port 2000
proto tcp
dev tun0
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem

server 172.20.20.0 255.255.255.0 #примечание: сервер забирает себе при организации тунеля первые два адреса из подсети
push «route 172.20.20.0 255.255.255.0″
client-config-dir ccd
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5
#cipher BF-CBC
keepalive 10 120
comp-lzo
max-clients 1
plugin /usr/local/lib/openvpn-auth-pam.so login
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

#tun-mtu 1450 #примечание: можно регулировать размер MTU (должен быть одинаковым на сервере и на клиенте)

Клиент:

dev tun
proto tcp
remote 77.87.200.10
port 2000
client
resolv-retry infinite
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
tls-client
tls-auth keys/ta.key 1
auth MD5
auth-user-pass
#cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

#tun-mtu 1450 #примечание: см. сервер
auth-user-pass keys/account #примечание: в текстовом файле account двумя отдельными строками хранятся логин и пароль
auth-nocache #примечание: чтобы логин-пароль не оставались на клиентской стороне в памяти

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

Автор: Будимиров Максим (madmax (at) subnets.ru)

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

ЗАМЕТКА

В рамках поднятия 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;
        }
    }
}

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

IPIP tunnel Juniper MX-series Routers + static route via IPIP tunnel interface

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

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

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

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

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

Читаю 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 туннель подсети

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

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

И вот оно случилось, снова появилась свежеполученная AS с блоком адресов и я все же выкроил время для теста.

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

Дано

  • Juniper M7i
  • на нем уже поднят BGP с несколькими апстримами

Задача

Сделать виртуальный роутер (logical-system) внутри реального роутера, соединить их по протоколу BGP и проанонсировать новую ASку в Инет.

Connect Logical System BGP to Main system BGP.

Решение

Logical System Overview

Logical systems perform a subset of the actions of a physical router and have their own unique routing tables, interfaces, policies, and routing instances. A set of logical systems within a single router can handle the functions previously performed by several small routers.

The following are supported on logical systems:
Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), RIP next generation (RIPng), Border Gateway Protocol (BGP), Resource Reservation Protocol (RSVP), Label Distribution Protocol (LDP), static routes, various multicast protocols, and IP version 4 (IPv4) and version 6 (IPv6) are supported at the [edit logical-systems protocols] hierarchy level.
Basic Multiprotocol Label Switching (MPLS) for core provider router functionality is supported at the [edit logical-systems protocols mpls]] hierarchy level.
All policy-related statements available at the [edit policy-options] hierarchy level are supported at the [edit logical-systems policy-options] hierarchy level.
Most routing options statements available at the [edit routing-options] hierarchy level are supported at the [edit logical-systems routing-options] hierarchy level. Only the route-record statement is not supported at the [edit logical-systems routing-options] hierarchy level.
Graceful Routing Engine switchover (GRES) is supported.
You can assign most interface types to a logical system, including SONET interfaces, Ethernet interfaces, Asynchronous Transfer Mode (ATM) interfaces, ATM2 interfaces, Channelized Q Performance Processor (QPP) interfaces, aggregated interfaces, link services interfaces, and multilink services interfaces.
Source class usage, destination class usage, unicast reverse path forwarding, class of service, firewall filters, class-based forwarding, and policy-based accounting work with logical systems when you configure these features on the physical router.
Multicast protocols, such as Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP) are supported at the [edit logical-systems logical-system-name protocols] hierarchy level. Rendezvous point (RP) and source designated router (DR) functionality for multicast protocols within a logical system is also supported.
The Bidirectional Forwarding Protocol (BFD) is supported.

The following restrictions apply to logical systems:
You can configure a maximum of 15 logical systems on one physical router.
The router has only one configuration file, which contains configuration information for the physical router and all associated logical systems. Master users can access the full configuration. However, logical system users can access only the portion of the configuration related to their particular logical system.
All configuration commits performed by a logical system user are treated as commit private. For more information on the commit private command, see the JUNOS System Basics Configuration Guide.
If a logical system experiences an interruption of its routing protocol process (rpd), the core dump output is saved in a file in the following location: /var/tmp/rpd_logical-system-name.core-tarball.number.tgz. Likewise, if you issue the restart routing command in a logical system, only the routing protocol process (rpd) for the logical system is restarted.
If you configure trace options for a logical system, the output log file is stored in the following location: /var/tmp/logical-system-name.
The following Physical Interface Cards (PICs) are not supported with logical systems: Adaptive Services PIC, ES PIC, Monitoring Services PIC, and Monitoring Services II PIC.
Sampling, port mirroring, IP Security (IPsec), and Generalized MPLS (GMPLS) are not supported.
Label-switched path (LSP) ping and traceroute for autonomous system (AS) number lookup are not supported.
If you configure multiple logical systems, you can configure a VPLS routing instance only for the first logical system configured at the [edit logical-systems logical-system-name routing-instances instance-name protocols vpls] hierarchy level.

Начинаем «курить» мануалы:

Более-менее понятно, что соединить осноной роутер (main) с виртуальным (logical-system) можно через интерфейсы. Но как ?

Читаем мануалы далее и выясняем, что сделать это можно или с помощью петли, т.е. тупо соединив проводом два физических порта  маршрутизатора (один порт будет принадлежать реальной системе, а второй порт виртуальной) или с помощью «Logical Tunnel Interface«.

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

On M Series and T Series routers, logical tunnel interfaces allow you to connect logical systems, virtual routers, or VPN instances. The router must be equipped with a Tunnel Services PIC or an Adaptive Services Module (only available on M7i routers)

Такс и где же этот встроенный Tunnel Services PIC ?

А вот он:

root@juniper> show chassis hardware

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

Что видно в интерфейсах:
root@juniper> show interfaces lt-1/2/0

Physical interface: lt-1/2/0, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 191
  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 800mbps
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps
  Link flags     : None
  Physical info  : 13
  Current address: 00:1f:12:d5:a0:bc, Hardware address: 00:1f:12:d5:a0:bc
  Last flapped   : 2010-07-17 00:24:41 MSD (2w6d 10:13 ago)
  Input rate     : 3088 bps (4 pps)
  Output rate    : 3088 bps (3 pps)

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

Прочитав Configuring Logical Tunnel Interfaces меня напрягли слова:

To connect two logical systems, you configure a logical tunnel interface on both logical systems.

«Эмм…. две логические…..» подумал я, а как же быть если я собираюсь законектить не две логические системы, а логическую и реальную ?

Смотрю на картинку  в примере настройки (Example: Configuring Logical Systems) и вижу что опять же виртуальные роутеры соединяются с реальными, но нигде реальные роутеры не соединяются с виртуальнфми внутри себя. Так делать нельзя ? Хм… как минимум странно.

Зрим в пример туннельного интерфейса:

lt-fpc/pic/port {
     unit logical-unit-number {
          encapsulation encapsulation;
          peer-unit unit-number; # peering logical system unit number
          dlci dlci-number;
          family (inet | inet6 | iso | mpls);
    }
}

Хм…. вроде все понятно, а вроде и нет ? Что такое peer-unit и какой номер указывать ? Читаем о peer-unit:

Syntax
peer-unit unit-number;
Hierarchy Level
[edit interfaces interface-name unit logical-unit-number],
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
Release Information

Statement introduced before JUNOS Release 7.4.
Description

Configure a peer relationship between two logical systems.
Options

unit-number—Peering logical system unit number.
Usage Guidelines

See Configuring Logical Tunnel Interfaces.
Required Privilege Level

interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration

Стало понятнее ? Мне нет….

Дальнейшее «курение» мануалов просветления в этом вопросе не принесло. Практика, попытки сделать хоть что то, тоже. Все они заканчивались выводом разнообразных ошибок при коммите (commit), например:

peer-unit needs to be configured for logical tunnel interface
error: configuration check-out failed
encapsulation needs to be configured for logical tunnel interface
error: configuration check-out failed

Или о том что интерфейсы реальной системы пересекаются с виртуальной:

Interface lt-1/2/0.1 is also configured at the top-level
error: configuration check-out failed

Либо реальная система не видела виртуальную (не было пинга).

Ну что ж, обратимся к великому гуглу ! Но толи я не так искал, тли не так читал :) не знаю, но ответа на свой вопрос я по прежнему не получил.

Листая форум на juniper.net, а затем  повторное прочтение Configuring Logical Tunnel Interfaces навели меня на мысль о том, что нужно и в реальном (main) роутере и в виртуальном настраивать именно туннельный интерфейс и «натравливать» их друг на друга.

Ну что ж, попробуем. Начнем с интерфейсов.

Для начала создадим наш логический роутер (для примера имя ему дадим virtual-bgp-router), переходим в режим конфигурации и начинаем:

[edit]
root@juniper#
set logical-systems virtual-bgp-router

Затем создадим наш туннельный интерфейс, я возьму номер 999, вы ессно можете указать любой понравившийся вам номер юнита, которого ещё нет на этом интерфейсе:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999

Зададим инкапсуляцию:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 encapsulation ethernet

Зададим с каким юнитом основного (main) роутера  мы будем соединяться:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 peer-unit 333

Добавим IP-адрес на интерфейс:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 family inet address 192.168.1.2/24

Так, с виртуалкой  пока закончили, теперь нужно реальному роутеру объяснить что к чему. Настроим туннельный  интерфейс и на нем.

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333

Создали  unit 333, тот юнит, который мы указали при создании туннельного интерфейса в логическом роутере, в кач-ве peer-unit.

Затем все действия точно такие же как делали выше, зададим инкапсуляцию:

[edit]
root@juniper#
set  interfaces lt-1/2/0 unit 333 encapsulation ethernet

Зададим с каким юнитом виртуального роутера мы будем соединяться:

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333 peer-unit 999

Добавим IP-адрес на интерфейс:

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333 family inet address 192.168.1.1/24

Ну вот, в первом приближении и все. Коммитим конфигурацию и смотрим, все ли работает как надо.

Для начала проверим есть ли у нас пинг с реального роутера на виртуальный:

[edit]
root@juniper#
run ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.910 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.802 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.839 ms
^C
— 192.168.1.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.802/0.850/0.910/0.045 ms

Затем наоборот, из виртуального на реальный:
[edit]
root@juniper#
run ping logical-system virtual-bgp-router 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.932 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.842 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.866 ms
^C
— 192.168.1.1 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.842/0.880/0.932/0.038 ms

Пинг в наличии ! А значит и все остальное, по нашей задаче BGP пиринг между реальной системой и виртуальной, уже можно воплощать в жизнь.

Как поднимать BGP на Juniper в этой статье я расписывать не буду, т.к. уже делал это в статье «Настройка протокола BGP на оборудовании Juniper«, скажу лишь что в виртуальном роутере все настраивается точно так же как и в реальном, т.е. переходим в режиме редактирования в «ветку» своего виртуального роутера:

[edit]
root@juniper#
edit logical-systems virtual-bgp-router

Забываем о том, что это виртуалка и настраиваем так же как обычный роутер. Т.е. поехали:

[edit]
root@juniper#
set protocols bgp local-as 12345

где «12345″  есть наша свежеполученная AS, затем настраиваем BGP пир (создаем BGP соседа  192.168.1.1 (реальный роутер) и т.д. и т.п.

После того как вы закончите с настройкой протокола BGP на виртуальном роутере, не забудьте создать BGP соседа (192.168.1.2) и в реальном роутере.

По итогу получаем самое обычное взаимоотношение по протоколу BGP между реальным роутером и виртуальным ;)

Реальный роутер видит по BGP виртуальный и получает от него один свой префикс от новой ASки:
root@juniper> show bgp summary | match 192.168.1.2

192.168.1.2 12345 2629 77689 0 0 01:40:19 1/1/1/0 0/0/0/0

Ну и наборот, виртуальный видит реальный роутер, который сгружает ему full-view таблицу:
root@juniper> show bgp summary logical-system virtual-bgp-router

Groups: 1 Peers: 1 Down peers: 0

Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.1         54321      77697       2639       0       0    01:44:37 323070/323070/323070/0  0/0/0/0

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

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

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

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

Автообзвон

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

Например вы сис.админ, у вас есть локальная сеть и куча оборудования в ней, но вы же не 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/.

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 скрипту sms-callback.php, а затем звонок будет сразу же завершен.

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

Почему скрипт на PHP ? PHP был выбран для AGI, т.к. callback является неотъемлимой частью проекта написанного на PHP + MySQL, потому решили и AGI пусть на PHP будет.
Сам скрипт: http://subnets.ru/files/sms-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)

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

Нам недавно пришлось реализовывать «кабельный тестер» на PHP. В Инете нашлась статья, спасибо автору большое, которую я и приведу, прежде чем переходить к кодингу:

В коммутаторы DES-3526 и DES-3550 (возможно DES-3028 и DES-3052) встроен кабельный тестер который позволяет определять (уточнить точность измерений) длину кабеля.

Использование из CLI

Комманда не требует админских полномочий (повторяющиеся строки удалены):

DES3526:user#cable_diag ports 1-24
Command: cable_diag ports 1-24

Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  1     FE      Link Down      OK                             -
  2     FE      Link Down      No Cable                       -
...
  10    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M
  11    FE      Link Down      Pair1 Open      at 25  M       -
                               Pair2 Open      at 25  M
  12    FE      Link Down      Pair1 Open      at 88  M       -
                               Pair2 Open      at 88  M
  14    FE      Link Up        OK                             40
  15    FE      Link Down      Pair1 Open      at 18  M       -
                               Pair2 Open      at 18  M
  16    FE      Link Up        OK                             69
  18    FE      Link Down      Pair1 Open      at 4   M       -
                               Pair2 Open      at 4   M
  19    FE      Link Up        OK                             34
  20    FE      Link Down      OK                             -
  21    FE      Link Up        OK                             40
  22    FE      Link Down      Pair1 Open      at 29  M       -
                               Pair2 Open      at 29  M
  24    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M

Возможные значения:

  • Pair Open – обрыв на растоянии ХХ метров
  • Link Up, длинна ХХ метров
  • Link Down, OK – нельзя измерить длинну кабеля (но нагрузка есть)
  • Link Down, No Cable – нет кабеля

Описание OID-ов:

1.3.6.1.4.1.171.12.58.1.1.1.2 -
swEtherCableDiagPortType OBJECT-TYPE
  SYNTAX INTEGER {
    fastEthernet(0),
    gigaEthernet(1),
    other(2)
  }

# snmpwalk -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.2
SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.1 = INTEGER: 0

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.25 = INTEGER: 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.26 = INTEGER: 1
Имеем, порты 1-24 поддерживают нужный функционал. Проверить состояние линков:

1.3.6.1.4.1.171.12.58.1.1.1.3 -
swEtherCableDiagLinkStatus OBJECT-TYPE
  SYNTAX INTEGER {
    link-down(0),
    link-up(1),
    other(2)
  }

# snmpwalk -v2c -c public 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.1 = INTEGER: 0

Все OID с результатом имеют валидные значения только после выполнения теста. Далее – OIDы для состояния пар:

  • 1.3.6.1.4.1.171.12.58.1.1.1.4 – cтатус первой пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.5 – cтатус второй пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.6 – cтатус третьей пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.7 – cтатус четвертой пары

Возможные значения:

  • ok(0)
  • open(1)
  • short(2)
  • open-short(3)
  • crosstalk(4)
  • unknown(5)
  • count(6)
  • no-cable(7)
  • other(8)

И, соответственно, длины пар: 1.3.6.1.4.1.171.12.58.1.1.1.8 – длинна первой пары 1.3.6.1.4.1.171.12.58.1.1.1.11 – длинна четвертой пары OID, предназначенный для запуска теста:

1.3.6.1.4.1.171.12.58.1.1.1.12

Это единственный OID предназначенный как для чтения так и для записи.

  • action(1)
  • processing(2)
  • other(3)

Тестирование

Работа с кабельным тестером в целом совершенно стандартна (что есть несомненный плюс)

Общий подход:

  • Запустить тест (запись нужного значения в соответвующий OID
  • Дождаться завершения (проверить стением OID со статусом)
  • Считать интересующие значения.

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

Линк есть, работающий абонент:

DES3526:user#cable_diag ports 21
Command: cable_diag ports 21

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  21    FE      Link Up        OK                             40

Запустить тест:

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 1

Проверить что он завершился (cтатус != 2):

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 3

Проверить состояние линка (1 – есть линк)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.21 = INTEGER: 1

Проверить состояние 1-й пары (0 – ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.21 = INTEGER: 0

Проверить состояние 2-й пары (0 – ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.5.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.5.21 = INTEGER: 0

Проверить состояние 3-й пары (8 – Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.6.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.21 = INTEGER: 8

Проверить состояние 4-й пары (8 – Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.7.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.7.21 = INTEGER: 8

Определить длинну 1-й пары (40 метров) # snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 2-й пары (40 метров, что логично, т.к. пары одинаковые)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 3-й пары (0 метров, фактически – не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.10.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.10.21 = INTEGER: 0

Определить длинну 4-й пары (0 метров, фактически – не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.11.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.11.21 = INTEGER: 0

Кабель не подключен:

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2
 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      No Cable                       -

Запустить тест, убедиться что при запросе ответе – «нет кабеля» (8)

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.2 = INTEGER: 8

Кабель есть, отключен

Подключаю 2-х метровый патч-корд к коммутатору (второй конец висит в воздухе):

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      Pair1 Open      at 3   M       -
                               Pair2 Open      at 2   M

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

Кабель имеет статус open:

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.2 = INTEGER: 1

«Обрыв» (в реальности – просто конец кабеля) на расстоянии 3 метра по одной и 2 метра по другой паре.

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.8.2 = INTEGER: 3

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.2 = INTEGER: 2

Насколько я могу судить, точности измерения вполне достаточня (плюс-минус метр).

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

DES3526:user#cable_diag ports 3
Command: cable_diag ports 3

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  3     FE      Link Down      Pair1 Short     at 3   M       -
                               Pair2 Open      at 3   M

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

Ссылка на оригинал статьи: http://wiki.sirmax.noname.com.ua/index.php/Dlink_Cable_Tester

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

PHP

Приведу простой пример, как все это может выглядеть на PHP.

Так как код в блоге выглядит не айс, то выкладываю файликом: http://subnets.ru/saved/dlink_cable_tester.php.txt

В моем рабочем варианте я ессно использую MySQL и все данные о свичах, OID`ах и значениях беру из БД.

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

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Задача

Показывать график по трафику от/к одного BGP пира при условии того, что сессия с ним устанавливается в одном vlan с другими BGP сессиями до других BGP пиров.

Отрисовать график загрузки по интерфейсу не выход, т.к. помимо нужного трафика будет присутствовать еще и трафик с другими BGP пирами.

Решение

В недрах гугла нашлось упоминание про mac accounting.

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

Как по итогу оказалось сделать это нет так сложно.

Имеем Juniper M7i,  для включения на физическом интерфейсе достаточно сделать следующее:

Войдем в режим конфигурации:
root@juniper> configure

Добавим в конфигурацию:

[edit]
root@juniper#
set interfaces ge-0/0/1 gigether-options ethernet-switch-profile mac-learn-enable

после чего в конфигурации интерфейса появится новая секция, посмотрим:
[edit]
root@juniper.#
show interfaces ge-0/0/1

ge-0/0/1 {
    ...................
    gigether-options {
          ethernet-switch-profile {
                 mac-learn-enable;
          }
    }
    ....................
}

Перед коммитом проверим все ли в порядке:
[edit]
root@juniper#
commit check

Если все в порядке и ошибок нет, то можно применять:

[edit]
root@juniper#
commit comment «Enabling mac accounting»


Примечание:
mac accounting нельзя включить на встроенном гигабитном интерфейсе M7i и 10-портовом гигабитном контроллере.


На этом конфигурация Juniper закончена. Что дальше ? А дальше нам нужно как то получить данные для MRTG, те данные по которым и будет строиться график.
Это и оказалось сложнее всего, а именно нахождение необходимых OID’ов где можно забрать нужные нам данные.

Вот алгоритм их нахождения:

1. Получаем номер SNMP-индекса интерфейса (это может быть как сам физический интерфейс так и vlan (802.1q) на этом физическом интерфейсе), получаем на основе прописанного на интерфейсе IP-адреса, например 1.1.1.1 (в нашем случае IP-адрес находится на vlan):

.1.3.6.1.2.1.4.20.1.2.1.1.1.1 = INTEGER: 208

2. Получаем мак-адрес нужного нам BGP пира, например с IP-адресом 1.1.1.2, зная индекс интерфеса (исходя из п.1 это 208):

.1.3.6.1.2.1.4.22.1.2.208.1.1.1.2 = STRING: 0:e0:81:b6:3c:1b

Он нам понадобится далее, но в десятичном виде: 0.224.129.182.60.27

3. Теперь нам нужен номер vlan за которым находится BGP пир. Мы ессно его знаем исходя из конфига девайса и можем посмотреть так (зная номера его индекса исходя из п.1 это 208):

.1.3.6.1.2.1.2.2.1.2.208 = STRING: ge-0/0/1.994

Т.к. на физическом интерфейсе у нас действительно присутствует vlan с id 994 на котором висит IP-адрес 1.1.1.1.

4. после чего нам нужно будет получить SNMP-индекс физического ge-0/0/1, например вот так в тупую:

snmpwalk -v2c -c RO-Community JUNIPER_CONTROL_IP .1.3.6.1.2.1.2.2.1.2 | grep 'ge-0/0/1$'

Видим:

.1.3.6.1.2.1.2.2.1.2.180 = STRING: ge-0/0/1

5. И вот теперь, на основе всех полученных данных, мы можем составить финальные OID’ы для построение графика MRTG:

Первый OID это входящий трафик (HCInOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27 = Counter64: 174250

Второй OID это исходящий трафик (HCOutOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27 = Counter64: 86433120

После чего мы уже можем сделать конфиг для MRTG:

Title[peer_m7i]: 1.1.1.2 BGP peer
MaxBytes[peer_m7i]: 125000000
Target[peer_m7i]: .1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27&.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27:RO-Community@JUNIPER_CONTROL_IP

З.Ы. На Juniper серии MX mac accounting включается немного по другому:

[edit]
protocols {
    l2-learning {
        mac-statistics;
    }
}

Ссылки

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

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

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

Назрел вопрос о реконфигурации AS5350, являющейся пограничным VoIP-шлюзом для существующей скромной (до 100 пиров) VoIP-сети.

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

Задачи

  1. Прием входящего трафика на свою номерную емкость через потоки Е1 от разных операторов.
  2. Пропуск исходящего трафика на Е1 разных операторов (например, в зависимости от ценовой политики).
  3. Формирование АОНа на основе префикса, подставленного перед набираемым номером, присланным из IP сети.
  4. Блокировка исходящих звонков с АОНами, не прописанными на AS5350.
  5. Блокировка входящих звонков на номера, не прописанные на AS5350.

Немного теории

Звонок, с точки зрения AS5350, состоит из двух частей (legs) – voip и pots. Если при поступлении звонка на AS5350 не находятся диалпиры, под которые могут попасть voip и pots части звонка, то будут использоваться системные диалпиры, отображаемые под номером ноль. Ниже приведены две схемы порядка прохождения звонков:

Входящий звонок из Е1

Входящий звонок из Е1

Исходящий звонок на Е1

Посмотреть распределение активных leg-ов по диалпирам можно командой:

show voice call status

CallID     CID  ccVdb      Port             DSP/Ch  Called #   Codec    Dial-peers
0x2B       12F1 0x6640CB84 3/0:D.30         1/3:1  *0007536    14400     66/2
0x32       1256 0x6640CB84 3/1:D.31         1/3:4  *0000579536 g711alaw  0/3

Раз так, то поехали перенастраивать железку. Я буду описывать настройку только наших вышеперечисленных требований.

Настройка

pots-диалпир для входящего трафика из потоков Е1:

dial-peer voice 7 pots
description INBOUND-CALLS-VIA-E1
huntstop                                             //Нашли подходящий диалпир и останавливаем "охоту" на остальных :)
preference 10
incoming called-number .T        //Благодаря этой строке (.Т – любые набираемые номера) этот
//диалпир выбирается в качестве наиболее подходящего для входящего звонка из Е1
direct-inward-dial
no register e164

Замечание: в этом диалпире нет смысла указывать порт потока Е1 как и делать несколько подобных диалпиров под каждый поток, т.к. при входящем через потоки Е1 трафике на вашу номерную емкость всегда будет выбираться диалпир с наименьшим номером.

pots-диалпир для пропуска исходящего МГ/МН трафика (начинающегося с 8-ки: 8.Т) в поток Е1 (3/1) первого провайдера:

dial-peer voice 2 pots
description OUTBOUND-MGMN-CALL-VIA-E1-1
huntstop
destination-pattern 8.T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/1:D
no register e164

pots-диалпир для пропуска оставшегося исходящего трафика в поток Е1 (3/0) второго провайдера:

dial-peer voice 3 pots

description OUTBOUND-REMAINING-CALLS-VIA-E1-0
huntstop
preference 8
destination-pattern .T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/0:D
no register e164

Замечание:

Преференс этого диалпира должен быть больше, чем pots-диалпира 1001 (описание которого будет дано ниже), иначе входящие со стороны Е1 звонки будут пытаться выйти через Е1 3/0 (и получим мы isdn-switching, который в данном случае никому не нужен).

Тааакс… с pots-leg’ами разобрались, продолжим с voip-leg’ами.

voip-диалпир для «приема» входящего из IP-сети номера с префиксом 009901 перед набранным номером:

dial-peer voice 94 voip
description inbound_peer_4_380-00-01
translation-profile incoming CUT-PREFIX
codec g711alaw
incoming called-number 009901.T

Создадим профиль преобразования АОНа и набираемого номера:

voice translation-profile CUT-PREFIX
translate calling 121
translate called 120

Создадим правило преобразования набираемого (called) номера – «отрежем» лидирующий префикс 009901:

voice translation-rule 120
rule 8 /^009901\(.*\)/ /\1/ type any unknown

Создадим правило преобразования АОНа – заменим любой присланный АОН на нужный нам 380-00-01:

voice translation-rule 121
rule 12 /^.*/ /3800001/

Пример типичного voip-диалпира:

dial-peer voice 78 voip
description TYPICAL-VOIP-PEER
max-conn 2
answer-address 84953800000     // answer-address служит для выбора диалпира в качестве наиболее
// подходящего на основе АОНа звонка, пришедшего из IP-сети.
//В данном случае у нас АОН будет 89453800000
destination-pattern 3800000       // destination-pattern служит для выбора диалпира в качестве
//наиболее подходящего на основе набранного номера звонка, пришедшего из Е1.
session protocol sipv2
session target ipv4:192.168.68.6
dtmf-relay rtp-nte
codec g711alaw
no vad

Все, что нужно мы разрешили-описали, осталась блокировка «левых» звонков, т.е. тех звонков, что не подходят ни под один dial-peer описанные выше, для чего создадим voip-диалпир:

dial-peer voice 1001 voip
description BAD-AON-AND-CALLED-NUM
call-block translation-profile incoming BLOCK    //блокируем звонок из IP сети
huntstop
preference 7
destination-pattern .T
codec g711alaw
session target ipv4:10.10.10.10

По итогу отправляем входящий звонок из Е1 на адрес 10.10.10.10, который маршрутизируется в никуда.
М.б. кто-то предложит лучшее решение ? С удовольствием послушаем.

Маршрутизируем адрес в «/dev/null»:

ip route 10.10.10.10 255.255.255.255 Null0

Создадим профиль и правило трансляции для блокировки «левых» АОНов:

voice translation-profile BLOCK
translate calling 42
!
voice translation-rule 42
rule 1 reject /^.*/

Для понимания, как и какие диалпиры участвуют в «выборах» при звонке и кто из них «победил» вам поможет команда:

debug voice dialpeer all

Будьте аккуратны – ее вывод может быть очень объемным !

В «отслеживании» звонков в/из IP-сети вам поможет команда:

debug ccsip calls

В трассировке звонка через ISDN вам поможет команда:

debug isdn q931

Увидеть логирование отработки правил трансляции номеров вам поможет команда:

debug voice translation

Замечание:

не забывайте давать команду:

terminal monitor

для того, чтобы вывод дебага отображался у вас в консоли (если вы сидите на циске через telnet), иначе он будет тихо складироваться в буфер логов AS5350 и все :)

Выражаю благодарность за помощь в написании статьи Сергею Бабичеву ( ака zaikini )

Ссылки

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftgwrepg.html

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

Автор: Панфилов Алексей (lehis (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Статья: Asterisk: автообзвон (auto-dial out) и обратный звонок (callback) с использованием AGI

Проблема

При организации функции callback на Asterisk`е, когда Asterisk перезванивает и ты пытаешься ввести тоном номер, то нажатые тобой цифры начинают задваиваться, а то и затраиваться.

Причем это могло происходить не всегда и не зависело от аппарата, на котором набирали тоном.

Так же после многочисленных тестов стало точно понятно, что когда идет звонок из «города» на Asterisk, то подобных проблем не возникает, только если сам Asterisk звонит в «город».

VoIP соединение идет так:

E1 <–> Cisco AS5350 (c5350-js-mz.124-15.T11.bin) <–> Asterisk (версия 1.4.29_2)

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

Начали разбор полетов

Для того что бы выявить проблему стало понятно, что нужно подебажить DTMF на самом Asterisk. Как это сделать ?

Пока опыт работы с Asterisk не такой большой как хотелось бы, посему прибегнули к помощи гугла, через минут пять выяснили:

Открываем файл  logger.conf и там ищем строчку:

console => notice,warning,error

В нее дописывем dtmf, получаем:

console => notice,warning,error,dtmf

Сохраняем файл, входим в консоль Asterisk`а:

asterisk -r

И в консоле даем команду:

asterisk*CLI> logger reload

После чего, в той же консоле, задаем уровень дебага, я делал так:

asterisk*CLI> core set debug 3

Далее, для того что бы потестить нажатие кнопок, я внес нехитрые изменения в dialplan:

[dtmf_test]
exten => s,1,Answer()
exten => s,n,Wait(1)
exten => s,n(collect),Read(digito,,11)
exten => s,n,SayDigits(${digito})
exten => s,n,GoTo(collect)
exten => s,n,Hangup

Т.е. поднимаем трубку, ждем ввода 11-ти цифр, а затем проговариваем все что набрали, собственно в этот контекст я перенаправил callback вызовы.

Подготовились, значит можно начинать.

Делаю callback на свою мобилку, начинаю давить цифири на мобиле, в консоле Астериска вижу:

[ДАТА] DTMF[5031]: channel.c:2351 __ast_read: DTMF begin '9' received on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2355 __ast_read: DTMF begin ignored '9' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2283 __ast_read: DTMF end '9' received on SIP/gt-00000015, duration 352 ms
[ДАТА] DTMF[5031]: channel.c:2336 __ast_read: DTMF end passthrough '9' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2351 __ast_read: DTMF begin '8' received on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2355 __ast_read: DTMF begin ignored '8' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2283 __ast_read: DTMF end '8' received on SIP/gt-00000015, duration 376 ms
[ДАТА] DTMF[5031]: channel.c:2336 __ast_read: DTMF end passthrough '8' on SIP/gt-00000015

и т.д. Во, то что надо, дебаг нажатия кнопок есть.

На одно нажатие в дебаге 4-ре строки. Чем дальше я смотрел в дебаг тем больше понимал, что я нажимаю цифирь один раз, а в дебаге она могла появиться и 2 и 3 раза (т.к. после одного нажатия появлялось более 4-х строк).

Смотрим что вообще мы можем «потрогать» в Астериске на тему DTMF.

Открываем файл sip.conf:

relaxdtmf=yes ; Relax dtmf handling
dtmfmode = rfc2833 ; Set default dtmfmode for sending DTMF. Default: rfc2833
 ; Other options:
 ; info : SIP INFO messages
 ; inband : Inband audio (requires 64 kbit codec -alaw, ulaw)
 ; auto : Use rfc2833 if offered, inband otherwise

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

Меняли режимы, ситуация не изменялась. Как работало через раз, так и продолжало работать.

Раз так, то смотреть нужно с обоих сторон, т.е. в какой то момент привлекли и девайс Cisco.

Смотрим что же у нас указано в dial-peer:

dial-peer voice 23 voip
 description 4_outgoing_asterisk
 translation-profile incoming fake_aon
 answer-address 0010.....
 session protocol sipv2
 voice-class codec 20
 dtmf-relay rtp-nte  h245-signal h245-alphanumeric
 no vad

В voice-class перечислены кодеки:

voice class codec 20
 codec preference 1 g723r53
 codec preference 2 g723ar53
 codec preference 3 g723r63
 codec preference 4 g723ar63
 codec preference 5 g729r8
 codec preference 6 g729br8
 codec preference 7 gsmfr
 codec preference 8 g726r16
 codec preference 9 g726r24
 codec preference 10 g726r32
 codec preference 11 g711alaw
 codec preference 12 g711ulaw

Решили ужать выбор кодеков до alaw и ulaw, т.к. тот же режим inband работет только с этими кодеками.

Тоже самое сделали и на Asterisk, запретив использование всех кодеков кроме этих двух, для этого в sip.conf, в настройках peer`а, который смотрит на Cisco, указали:

disallow=all
allow = alaw
allow = ulaw

Снова стали менять режимы в sip.conf, пробовать звонить, пофиг, все как было так и осталось.

Полезли на Cisco.com -> Configuring SIP DTMF Features, в частности интересовали предлагаемый самой циской debug:

Verifying SIP DTMF Support

To verify SIP DTMF support, perform the following steps as appropriate (commands are listed in alphabetical order).

SUMMARY STEPS

1. show running-config
2. show sip-ua retry
3. show sip-ua statistics
4. show sip-ua status
5. show sip-ua timers
6. show voip rtp connections
7. show sip-ua calls

Благодаря команде show sip-ua calls видно какой режим DTMF выбран в данный момент:

Call 1
SIP Call ID                : 12abb76a79d610df282e2b237177bfe5@XX.XXX.XXX.XXX
   State of the call       : STATE_SENT_ALERTING (14)
   Substate of the call    : SUBSTATE_NONE (0)
   Calling Number          : 001000119
   Called Number           : 8916XXXXXXX
   Bit Flags               : 0xC0001C 0x100 0x404
   CC Call ID              : 22371
   Source IP Address (Sig ): XXX.XXX.XXX.XXX
   Destn SIP Req Addr:Port : XXX.XXX.XXX.XXX:5060
   Destn SIP Resp Addr:Port: XXX.XXX.XXX.XXX:5060
   Destination Name        : XXX.XXX.XXX.XXX
   Number of Media Streams : 1
   Number of Active Streams: 0
   RTP Fork Object         : 0x0
   Media Mode              : flow-through
   Media Stream 1
     State of the stream      : STREAM_ADDING
     Stream Call ID           : -1
     Stream Type              : voice+dtmf (1)
     Negotiated Codec         : g711alaw (160 bytes)
     Codec Payload Type       : 8
     Negotiated Dtmf-relay    : rtp-nte
     Dtmf-relay Payload Type  : 101
     Media Source IP Addr:Port: XXX.XXX.XXX.XXX:18936
     Media Dest IP Addr:Port  : XXX.XXX.XXX.XXX:14328
     Orig Media Dest IP Addr:Port : 0.0.0.0:0

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

В Инете (в частности на www.voip-info.org/wiki/view/Asterisk+DTMF) иногда народ советовал прям в dialplan указывать режим DTMF перед набором чего-либо, сделать это можно командой SIPdtmfmode:

SIPDtmfMode(inband|info|rfc2833)

Но это как то тоже не очень спасало. После многочасовых разборок решили глянуть, а что у Asterisk`а на тему vad есть.

Решение

В файле codecs.conf:

; voice activity detection [true / false]
; reduces bitrate when no voice detected, used only for CBR
; (implicit in VBR/ABR)
vad => true

Таксссс.. опять же народ в Инете, при разборках с DTMF, советует с первую очередь гасить vad к чертям, делаем это:

vad => false

Далее была обнаружена вот эта статья «Changing DTMF tone frequency in Asterisk«:

Changing the DTMF tones
The Asterisk module dsp.c contains the definitions for DTMF tones. Just look for a part of the source code that says:

static float dtmf_row[] =
{
    697.0,  770.0,  852.0,  941.0
};
static float dtmf_col[] =
{
    1209.0, 1336.0, 1477.0, 1633.0
};

And change that to:

static float dtmf_row[] =
{
        732.0,  809.0,  894.0, 988.0
        /* 697.0,  770.0,  852.0,  941.0 */
};
static float dtmf_col[] =
{
        1270.0, 1404.0, 1551.0, 1715.0
        /* 1209.0, 1336.0, 1477.0, 1633.0 */
};

This will raise all detected DTMF codes by some 40Hz, enough for Asterisk to become completely tone-blind to existing DTMF codes.


Once you made the change, you must recompile Asterisk by:

  • 1. Stopping Asterisk
  • 2. Go to your Asterisk source directory
  • 3. Enter make clean
  • 4. Enter make
  • 5. Enter make install

Note that you still can send Asterisk DTMF codes to transfer the call, start monitoring or what else – as long as you use the new DTMF tone matrix you just input. This is pretty easy to do with most industrial-grade call handling equipment.

«Ну что ж, не грех попробовать»  - сказали мы и выполнили как написано.

Диалпир на циске был приведен к виду:

dial-peer voice 23 voip
 description 4_outgoing_asterisk
 translation-profile incoming fake_aon
 answer-address 0010.....
 session protocol sipv2
 codec g711alaw
 dtmf-relay rtp-nte
 no vad

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

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

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

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

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