LINUX.ORG.RU
Форум — Admin  

Непонятки с iptables и RTP


0

1

В академических целях так скать... Вопрос в следующем: почему я могу, скажем, позвонить на тестовый extension 1000@demo в астериске и услышать приятный голос, если таблица INPUT выглядит так (на сервере, где установлен asterisk):

root@mx:~# iptables --line-numbers -vnL INPUT 
Chain INPUT (policy DROP 689 packets, 136K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    72884 4197K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 22 
2    2930K  310M allowed    all  --  *      *       0.0.0.0/0            0.0.0.0/0           
3     473K   29M tcp_allowed  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
4     4437  384K udp_allowed  all  --  *      *       0.0.0.0/0            0.0.0.0/0 
root@mx:~# iptables --line-numbers -vnL udp_allowed 
Chain udp_allowed (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       10  6903 ACCEPT     udp  --  *      *       a.b.c.d         0.0.0.0/0           udp dpt:5060

А как же RTP и порты с 10000-20000. Они ведь «закрыты». Да, нет 

root@mx:~# tcpdump -i eth0 host a.b.c.d and not port 22 -nnn -c 30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:31:36.970168 IP a.b.c.d.5060 > e.f.g.h.5060: SIP, length: 2
21:31:38.178520 IP a.b.c.d.5060 > e.f.g.h.5060: SIP, length: 1136
21:31:38.179763 IP e.f.g.h.5060 > a.b.c.d.5060: SIP, length: 604
21:31:38.254658 IP a.b.c.d.5060 > e.f.g.h.5060: SIP, length: 382
21:31:38.996031 IP a.b.c.d.5060 > e.f.g.h.5060: SIP, length: 1302
21:31:38.996912 IP e.f.g.h.5060 > a.b.c.d.5060: SIP, length: 544
21:31:39.997638 IP e.f.g.h.5060 > a.b.c.d.5060: SIP, length: 917
21:31:40.072986 IP a.b.c.d.5065 > e.f.g.h.11627: UDP, length 1
21:31:40.083025 IP a.b.c.d.5060 > e.f.g.h.5060: SIP, length: 593
21:31:40.083132 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 1
21:31:40.207751 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.226420 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.253031 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.263320 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.281597 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.431432 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.445943 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.452439 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.458892 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.486597 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.506960 IP e.f.g.h.11626 > a.b.c.d.5064: UDP, length 172
21:31:40.517349 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.523973 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.528833 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.534508 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.540590 IP e.f.g.h.11626 > a.b.c.d.5064: UDP, length 172
21:31:40.549433 IP e.f.g.h.11626 > a.b.c.d.5064: UDP, length 172
21:31:40.569699 IP e.f.g.h.11626 > a.b.c.d.5064: UDP, length 172
21:31:40.570685 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
21:31:40.577345 IP a.b.c.d.5064 > e.f.g.h.11626: UDP, length 172
30 packets captured
33 packets received by filter
0 packets dropped by kernel

Неужели conntrack? Так ведь udp stateless. Ну ладно, от греха подальше

root@mx:~# iptables -vnL PREROUTING -t raw
Chain PREROUTING (policy ACCEPT 2701 packets, 273K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  852  169K LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpts:10000:20000 LOG flags 0 level 4 prefix `RAW RTP: ' 
  676  134K NOTRACK    udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpts:10000:20000

Всё равно звоню. Что я просмотрел? Пока одним глазом смотрю RFC :)

root@mx:~# iptables --line-numbers -vnL allowed 
Chain allowed (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1    64569 5299K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            
2    2359K  273M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED 
3    34830 3335K ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
root@mx:~# iptables --line-numbers -vnL tcp_allowed 
Chain tcp_allowed (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1    81244 4870K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 ctstate NEW 
2       56  2976 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
3       41  2140 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993  
4     382K   23M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:10050
← Есть ли в BusyBox аналог dtach, screen или tmux?
Некорректное удаление скомпиленной программы →

Покажи лучше нормальный вывод через iptables-save. А так да, nf_conntrack_sip следит за дочерними RTP соединениями.

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

Да я знаю, поэтому и не загружал. Разрассуждался я, поэтому забыл про

# Generated by iptables-save v1.4.8 on Wed Jan 12 22:11:05 2011
*raw
:PREROUTING ACCEPT [3246:303471]
:OUTPUT ACCEPT [2214:439723]
-A PREROUTING -p udp -m udp --dport 10000:20000 -j LOG --log-prefix "RAW RTP: " 
-A PREROUTING -p udp -m udp --dport 10000:20000 -j NOTRACK 
COMMIT
# Completed on Wed Jan 12 22:11:05 2011
# Generated by iptables-save v1.4.8 on Wed Jan 12 22:11:05 2011
*filter
:INPUT DROP [698:136554]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2605:554329]
:allowed - [0:0]
:fail2ban-ssh - [0:0]
:tcp_allowed - [0:0]
:udp_allowed - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A INPUT -j allowed 
-A INPUT -j tcp_allowed 
-A INPUT -j udp_allowed 
-A allowed -i lo -j ACCEPT 
-A allowed -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A allowed -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A fail2ban-ssh -j RETURN 
-A tcp_allowed -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 25 -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 993 -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 10050 -j ACCEPT 
-A udp_allowed -s a.b.c.d -p udp -m udp --dport 5060 -j ACCEPT 
COMMIT
# Completed on Wed Jan 12 22:11:05 2011
anton_jugatsu ★★★★
() автор топика
Ответ на: комментарий от anton_jugatsu

Есть правило "--ctstate RELATED,ESTABLISHED", оно пропускает все дочерние соединения от SIP (5060 порт), убедиться можно погрепав nf_conntrack.

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

Грепать не надо, для этого есть

root@mx:~# conntrack -L -p udp
udp      17 173 src=a.b.c.d dst=e.f.g.h sport=5060 dport=5060 packets=14015 bytes=683281 src=e.f.g.h dst=a.b.c.d sport=5060 dport=5060 packets=627 bytes=351566 [ASSURED] mark=0 secmark=0 use=2

Поэтому я и использовал таблицу raw, правда, ошибся. RTP не нужон там. Хорошо, проверим related ли rtp и rtcp к sip.

-A PREROUTING -p udp -m udp --dport 5006 -j NOTRACK

Счётчики по нулям.

anton_jugatsu ★★★★
() автор топика

По выводу tcpdump вижу, что a.b.c.d с 506X порта устанавливает вторичное «соединение» (в кавычках, ибо UDP) с высоким портом e.f.g.h.

// На котором из фаервол?

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

Значит, наоборот, e.f.g.h с высокого порта шлет пакеты на a.b.c.d:506X/udp, иначе бы фаервол не пропустил.

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

А ну да, получается, что я звоню на демо экстэншен (устанавливаю соединение через sip), а ответ то получаю звук по rtp, я ничего не передаю. Надо поробовать с передачей звука.

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

Не хотит работать nf_conntrack_sip.

Картина следующая:

На сервере (1.2.3.4) установлен asterisk. К нему подключаются два пира

-A udp_allowed -s 1.2.3.4/32 -p udp -m udp --dport 5060 -j ACCEPT

Эти пиры инициируют разговор: как следствие, друг друга не будут слышать, пока жёстко не указать

iptables -A udp_allowed -p udp --dport 10000:20000 -j ACCEPT

Чем, собственно, и должен заниматься sip хелпер. Кстати правило, которое выше, можно потом свободно удалять, conntrack модуль обо всём позаботится (видно по -LOG и, если в -t raw на RTP порты 10000:20000 указать NOTRACK, сразу голос не слышно).

# Generated by iptables-save v1.4.8 on Tue Jan 25 23:55:25 2011
*nat
:PREROUTING ACCEPT [2695:519436]
:POSTROUTING ACCEPT [173:12530]
:OUTPUT ACCEPT [173:12530]
COMMIT
# Completed on Tue Jan 25 23:55:25 2011
# Generated by iptables-save v1.4.8 on Tue Jan 25 23:55:25 2011
*raw
:PREROUTING ACCEPT [76345:14906068]
:OUTPUT ACCEPT [72837:15028395]
COMMIT
# Completed on Tue Jan 25 23:55:25 2011
# Generated by iptables-save v1.4.8 on Tue Jan 25 23:55:25 2011
*filter
:INPUT DROP [1:60]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21063:4595015]
:allowed - [0:0]
:fail2ban-ssh - [0:0]
:tcp_allowed - [0:0]
:udp_allowed - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A INPUT -j allowed 
-A INPUT -j tcp_allowed 
-A INPUT -j udp_allowed 
-A allowed -i lo -j ACCEPT 
-A allowed -p udp -m udp --dport 10000:20000 -m conntrack --ctstate RELATED,ESTABLISHED -j LOG --log-prefix "RTP_CT: " 
-A allowed -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A allowed -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A fail2ban-ssh -j RETURN 
-A tcp_allowed -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 25 -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 993 -j ACCEPT 
-A tcp_allowed -p tcp -m tcp --dport 10050 -j ACCEPT 
-A udp_allowed -s 5.6.7.8/32 -p udp -m udp --dport 5060 -j ACCEPT 
COMMIT
# Completed on Tue Jan 25 23:55:25 2011

5.6.7.8 это айпи клиентов.

iptables 1.4.8
2.6.32.25
anton_jugatsu ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Есть ли в BusyBox аналог dtach, screen или tmux?
Admin
Некорректное удаление скомпиленной программы →