tandberg iptables

[ventru22]

Доброго времени суток!
Нужна помощь коллективного разума.
Досталась мне от прошлого админа железка, Tandberg TTC7-08, предназначена для видеоконференций по протоколу h.323, редкая и дорогущая.
Не умеет работать через прокси, весь трафик вещает по UDP, по определенным портам и как написано в офф мануале не знает что такое nat, однако если я делаю:

iptables -A POSTROUTING -t nat -s $IP_железки -o eth0 -j MASQUERADE

где eth0 - смотрит в инет, то как ни странно подключается, но с черным экраном, вместо списка доступных конференций. Узнавал у провайдера, канал не режется, все порты для работы h.323 открыты, сама железка располагается за шлюзом на ubuntu 10.04.
Как завернуть UDP трафик, без помощи nat, на заведомо известный IP, средствами iptables?
Пользуемся ей раз в пару месяцев, она так и лежит не настроенная

[fisher74]

Код: [Выделить]

sudo iptables -t nat -A PREROUTING -i eth0 -d $Global_IP -p udp -j DNAT --to-destination $IP_железкиНо это грубое поделие. Нужно изучить всё-таки взаимодействие клиента с привратником и с другими клиентами. возможно, что клиент определяет свой IP и выдаёт его привратнику. ...
Извините, я давно пробегал по диагонали работу видеоконференций, многое не запечатлилось в памяти.

[ventru22]

Этот способ не сработал, вообще не видит пункт назначения. Железка цепляется напрямую к вещательному хосту, где стоит точно такая же железка, без привратников.
Пользователь решил продолжить мысль 06 Сентября 2011, 11:59:01:вот как идет трафик:
eth0 - смотрит в инет
eth1 - смотрит в локалку
192.168.0.43 - внутренний ip железки

(Нажмите, чтобы показать/скрыть)

# tcpdump -i eth0 -v -vv host 192.168.0.43

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:44:22.761314 IP (tos 0x80, ttl 63, id 32666, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.43.11050 > <IP_вещающего_хоста>.1720: Flags S, cksum 0x05dc (correct), seq 3010464553, win 16384, options [mss 1460,nop,wscale 0,nop,nop,TS val 1474765 ecr 0], length 0
13:44:25.761209 IP (tos 0x80, ttl 63, id 32667, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.43.11050 > <IP_вещающего_хоста>.1720: Flags S, cksum 0x04b0 (correct), seq 3010464553, win 16384, options [mss 1460,nop,wscale 0,nop,nop,TS val 1475065 ecr 0], length 0
а вот что происходит на eth1:

# tcpdump -i eth1 -v -vv host 192.168.0.43
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:49:27.292653 IP (tos 0x80, ttl 64, id 32668, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.43.11052 > <IP_вещающего_хоста>.1720: Flags S, cksum 0x1052 (correct), seq 2268247546, win 16384, options [mss 1460,nop,wscale 0,nop,nop,TS val 1505217 ecr 0], length 0
13:49:30.292577 IP (tos 0x80, ttl 64, id 32669, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.43.11052 > <IP_вещающего_хоста>.1720: Flags S, cksum 0x0f26 (correct), seq 2268247546, win 16384, options [mss 1460,nop,wscale 0,nop,nop,TS val 1505517 ecr 0], length 0
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

и ничего не работает

после применения
iptables -A POSTROUTING -t nat -s 192.168.0.43/24 -o eth0 -j MASQUERADE

железка подключается к конфе, но черный экран. в этот момент tcpdump на eth0 молчит а вот на eth1 вот такая картина:

(Нажмите, чтобы показать/скрыть)

    192.168.0.43.2454 > <IP_вещающего_хоста>.65276: [no cksum] UDP, length 172
13:53:40.352093 IP (tos 0x80, ttl 64, id 37833, offset 0, flags [none], proto UDP (17), length 580)
    192.168.0.43.2456 > <IP_вещающего_хоста>.65270: [no cksum] UDP, length 552
13:53:40.354742 IP (tos 0x80, ttl 64, id 37834, offset 0, flags [none], proto UDP (17), length 200)
    192.168.0.43.2454 > <IP_вещающего_хоста>.65276: [no cksum] UDP, length 172
13:53:40.362315 IP (tos 0x80, ttl 64, id 37835, offset 0, flags [none], proto UDP (17), length 905)
    192.168.0.43.2456 > <IP_вещающего_хоста>.65270: [no cksum] UDP, length 877
13:53:40.374771 IP (tos 0x80, ttl 64, id 37836, offset 0, flags [none], proto UDP (17), length 200)
    192.168.0.43.2454 > <IP_вещающего_хоста>.65276: [no cksum] UDP, length 172
13:53:40.394820 IP (tos 0x80, ttl 64, id 37837, offset 0, flags [none], proto UDP (17), length 200)
    192.168.0.43.2454 > <IP_вещающего_хоста>.65276: [no cksum] UDP, length 172
13:53:40.402107 IP (tos 0x80, ttl 64, id 37838, offset 0, flags [none], proto UDP (17), length 283)
    192.168.0.43.2456 > <IP_вещающего_хоста>.65270: [no cksum] UDP, length 255
13:53:40.402458 IP (tos 0x80, ttl 64, id 37839, offset 0, flags [none], proto UDP (17), length 583)
    192.168.0.43.2456 > <IP_вещающего_хоста>.65270: [no cksum] UDP, length 555

старый админ говорит, что у него работало так:

iptables -A OUTPUT -s $IP_вещающего_хоста -p udp -j ACCEPT
iptables -A OUTPUT -s $IP_вещающего_хоста -p tcp -j ACCEPT

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

[fisher74]

Этот способ не сработал, вообще не видит пункт назначения. Железка цепляется напрямую к вещательному хосту,

А маскарад-то надо было оставить. А Вы его видимо "2били"

    iptables -A OUTPUT -s $IP_вещающего_хоста -p udp -j ACCEPT
    iptables -A OUTPUT -s $IP_вещающего_хоста -p tcp -j ACCEPT

Бред. Цепочка OUTPUT в этом процессе вообще не участвует

А Вы нам можете всё-таки все правила показать, а не выжимки? Вы же не говорили, что у Вас там запрещающие правила толпятся.
ИМХО

Код: [Выделить]

sudo iptables -t nat -A POSTROUTING -s 192.168.0.43/24 -o eth0 -j MASQUERADE
sudo iptables -t nat -A PREROUTING -i eth0 -d $Global_IP -p udp -j DNAT --to-destination 192.168.0.43
sudo iptables -A FORWARD -i eth0 -d 192.168.0.43 -p udp -j ACCEPT


[ventru22]

правил не особо много, почта, трафик с некоторых выпущен в обход прокси-сервера, запрещающие правила - блокируются асечные сервера в цепочке INPUT:
# iptables-save

(Нажмите, чтобы показать/скрыть)

sudo iptables-save
# Generated by iptables-save v1.4.4 on Tue Sep  6 15:14:30 2011
*mangle
:PREROUTING ACCEPT [3508827:2727298034]
:INPUT ACCEPT [1651719:742582300]
:FORWARD ACCEPT [1856633:1984683386]
:OUTPUT ACCEPT [1270089:2282832699]
:POSTROUTING ACCEPT [3126938:4267570565]
COMMIT
# Completed on Tue Sep  6 15:14:30 2011
# Generated by iptables-save v1.4.4 on Tue Sep  6 15:14:30 2011
*nat
:PREROUTING ACCEPT [723996:51804134]
:POSTROUTING ACCEPT [460127:29184335]
:OUTPUT ACCEPT [388037:25344193]
-A POSTROUTING -s 192.168.3.0/24 -p tcp -m tcp --dport 110 -j MASQUERADE
-A POSTROUTING -s 192.168.3.0/24 -p tcp -m tcp --dport 25 -j MASQUERADE
-A POSTROUTING -s 192.168.3.50/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.3.10/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.4/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.3.7/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.3.5/32 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Sep  6 15:14:30 2011
# Generated by iptables-save v1.4.4 on Tue Sep  6 15:14:30 2011
*filter
:INPUT ACCEPT [81794811:38256121758]
:FORWARD ACCEPT [11887787:9740807513]
:OUTPUT ACCEPT [98070789:104977205884]
-A INPUT -s 205.188.251.47/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 64.12.202.112/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 64.12.202.112/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 205.188.251.43/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 79.174.73.67/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Tue Sep  6 15:14:30 2011

# iptables -L

(Нажмите, чтобы показать/скрыть)

sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  bucp-p1-vip.blue.icq.net  anywhere            reject-with icmp-port-unreachable
REJECT     all  --  bucp-w1-vip.blue.icq.net  anywhere            reject-with icmp-port-unreachable
REJECT     all  --  bucp-w1-vip.blue.icq.net  anywhere            reject-with icmp-port-unreachable
REJECT     all  --  bucp-d1-vip.blue.aol.com  anywhere            reject-with icmp-port-unreachable
REJECT     all  --  fe54-1.hc.ru         anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Пользователь решил продолжить мысль 06 Сентября 2011, 13:22:34:

А маскарад-то надо было оставить. А Вы его видимо "2били"

с маскарадом аналогично, просто цепляется - черный экран, без него, "не найден пункт назначения"

[fisher74]

(Нажмите, чтобы показать/скрыть)

блокируются асечные сервера в цепочке INPUT:

Я с Вас чумею... аськи решете, а злоклассников в работе оставляете

[ventru22]

Я с Вас чумею... аськи решете, а злоклассников в работе оставляете

остальное благополучно режется на уровне прокси-сервера, аська просто такая пакость что только так можно с ней бороться )))

[fisher74]

В настройках сервера нет настроек собственного адреса?

[ventru22]

Если вы про настройки сервера самой железки, то там таких вообще нету, есть настройка LAN (ip получает по dhcp), настройки кодеков h.323, настройки портов, есть настройка NAT (ничего в нем не заполнял), скорость соединения - это все настраивается по выданному головной конторой мануалу.

[fisher74]

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

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

[ventru22]

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

[fisher74]

Какэто не за NAT-ом? Вы как раз на ним самым. Или Вы считаете букаффки "-t nat" с правиле маскарадинга для полноты использования алфавита добавляется?

[just_men]

вопрос - а зачем вообще использовать маскард, если у вас статический адрес внешний (если я правильно понял)?
попробуйте так ради интереса
/sbin/iptables -t nat -A POSTROUTING -j SNAT -p udp -s 192.168.0.43 -d $ip_server -o eth1 --to $ip_ext

и кстати зачем вы тут указываете подсеть, достаточно ип хоста
sudo iptables -t nat -A POSTROUTING -s 192.168.0.43/24 -o eth0 -j MASQUERADE

[ventru22]

Какэто не за NAT-ом?

Здесь подразумевалось что не за внешним NAT'ом, о том что есть нат на шлюзе - это само собой.

попробуйте так ради интереса
/sbin/iptables -t nat -A POSTROUTING -j SNAT -p udp -s 192.168.0.43 -d $ip_server -o eth1 --to $ip_ext

хм ... забавно, после этого проскользнуло два пакета, почему то по TCP, но по прежнему не видит пункт назначения, подключиться не может  -
вот кусок лога из iptraf, до этого ничего подобного небыло:

(Нажмите, чтобы показать/скрыть)

Wed Sep  7 09:09:15 2011; TCP; eth1; 60 bytes; from 192.168.0.43:11010 to $IP_вещающего_хоста:1720; first packet (SYN)
Wed Sep  7 09:09:15 2011; TCP; eth0; 60 bytes; from 192.168.0.43:11010 to $IP_вещающего_хоста:1720; first packet (SYN)

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

(Нажмите, чтобы показать/скрыть)

Wed Sep  7 09:19:53 2011; UDP; eth1; 200 bytes; from 192.168.0.43:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth0; 200 bytes; from $внешний_IP:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth1; 200 bytes; from 192.168.0.43:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth0; 200 bytes; from $внешний_IP:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth1; 200 bytes; from 192.168.0.43:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth0; 200 bytes; from $внешний_IP:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth1; 200 bytes; from 192.168.0.43:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth0; 200 bytes; from $внешний_IP:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth1; 465 bytes; from 192.168.0.43:2440 to $IP_вещающего_хоста:65228
Wed Sep  7 09:19:53 2011; UDP; eth0; 465 bytes; from $внешний_IP:2440 to $IP_вещающего_хоста:65228
Wed Sep  7 09:19:53 2011; UDP; eth1; 636 bytes; from 192.168.0.43:2440 to $IP_вещающего_хоста:65228
Wed Sep  7 09:19:53 2011; UDP; eth0; 636 bytes; from $внешний_IP:2440 to $IP_вещающего_хоста:65228
Wed Sep  7 09:19:53 2011; UDP; eth1; 200 bytes; from 192.168.0.43:2438 to $IP_вещающего_хоста:65234
Wed Sep  7 09:19:53 2011; UDP; eth0; 200 bytes; from $внешний_IP:2438 to $IP_вещающего_хоста:65234

а зачем вообще использовать маскард

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

[just_men]

млин, я конечно не растыка .. просто по привычке именования интерфейсов,  у вас же eth0 внешний, тады надо
/sbin/iptables -t nat -A POSTROUTING -j SNAT -p udp -s 192.168.0.43 -d $ip_server -o eth0 --to $ip_ext
или как вариант вообще внешний интерфейс не указывать...
/sbin/iptables -t nat -A POSTROUTING -j SNAT -p udp -s 192.168.0.43 -d 0.0.0.0/0  --to $ip_ext