LINUX.ORG.RU
ФорумAdmin

sip траффик в обход iptables?

 ,


0

1

Добрый день! Ситуация:
iptables -L -t nat -vxn
Chain PREROUTING (policy ACCEPT 448083 packets, 32660394 bytes)
pkts bytes target prot opt in out source destination
448110 32663092 phones all  — * * 0.0.0.0/0 0.0.0.0/0
....................................
Chain phones (1 references)
pkts bytes target prot opt in out source destination
26 2392 DNAT udp  — * * !192.168.0.0/16 0.0.0.0/0 udp dpts:17901:17910 to:192.168.1.112
5 382 DNAT tcp  — * * !192.168.0.0/16 0.0.0.0/0 tcp dpt:11112 to:192.168.1.112

RTP порты на телефоне 17901-17910 его IP в локалке 192.168.1.112

tcpdump -i eth1 host 192.168.1.112
14:57:32.382948 IP hosted.telphin.ru.19722 > 192.168.1.112.17902: UDP, length 172
14:57:32.384154 IP 192.168.1.112.17902 > hosted.telphin.ru.19722: UDP, length 172
14:57:32.402759 IP hosted.telphin.ru.19722 > 192.168.1.112.17902: UDP, length 172
14:57:32.404205 IP 192.168.1.112.17902 > hosted.telphin.ru.19722: UDP, length 172

lsmod говорит, что модулей пережевывающих sip нет.

Module Size Used by
w83627ehf 18647 0
hwmon_vid 1751 1 w83627ehf
coretemp 4968 0
ipmi_si 33634 0
ipmi_msghandler 26300 1 ipmi_si
sunrpc 165859 1
cpufreq_ondemand 7262 4
acpi_cpufreq 6285 1
mperf 1141 1 acpi_cpufreq
ipv6 229795 96
capi 10620 0
capifs 2374 2 capi
kernelcapi 28157 1 capi
iptable_nat 3945 1
nf_nat 16298 1 iptable_nat
iptable_mangle 1235 0
uinput 5228 0
i2c_i801 9016 0
i2c_core 21552 1 i2c_i801
joydev 7306 0
e1000e 162355 0
iTCO_wdt 8980 0
iTCO_vendor_support 2070 1 iTCO_wdt
serio_raw 3589 0
microcode 11149 0
raid1 17323 3
usb_storage 35831 0

DNAT точно работает. Если с удаленного компа сделать tcpdump XX.XXX.XXX.XX 11112 количество пакетов прошедших цепочку растет.

Вопрос: по этому телефону весь день треплются. КАК в счетчике прероутинга может быть 26 пакетов и 2392 байт данных? Как идет траффик и почему в обход фаервола?
При этом, если сделать service iptables restart - все, телефон отваливается и его ни как не поднять! Хотя визуально траффик по портам идет, судя по tcpdump.



Последнее исправление: gich (всего исправлений: 1)

Как идет траффик и почему в обход фаервола?

В обход конкретной цепочи.

При этом, если сделать service iptables restart - все, телефон отваливается и его ни как не поднять!

Так он запускается только после ребута?

Yustas ★★★★
()
Ответ на: комментарий от gich

А какого ### собственно он вокруг нее может идти и как на это повлиять? Ну или хорошо, хотя бы обнаружить это.

gich
() автор топика
Ответ на: комментарий от gich

По прероутингу идёт первый пакет.
Остальные пускаются где-то через --state ESTABLISHED,RELATED, как я понимаю

Yustas ★★★★
()
Ответ на: комментарий от gich

В PREROUTING у тебя прошло 400 тыщ пакетов, по DNAT-правилу идут только пакеты установки соединения, остальные - по conntrack проходят

anonymous
()
Ответ на: комментарий от anonymous

Основная то проблема в том, что несмотря на ping 1-3 ms во все стороны, при соединении получается задержка 3-5, иногда до 10 секунд. ТЕ 192.168.1.112 не слышит того, кто звонит. Звонящий со своей стороны слышит 192.168.1.112. Уже запарился этот глюк лечить.

gich
() автор топика
Ответ на: комментарий от Pinkbyte

И как он лечится?

Ребутом

канал не забит ничем?

В том -то и дело. Буду ось переставлять. Все варианты уже перепробовал. Сменю дистриб.

gich
() автор топика

Запрещать/считать не prerouting, а в forward нужно.

zgen ★★★★★
()
Ответ на: комментарий от gich

Основная то проблема в том, что несмотря на ping 1-3 ms во все стороны, при соединении получается задержка 3-5, иногда до 10 секунд. ТЕ 192.168.1.112 не слышит того, кто звонит. Звонящий со своей стороны слышит 192.168.1.112. Уже запарился этот глюк лечить.

Я не понял. Проблема в том, что у тебя что-то работает, хотя не должно? Или наоборот - не работает то, что работать должно?

Deleted
()
Ответ на: комментарий от Yustas

ТЕ 192.168.1.112 не слышит того, кто звонит. Звонящий со своей стороны слышит

И как он лечится?

на шлюзе ставится sip-proxy(лучший вариант) или steteless nat до него. Разруливал такую-же ситуацию, но у меня был аппаратный маршрутизатор, и пришлось голосовые потоки тащить через voice-proxy (т.е. дать ему лишнюю работу - помимо сигнальной части тащить/согласовывать/перекодировать ещё и потоки)

MKuznetsov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.