Помогите чайнику! (Поставил в локалке IP-телефонию, а не фурычит!)

[leoshin]

Господа, помогите!
Достался сервак в наследство от старого админа, вроде бы все нормально пашет, но вдруг беда: шеф купил Ip-телефонию, в DNAT-SNAT её прописал, а не фурычит. Работает эта редиска аж по 4 пакетам портов, но как только я подключаю ее напрямую, т.е. в обход сервера, заводится она с пол-тычка. А через сервак - ни в какую. Вот что меня интересует: В файле конфигурации iptables, (который я сам же и создал, т.к. своего там не было), после первой же перезагрузки кроме моих настроек появились еще какие-то, со странными циферями, типа: (12385:0345988). Подскажите, чего они значат, и как они расшифровываются. И еще: по умолчанию , я так понимаю, все порты "задроплены", так как мне их открыть в обе стороны. Желательно, приведите пример хоть для одного порта.
Огромное спасибо!

[Mind Freedom]

Конфиг iptables-то покажи.

[leoshin]

Конфиг iptables-то покажи.

ftp://netcafe.te.ua/iptables.txt

Если поможете, буду очень благодарен!

[t.t]

Это такой проект?? Переношу, и просьба больше такие темы в "проектах" не размещать.

[leoshin]

Извините, но что же мне делать?

[TuLiss]

Извините, но что же мне делать?

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

[Archont]

Извините, но что же мне делать?

Читать документацию к вашей "IP-телефонии", а потом спрашивать на соответствующих форумах.
Хинт: в Voice over IP (VoIP) чаще всего используется 2 основных протокола, H323 и SIP. В обоих протоколах сначала идет обмен сигнальными пакетами по TCP, в которых стороны передают информацию о своих адресах и портах, которые будут использоваться далее. После этого открываются сокеты по UDP, и идет обмен по RTP протоколу, причем в качестве адреса источника и назначения используется информация, полученныя в первой фазе. Поэтому если клиент имеет реальный адрес 192.168.0.10, то и RTP пакеты от противоположной стороны будут адресованы к этому адресу, т.к. именно этод адрес будет передан в первой фазе, т.е. они никогда не попадут к клиенту, и никакой проброс портов не поможет.
Поможет либо использование различных специальных прокси-серверов, либо организация файрвола таким образом, чтобы можно было присвоить клиенту реальный IP адрес (конечно не совпадающий с реальным адресом шлюза).