После подключения второго прова к W2 DFL-800(210) стала неопределенным образом проявляться односторонняя слышимость на VoIP шлюзах подключенных в DMZ т.е. исходяший голос слышен, а входящий нет.

Предположил что косяк на стороне второго прова потому что с первым уже много лет по этой теме проблем не возникало. Зацепил один VoIP шлюз напрямую с белым IP к каналу второго прова - все нормально работает.

Стал разбираться и выяснил следующее:
Если VoIP шлюзы подключаются к SIP оператору по маршрутам в W1, там где статическая маршрутизация до ADSL модема, то все работает.
Нормально проходит SIP регистрация, нормально проходит звонок, нормально идет исходящий голосовой траф и нормально входящий. Все работает, зафиксирована двухсторонняя слышимость.

А вот если VoIP шлюзы подключаются к SIP оператору по маршрутам в W2, там где NAT на DFL-ке, то почти все нормально.
SIP регистрация проходит. Исходящий звонок совершается. Исходящий голос слышен. Входящий голос - тишина.
Где то не проходит входящий RTP до VoIP шлюза.

Балансирока, failover, VPN и т.п. к данной теме не относятся, хотя там тоже есть ряд вопросов. Но сейчас не об этом.

Пока ковыряюсь с одним шлюзом.

Детали по теме.
W1: Статическая маршрутизация до ADSL модема без правил NAT на DFL.
NAT поднят непосредственно на модеме. На нем же разруливается форвардинг через NAT на VoIP шлзюзы, проброс VPN до W1, e.t.c. Там же DynDNS клиент.

W2: От другого прова непосредственно в DFL идет Ethernet c одним белым статическим адресом. Т.е. NAT для W2 поднимается непосредственно на DFL.

В DMZ DFL-ки живут разные DMZ хосты и, в частности, VoIP шлюзы.


Правила в студию:
Чтобы не возникало вопросов, типа что это за сервис такой сразу уточняю:
Сделана дополнительная группа сервисов для проброса на шлюз по аналогии с другим каналом
Linksys_Redirect: tcpupd 40000-47999 + tcp 5061-5399 + udp 5061-5399 через стандарный SIP ALG.
Так много всего потому, что это уже заморочки самого шлюза Linksys SPA-8000.

MainOffice_VoIP_GW - группа IP адресов всех VoIP шлюзов в DMZ главного офиса.
spa-8000-main_IP - адрес того шлюза с которым экспериментирую.

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

DMZ_to_W2
1. allow_SPA_all_to_INKO
NAT
Service:all_tcpudp;
Source: DMZ -> MainOffice_VoIP_GW; Destination: w2_Inko -> all-nеts
(пока так, лишь бы заработало, лишнее отрежу потом)

W2_to_DMZ
1. Redirect_VoIP_to_Linksys
SAT
Service: Linksys_Redirect
Source: any -> all-nets ; Destination: core -> inko_ip

SAT: Translate the -> Destination IP to New IP Address -> spa-8000-main_IP

2. Allow_VoIP_Linksys_to_INKO_ip
Allow
Service:Linksys_Redirect
Source: Source: w2_Inko -> all-nеts; Destination: DMZ -> spa-8000-main_IP
(это правило пробовал через NAT - эффект то же, односторонняя слышимость)

Предположительно что-то не так в группе правил W2_to_DMZ.
Но я не врубаюсь что именно, и не понимаю, где застревает входящий UDP траф.

Ставить отдельный машрутизатор для W2 не хочется. Хочу разрулить проблему непосредственно на DFL.
Хотя со статикой на DFL и дополнителным машрутизатром для W2 на котором поднят NAT все работает.
(Все по аналогии с W1, на котором все работает)
В лабораторках подставлял простенький домашний WiFi маршутизатор (Zyxel NBG334W) и разруливал NAT на нем.

ЗЫ: До решения проблемы временно отрубил второго прова на фиг, чтобы VoIP шлюзы не косячили. Желательно бы тему разрулить до понедельника.

По идее проброс осуществляется парой правил. Одно правило SAT, второе Allow. Причем "откуда" и "куда" указываются одинаковыми. То есть в вашем случае надо указать

W2_to_DMZ
1. SAT: Source: w2_inko - all_nets; Destination: core - inko_ip; SAT -> spa-8000-main_ip
2. Allow: Source: w2_inko - all_nets; Destination: core - inko_ip.

Нужно, чтобы приход пакетов разрешался с w2 на core - inko_ip, а оттуда их уже SAT прокинет.

У Linksys/Sipura есть параметр внешнего адреса. Какое его значение установлено у вас? Уж не белый адрес WAN1?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

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

Все VoIP GW живут в DMZ. Псевдостатика (DHCP c привязкой к MAC).
DHCP поднят непосредственно на DFL к интерфейсу DMZ. По этому о белых адресах для VoIP GW либо серых провайдерских говорить не имеет смысла.

Соответственно, все VoIP GW, включая Linksys SPA-8000 настроены на получение адресов исключительно по DHCP.

Что и происходит.

Хотя, чем черт не шутит, еще раз проверил - Шлюзы честно получают те адреса, которые и задумано. И 28 маска тоже получается шлюзами, как задумано.



Нет, точно, не белый из W1.
Тогда, даже теоретически, если бы и работал, то работал бы только один VoIP GW, для всех остальных хостов был бы конфликт адресов

Я уже писал, что для W1 серые адреса и статическая маршрутизация до ADSL модема. NAT для W1 поднят непосредственно на модеме и, соответственно, белый адрес, через который идет маршрут для W1 живет непосредственно на модеме.

Вот это скорее всего и есть мой косяк.
Уже переписал правила. Сегодня в обед проверю, воткну соску от второго прова и, соответственно, выткну первого, чтобы маршруты переключились и уж точно шли мимо балансировки чисто на W2.

Где ни-ть в 14:30 MSK отпишусь по результату.

Во-первых, избавьтесь от двойного NAT. Это по факту зло, а для VoIP's RTP - особенно.

Во-вторых, я имел ввиду не адрес на шлюзе, а внешний адрес, указанный в параметрах шлюза.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Вот именно это и было моим косяком

На канале второго прова шлюзы начали полноценно заводиться.

Спасибо за то что ткнул носом

Да не за что

К вам же на второй интерфейс приходят пакеты типа
<инет адрес> <inko_ip> : Linksys_redirect
а не типа
<инет адрес> <некий внутренний адрес> : Linksys_redirect
Вот их вы и должны разрешить. А уж SAT правило их дальше пробросит.
Вообще все, что пробрасывается, нужно разрешать для прихода именно на внешний адрес интерфейса. Не знаю, как-то коряво объяснил... Но думаю, что понятно

Просто после iptables и pf я еще не до конца въехал в термины и грамматику DFL

Есть еще трабла с VoIP. В режиме failover шлюзы не хотят перерегистяться на альтернативном маршруте.
С вероятностью ~100% уверен, что это какие то мои косяки с альтернативной маршрутизацией. Но, не буду захламлять эту тему. Создам новую.

Перерегистрация это вообще песня, если честно.

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

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

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Какой такой gatekeeper? Это ведь SIP, а не H323!!!



Для SIP это не совсем верно. Шлюз рвется перерегистрироваться на sip proxy, когда у него заканчивается Register Expires (период регистрации).
Это, обычно, 2-3 минуты.

Выкинул VoIP шлюзы из балансировки и загнал на альтернативную таблицу маршрутизации.
В балансировке в основной таблице маршруты в I-Net у меня с метрикой 250. В альтернативной таблице, соответственно, повесил метрики 200 для основного канала и 220 для резервного.

Все остальное меньше.

Протрассировал маршруты - все вроде бы четко отщелкивет.
В альтернативной таблице и основной и резервный маршруты мониторятся через гуглевские 8.8.8.8 и 8.8.4.4.

Но "радость" в следующем: Заклиниваю линк на основном маршруте (вытыкаю телефонный кабель из ADSL, даже не дергая RJ45 из W1)
Жду полторы минутки пока замониторенные маршруты перещелкнутся во всех таблицах. (Перещелкиваются, вроде, нормально.)

Дальше жду 2-3 минуты пока VoIP шлюзы разрегистрируются по старому мертвому маршруту. И после этого тишина...
Но судя по лампочкам DFL-ки, от шлюзов гонится конкретный траф на регистрацию в W2 и ни чего не происходит.

Что характерно, когда живы оба маршрута я отрубаю поочереди правила для DMZ_to_W1 (allow) или для DMZ_to_W2 (nat) то разрегистрированные шлюзы нормально регистрируются либо по одному маршршруту, либо по другому. Входящий RTP ни где не стрянет. Слышимость двухсторонняя.

Я не врубаюсь - это мой косяк (возможно, но не врубаюсь в чем), косяк DFL-ки (хотя не очень похоже), косяк прошивки шлюзов (но почему три разных шлюза (Zyxel, SPA-8000 и SPA 2102 ведут себя одинаково?) и все же косяк SIPNET?

В том, что на каналах обоих провов нет косяков по этой теме я уверен на 99.99%.

В какую сторону хоть рыть?
IMHO, на SIPNET пока еще наезжать рановато...

Эх, был бы свой Asterisk под руками - куда проще было бы багу отловить...

ЗЫ: Еще одна штука выяснилась. Если выткнуть оба WAN и дождаться когда шлюзы разрегистрируются (до 3 мин.), а потом воткнуть WAN1, то шлюзы нормально регистрятся по этому маршруту W1.
Если операцию с вытыканием обоих WAN повторить, а потом воткнуть WAN2, то шлюзы уже нормально регистрятся по маршруту W2.

Ну, глюки провайдера (SipNet) исключать не стоит. Проверяется все достаточно просто - в софтах DFL выше 2.25 есть встроенный снифер (команда pcapdump). Снимите им или компьютером при помощи управляемого свитча с зеркалом дамп того что происходит и смотрите...

PS Под гейткипером я имею ввиду SIP сервер, сорри за некорректный термин.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

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

Ну, тогда можно либо подождать, либо пока обходиться встроенными в DFL средствами. Бездумно pcapdump'ом не поснифать - доступно лишь 500кб, но определенный трафик - вполне реально.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc