sip.conf
| Код: |
| qualifyfreq=60 rpid_update=yes regextenonqualify=yes rtptimeout=60 rtpholdtimeout=300 rtpkeepalive=30 |
мне помогло.
Установлен в виртуальной машине Hyper-V, компоненты интеграции 2.1 установлены
2 синтетических сетевых адаптера, один в локалку, другой в инет.
Установлен Asterisk 1.8.
Есть 2 транка.
Первый -- к MS OCS 2007 R2 Mediation Server, к нему вопросов нет.
Второй -- к провайдеру. Между Астериском и провайдером есть нат, но Астериск в DMZ.
localnet и externip настроена.
Сразу после загрузки все работает замечательно, звонки по всем направлениям между транками и т. п. Однако, спустя часа 2-3 неизбежно отваливается транк до провайдера, и пишет в лог
[Oct 31 11:25:12] WARNING[6635]: chan_sip.c:12294 transmit_register: Probably a DNS error for registration to *@*, trying REGISTER again (after 20 seconds)
[Oct 31 11:25:12] NOTICE[6635]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '*@*' timed out, trying again (Attempt #7)
Перезапуск астериска, перезапуск network не влияют. Перезагрузка всей ОС решает проблему, после перезагрузки все работает как новенькое.
Куда копать, в чем может быть проблема?
если всеравно стоит линукс - зачем в виртуалку пихать астериск?
_________________
Успехов!
Подожду следующего падения и попробую использовать эмулированные сетевухи вместо синтетических.
Странным мне кажется то, что при появлении этой проблемы все остальное сетевое взаимодействие -- по локалке, через нат к провайдеру -- работает. Транк в локалку -- тоже.
Может еще какие варианты решения или диагностики проблемы подскажете? Я сам в линухе нуб, дальше настройки астериска и стандартных сетевых сервисов не ходил.
_________________
MCITP: EA, EMA, VA; MCSA
имеет смысл для начала попробовать в настройках провайдера указать nat=yes, так же удостовериться для для данного peer`а стоит qualify = no (т.к. аплинк имеет полное право НЕ отвечать на запросы option и subscribe )
В последний раз коннект прожил аж 8 часов.
После отвала, соответственно, в
sip show peers мой провыайдер виден как unreachable
sip show registry -- unregistered
причем пока регистрация у прова еще не отвалилась по таймауту (астериск уже не может зарегится, а провайдер его еще считает своим), входящие звонки принимались. Исходящие --нет.
Пинги, ssh и прочее ходят без проблем что в инет,что из инета без проблем. В том числе до VoIP шлюза провайдера, до которого не поднимается транк.
Транк на локалку работает без проблем.
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| [Oct 31 11:25:12] WARNING[6635]: chan_sip.c:12294 transmit_register: Probably a DNS error for registration to *@*, trying REGISTER again (after 20 seconds) [Oct 31 11:25:12] NOTICE[6635]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '*@*' timed out, trying again (Attempt #7) Перезапуск астериска, перезапуск network не влияют. Перезагрузка всей ОС решает проблему, после перезагрузки все работает как новенькое. Куда копать, в чем может быть проблема? |
А можно без фигурной резки увидеть, что пишется вместо '*@*' ?
Ну и это, 'Probably a DNS error' как-то дебагался?
Probably a DNS error -- возникае сие только в описанных условиях -- когда регистрация не возможна.
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| Вместо '*@*' соответственно login@ip_address_of_voip_proviced |
То есть там точно IP-адрес, а не DNS-имя?
| Argon wrote: |
| Probably a DNS error -- возникае сие только в описанных условиях -- когда регистрация не возможна. |
Вопрос был - как-то это дебагалось, а не когда возникает
Не совсем понял смысл фразы "как-то это дебагалось".
_________________
MCITP: EA, EMA, VA; MCSA
Я правильно понимаю, что выставлено verbose >=-5, debug>= 5 и с этими значениями, все что пишет астериск в консоль - это 2 строчки про ошибки?
iptables с каким-нибудь conntrac стоит?
В общем, предлагаю:
в момент X:
а) выкрутить console=...,debug в logger.conf, сказать logger reload и после очередного вылетания тех же ошибок запостить простыню сюда
б) сюда же запостить sudo netstat -anlp | grep /asterisk
в) и lsof -p
г) ping -c 10 (интересует время и потери, а так же их отличие от момента "до Х")
д) сравнить скорость (желательно каким-нибудь scp) через ту же виртуальную сетевуху в момент "до Х" и в Х, после чего тоже сюда запостить
Added after 21 minutes:
a) ничего нового
| Code: |
| [Nov 6 23:09:45] WARNING[2444]: chan_sip.c:12291 transmit_register: Still have a registration timeout for 211688@91.144.148.105 (create_addr() error), 323178 [Nov 6 23:10:05] WARNING[2444]: chan_sip.c:12294 transmit_register: Probably a DNS error for registration to 211688@91.144.148.105, trying REGISTER again (after 20 seconds) [Nov 6 23:10:05] NOTICE[2444]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '211688@91.144.148.105' timed out, trying again (Attempt #14347) [Nov 6 23:10:25] WARNING[2444]: chan_sip.c:12294 transmit_register: Probably a DNS error for registration to 211688@91.144.148.105, trying REGISTER again (after 20 seconds) [Nov 6 23:10:25] NOTICE[2444]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '211688@91.144.148.105' timed out, trying again (Attempt #14348) |
б)
| Code: |
| [root@asterisk ~]# netstat -anlp | grep /asterisk tcp 0 0 0.0.0.0:5060 0.0.0.0:* LISTEN 2246/asterisk tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 2246/asterisk tcp 0 0 10.0.0.50:34825 10.0.0.51:5060 ESTABLISHED 2246/asterisk udp 0 0 0.0.0.0:5000 0.0.0.0:* 2246/asterisk udp 0 0 0.0.0.0:4520 0.0.0.0:* 2246/asterisk udp 0 0 0.0.0.0:5060 0.0.0.0:* 2246/asterisk udp 0 0 0.0.0.0:4569 0.0.0.0:* 2246/asterisk unix 2 [ ACC ] STREAM LISTENING 6775 2246/asterisk /var/run/asterisk/asterisk.ctl |
в)
| Code: |
| (2210 root Nov02 /bin/sh /usr/sbin/safe_asterisk -U asterisk -G asterisk ) [root@asterisk ~]# lsof -p 2210 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME safe_aste 2210 root cwd DIR 253,0 4096 720897 /tmp safe_aste 2210 root rtd DIR 253,0 4096 2 / safe_aste 2210 root txt REG 253,0 735004 5865580 /bin/bash safe_aste 2210 root mem REG 253,0 50848 6062119 /lib/libnss_files-2.5.so safe_aste 2210 root mem REG 253,0 129832 6062965 /lib/ld-2.5.so safe_aste 2210 root mem REG 253,0 1689640 6062983 /lib/libc-2.5.so safe_aste 2210 root mem REG 253,0 20668 6063465 /lib/libdl-2.5.so safe_aste 2210 root mem REG 253,0 13084 6062984 /lib/libtermcap.so.2.0.8 safe_aste 2210 root mem REG 253,0 56454688 7026850 /usr/lib/locale/locale-archive safe_aste 2210 root mem REG 253,0 25462 7111037 /usr/lib/gconv/gconv-modules.cache safe_aste 2210 root 0r CHR 1,3 1215 /dev/null safe_aste 2210 root 1u CHR 5,1 682 /dev/console safe_aste 2210 root 2u CHR 5,1 682 /dev/console |
(2246 asterisk Nov02 /usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c )
lsof -p 2246
выдал очень много всего, могу файл приложить.
г) после беды
| Code: |
| [root@asterisk ~]# ping -c10 91.144.148.105 PING 91.144.148.105 (91.144.148.105) 56(84) bytes of data. 64 bytes from 91.144.148.105: icmp_seq=1 ttl=122 time=2.29 ms 64 bytes from 91.144.148.105: icmp_seq=2 ttl=122 time=1.68 ms 64 bytes from 91.144.148.105: icmp_seq=3 ttl=122 time=2.33 ms 64 bytes from 91.144.148.105: icmp_seq=4 ttl=122 time=1.78 ms 64 bytes from 91.144.148.105: icmp_seq=5 ttl=122 time=1.73 ms 64 bytes from 91.144.148.105: icmp_seq=6 ttl=122 time=1.68 ms 64 bytes from 91.144.148.105: icmp_seq=7 ttl=122 time=1.72 ms 64 bytes from 91.144.148.105: icmp_seq=8 ttl=122 time=1.65 ms 64 bytes from 91.144.148.105: icmp_seq=9 ttl=122 time=2.34 ms 64 bytes from 91.144.148.105: icmp_seq=10 ttl=122 time=2.16 ms --- 91.144.148.105 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9006ms rtt min/avg/max/mdev = 1.658/1.941/2.340/0.285 ms |
д) Не понял, скорость между чем и чем? До провайдера или интерейейса? Умею скорость мерять прогой iperf
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| (2246 asterisk Nov02 /usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c ) lsof -p 2246 выдал очень много всего, могу файл приложить. |
Можно файлом, да.
Если после | grep -v /usr/lib/asterisk стновится сильно меньше, то можно сюда.
| Argon wrote: |
| д) Не понял, скорость между чем и чем? До провайдера или интерейейса? Умею скорость мерять прогой iperf |
Между ценосью и чем-нибудь снаружи, что идет через тот же интерфейс, можно и iperf'ом
Имеет смысл запустить tcpdump на соотв. интерфейсе, например с флагами -lnvvs0 dst host 91.144.148.105 and port 5060
и посмотреть, есть ли там что-то на тему SIP REGISTER. Скорее всего нет, но все же..
Вообще, конечно за такие подробные дебаги надо карать горе-плагламистов.
Дальше самым продуктивным было бы на мой взгляд пропатить chan_sip.c на тему дополнительных логов перед каждым return() в create_addr() и особенно в create_addr_from_peer(),
выключив перед этим qualify. Если есть возможность [пере]собрать из исходников - готов патчик какой-нибудь сделать. Без этого гадать по фотографии уже как-то плохо получается. Да и не знаток я линуксов.
Да, а внешне система себя нормально ведет? Время туда-сюда не скачет, остальные процессы внутри тоже живут и здравствуют, памяти там всем хватает?
На всякий случай выложите еще и top какой-нибудь
| Code: |
| asterisk*CLI> sip set debug ip 91.144.148.105 SIP Debugging Enabled for IP: 91.144.148.105 [Nov 1 12:28:01] WARNING[4229]: chan_sip.c:12294 transmit_register: Probably a DNS error for registration to 711143@91.144.148.105, trying REGISTER again (after 20 seconds) [Nov 1 12:28:01] NOTICE[4229]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '711143@91.144.148.105' timed out, trying again (Attempt #2442) Reliably Transmitting (no NAT) to 91.144.148.105:5060: OPTIONS sip:91.144.148.105 SIP/2.0 Via: SIP/2.0/UDP 91.144.175.67:5060;branch=z9hG4bK0753c7db Max-Forwards: 70 From: "asterisk" ;tag=as511f4b55 To: Contact: Call-ID: 63685ea27b7b9b1f3ed462ef30a3515c@91.144.175.67:5060 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 1.8.0 Date: Mon, 01 Nov 2010 09:28:04 GMT Session-Expires: 1800 Min-SE: 90 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 --- Retransmitting #1 (no NAT) to 91.144.148.105:5060: OPTIONS sip:91.144.148.105 SIP/2.0 Via: SIP/2.0/UDP 91.144.175.67:5060;branch=z9hG4bK0753c7db Max-Forwards: 70 From: "asterisk" ;tag=as511f4b55 To: Contact: Call-ID: 63685ea27b7b9b1f3ed462ef30a3515c@91.144.175.67:5060 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 1.8.0 Date: Mon, 01 Nov 2010 09:28:04 GMT Session-Expires: 1800 Min-SE: 90 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 ... --- Really destroying SIP dialog '63685ea27b7b9b1f3ed462ef30a3515c@91.144.175.67:5060' Method: OPTIONS Reliably Transmitting (no NAT) to 91.144.148.105:5060: OPTIONS sip:91.144.148.105 SIP/2.0 Via: SIP/2.0/UDP 91.144.175.67:5060;branch=z9hG4bK72f52aa2 Max-Forwards: 70 From: "asterisk" ;tag=as5a7ed16c To: Contact: Call-ID: 16a0a8a211c71ea456eba6590f9ad580@91.144.175.67:5060 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 1.8.0 Date: Mon, 01 Nov 2010 09:28:18 GMT Session-Expires: 1800 Min-SE: 90 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 |
_________________
MCITP: EA, EMA, VA; MCSA
Поэтому для вот этих пакетиков интересно посмотреть, видно ли их в tcpdump'е (т.е. улетают ли они из астериска, не глотает ли их сетевой стек и файрволл) и есть ли на них ответ (опять же в tcpdump).
_________________
MCITP: EA, EMA, VA; MCSA
Ни какой разницы!
Как дампы делать?
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| Как дампы делать? |
Во-первых таки давайте отключим qualify
Дампы - утилитой tcpdump.
Например tcpdump -i interface_name -lns0 -w xxx.cap host 91.144.148.105 and port 5060
interface_name - тот, через который должны улетать/прилетать пакеты на этот хост. Если интерфейсы вылета/прилета - разные, то дампим на обоих.
xxx.cap - фвйл, куда запишутся пакеты
Это делаем в виртуальной машине. Если соотв. видим (наиболее вероятное), что пакеты улетают, но не прилетают - начинаем копать с сетевым анализатором в других местах сети.
Помнится, даже в windows был какой-то встроенный унылый анализатор трафика
В общем интересен трафик за K минут до момента X и минут тоже К после момента Х, K >= 10
А если серьезно, я бы просто запустил tcpdump сразу после перезапуска виртуалки и все
Правда не знаю, как потом покоцать файл, чтобы выложить без сигнализации по разговорам.
Если что, то сойдет вывод чего-то типа tcpdump -r xxx.cap -lnvvs0
| Code: |
| [root@asterisk ~]# tcpdump -s 1500 -i seth1 -w /argon/dump2.pcap tcpdump: listening on seth1, link-type EN10MB (Ethernet), capture size 1500 bytes 1632 packets captured 1632 packets received by filter 0 packets dropped by kernel [root@asterisk ~]# tcpdump -s 1500 -i seth1 -w /argon/dum3.pcap host 91.144.148.105 and port 5060 tcpdump: listening on seth1, link-type EN10MB (Ethernet), capture size 1500 bytes 93 packets captured 93 packets received by filter 0 packets dropped by kernel |
В дампах ни одного слова Register или логина для регистрации нету.
Мой вывод -- из Астериска в сеть не пытается посылать данные о перерегистрации, то же было и при дебаге SIP внутри Астериска.
_________________
MCITP: EA, EMA, VA; MCSA
http://narod.ru/disk/27397364000/dump2.pcap.html
http://narod.ru/disk/27397385000/dump3.pcap.html
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: | ||
| Сделал |
| Code: |
| [root@asterisk ~]# tcpdump -s 1500 -i seth1 -w /argon/dump2.pcap tcpdump: listening on seth1, link-type EN10MB (Ethernet), capture size 1500 bytes 1632 packets captured 1632 packets received by filter 0 packets dropped by kernel [root@asterisk ~]# tcpdump -s 1500 -i seth1 -w /argon/dum3.pcap host 91.144.148.105 and port 5060 tcpdump: listening on seth1, link-type EN10MB (Ethernet), capture size 1500 bytes 93 packets captured 93 packets received by filter 0 packets dropped by kernel |
В дампах ни одного слова Register или логина для регистрации нету.
Мой вывод -- из Астериска в сеть не пытается посылать данные о перерегистрации, то же было и при дебаге SIP внутри Астериска.
Я не понимаю. Я просил отключить qualify - так нет, не отключаем и молчим. То, что его никто не отключал выясняется только в следующем посте.
Просил дампить на обеих интерфейсах, если пакеты прилетают на разные - тоже не сделано.
Просил выложить получившееся в каком-то виде - тоже нету.
Есть только вывод, что виноват астериск.
Это все "MCITP: EA, EMA, VA; MCSA" такие альтернативно одаренные?
qualify плох в данном случае тем, что если он включен, а пир недоступен, то все попытки регистрации будут сразу отбиваться прямо внутри астериска, что в общем-то логично.
Про это я писал пару постов назад.
По преждему жду дампа в том числе и входящих пакетов.
| Quote: |
| Скажи мне, Argon, какой ip "в тырнет", а какой "в локалку" в твоей конфиге? |
В инет seth1 (192.168.0.50), в локалку seth0 (10.0.0.50), роутер 192.168.0.11, провайдер 91.144.148.105.
| Quote: |
| Можешь снять дамп, сразу после рестарта с успешной ситуаций? |
Могу (в понедельник будет доступ к оборудованию), прошу указать откуда и куда нужен дамп, желательно в виде полной команды tcpdump.
bird_of_Luck
| Quote: |
| Я просил отключить qualify - так нет, не отключаем и молчим. То, что его никто не отключал выясняется только в следующем посте. |
Я попросил объяснить почему это важно, так как в моей конфиге его включение/отключение на вероятность наступления проблемы этого топика не влияет. Зато в sip show peers сразу видно, наступила проблема или нет.
| Quote: |
| Просил дампить на обеих интерфейсах, если пакеты прилетают на разные - тоже не сделано. |
К SIP провайдеру астериск подключен только одним интерфейсам.
| Quote: |
| Просил выложить получившееся в каком-то виде - тоже нету. |
Выложено в посте Сб Ноя 13, 2010 11:29.
| Quote: |
| Это все "MCITP: EA, EMA, VA; MCSA" такие альтернативно одаренные? |
Не могу оценить этого юмора. У меня полно работы по основному профилю, а линуксом и астериском занимаюсь по мере появления возможности.
| Quote: |
| qualify плох в данном случае тем, что если он включен, а пир недоступен, то все попытки регистрации будут сразу отбиваться прямо внутри астериска, что в общем-то логично. Про это я писал пару постов назад. |
Спасибо, теперь понял. По предыдущему посту
| Quote: |
| если у пира включен qualify и он недоступен, то create_addr_from_peer() сразу обломается. |
-- не очень понял.
| Quote: |
| По преждему жду дампа в том числе и входящих пакетов. |
Чем плохи те, что я выложил? Как сделать правильные?
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| Я попросил объяснить почему это важно, так как в моей конфиге его включение/отключение на вероятность наступления проблемы этого топика не влияет. Зато в sip show peers сразу видно, наступила проблема или нет. |
В следующем посте после моего запроса ни про какие обьяснения не было. было "Сделал" и все. И только уже после вопроса про qualify вдруг выяснилось, что оказывается не отключен и надо обьяснить, зачем же его отключать
| Argon wrote: | ||||
| |
| Quote: |
| Просил дампить на обеих интерфейсах, если пакеты прилетают на разные - тоже не сделано. |
К SIP провайдеру астериск подключен только одним интерфейсам.
| Quote: |
| Просил выложить получившееся в каком-то виде - тоже нету. |
Выложено в посте Сб Ноя 13, 2010 11:29.
| Argon wrote: | ||
| |
| Quote: |
| Это все "MCITP: EA, EMA, VA; MCSA" такие альтернативно одаренные? |
Не могу оценить этого юмора. У меня полно работы по основному профилю, а линуксом и астериском занимаюсь по мере появления возможности.
А это не юмор, увы. Имеет смысл все же почитать http://segfault.kiev.ua/smart-questions-ru.html
| Argon wrote: | ||
| |
| Quote: |
| если у пира включен qualify и он недоступен, то create_addr_from_peer() сразу обломается. |
-- не очень понял.
Да, я не обьяснил достаточно подробно. В самом начале из логов:
| Quote: |
| [Nov 6 23:09:45] WARNING[2444]: chan_sip.c:12291 transmit_register: Still have a registration timeout for 211688@91.144.148.105 (create_addr() error), 323178 |
create_addr() практически сразу, как только выясняет, что мы регистрируемся на существующем пире вызывает create_addr_from_peer(), поведение которого зависит от включенного qualify
| Quote: |
| По преждему жду дампа в том числе и входящих пакетов. |
Чем плохи те, что я выложил? Как сделать правильные?[/quote]
В обоих дампах видно только исходящие пакеты. Если это дампы ситуаций, когда "все плохо", а вообще входящий трафик видно - то все примерно как и предполагалось:
Астериск раз в минуту шлет SIP OPTIONS (проверка qualify) а дальше либо
* его за частые запросы банит робот на сервере провайдера, работа после ребута обьясняется тем, что робот быстро разбанивает т.к. флуд с его точки зрения кончился (система перегружается, OPTIONS никто не шлет)
* пакет до провайдера не доходит (переполняется таблица ната, таблица conntrack, сносит крышу у сетевой карты, etc...) - тут надо, как я и говорил выше, смотреть еще и в других местах (на хост-машине, на роутерах дальше и тд), дабы найти место, где все-таки пакет теряется
Если это дампы когда "все хорошо", то тогда входящие пакеты приходят куда-то еще и надо их задампать тоже
| Quote: |
| В следующем посте после моего запроса ни про какие обьяснения не было. было "Сделал" и все. |
Сожалею, что не совсем очевидно выразился, когда написал слово "сделал" и следующий за ним листинг конкретных команд и ответов.
| Quote: |
| * его за частые запросы банит робот на сервере провайдера, работа после ребута обьясняется тем, что робот быстро разбанивает т.к. флуд с его точки зрения кончился (система перегружается, OPTIONS никто не шлет) |
Еще раз говорю, что с отключенным квалифаем ничего не меняется. Будет в следующий раз доступ к оборудованию -- дождусь когда без квалифая ситуация "все плохо" случится и сделаю дампы.
| Quote: |
| * пакет до провайдера не доходит (переполняется таблица ната, таблица conntrack, сносит крышу у сетевой карты, etc...) - тут надо, как я и говорил выше, смотреть еще и в других местах (на хост-машине, на роутерах дальше и тд), дабы найти место, где все-таки пакет теряется |
На хосте есть и другие виртуалки, они работают без проблем. Насчет роутеров дальше -- а как на них влияет перезагрузка гостевой виртуальной машины?
Проблема дальше по сети менее вероятна, чем просто не выход пакетов из вм с астериском. Либо астериск перестает посылать пакеты, содержащие адрес внешнего интерфейса роутера (прописан в конфиге)? Тогда не удивительно, если обратно не возвращается ничего.
| Quote: |
| А это не юмор, увы. Имеет смысл все же почитать http://segfault.kiev.ua/smart-questions-ru.html |
Благодарю, что по-прежнему пытаетесь помочь мне и технически, и воспитательски. Знаком с сим текстом, и не нахожу грубых несоответствий своих постов с этими правилами.
_________________
MCITP: EA, EMA, VA; MCSA
| Argon wrote: |
| В дампах -- ситуация когда все было плохо. |
Ага. Это упрощает.
| Argon wrote: | ||
| |
| Quote: |
| * его за частые запросы банит робот на сервере провайдера, работа после ребута обьясняется тем, что робот быстро разбанивает т.к. флуд с его точки зрения кончился (система перегружается, OPTIONS никто не шлет) |
Еще раз говорю, что с отключенным квалифаем ничего не меняется. Будет в следующий раз доступ к оборудованию -- дождусь когда без квалифая ситуация "все плохо" случится и сделаю дампы.
Нет, qualify в принципе отключать уже не нужно
| Argon wrote: | ||
| |
| Quote: |
| * пакет до провайдера не доходит (переполняется таблица ната, таблица conntrack, сносит крышу у сетевой карты, etc...) - тут надо, как я и говорил выше, смотреть еще и в других местах (на хост-машине, на роутерах дальше и тд), дабы найти место, где все-таки пакет теряется |
На хосте есть и другие виртуалки, они работают без проблем. Насчет роутеров дальше -- а как на них влияет перезагрузка гостевой виртуальной машины?
Проблема дальше по сети менее вероятна, чем просто не выход пакетов из вм с астериском. Либо астериск перестает посылать пакеты, содержащие адрес внешнего интерфейса роутера (прописан в конфиге)? Тогда не удивительно, если обратно не возвращается ничего.
Вариантов в жизни может быть много, иногда лучше проверить, чем быть уверенным, что в месте X все работает так, как и должно и потратить еще кучу времени из-за неправильных предположений.
Пока самый рабочий вариант - это проблема на стыке виртуальной машины и хост-системы.
Потому как в вышеприведенных дампах (а посмотреть их под windows запросто можно wireshark'ом, например) видно, что qualify (SIP OPTIONS) шлется и в поле Contact передается адрес ..175.67:5060
tcpdump (точнее, BPF) снимает пакеты перед всякими файрволлами на входе и после них на выходе. То есть, с т.з. гуестовой операционной системы пакет улетел (этот хук (отдающий пакеты в BPF, который выдает их tcpdump'у) вызывается уже примерно в радиусе драйвера сетевой карты, по крайней мере в FreeBSD)
Также завтра будет совершенно новый роутер до провайдера, и тип подключения будет уже не через нат, а напрямую в сеть.
_________________
MCITP: EA, EMA, VA; MCSA
Выключил Qualify.
Между сервером и voip провайдером ната нет, прямая маршрутизация, сетевуха сервера прямо в интернете с белым адресом.
Всё та же фигня!
| Code: |
| [Nov 19 20:18:34] NOTICE[16397]: chan_sip.c:12209 sip_reg_timeout: -- Registration for '211688@91.144.148.105' timed out, trying again (Attempt #12) |
_________________
MCITP: EA, EMA, VA; MCSA
Во-вторых все прежние советы в силе:
Делаем tcpdump в этой центоси, смотрим, улетает ли пакет и есть ли ответ.
Если пакет улетает, а ответа нет - смотрим дальше насколько можно, на маршрутизаторе например. Если там этот пакет тоже видно и видно, что он летит дальше, а ответа так и нет - надо общаться с SIP-провайдером, чего у них там происходит, видят ли они в эти моменты пакеты