LINUX.ORG.RU
решено ФорумAdmin

iproute2. Неверный src-ip.

 , ,


0

2

Имеется шлюз с debian 6. На него заведены 2 провайдера. Один подключен через ethernet, второй через pppoe. В 101 vlan за этим шлюзом имеется сервер asterisk. Он регистрируется на sip-сервере второго провайдера. В /etc/iproute2/rt_tables добавлены две таблицы, через которые осуществляется маршрутизация. В /etc/ppp/ip-up.d кинут скрипт

#!/bin/sh
IF0=eth0
IF1=eth1
IF_PPP=ppp0
IF_VLAN101=eth3.101
IP0=192.168.0.254
IP1=1.1.1.1
IP_PPP=2.2.2.2
IP_VLAN101=192.168.101.254
P1=1.1.1.254
P_PPP=2.2.2.254
P0_NET=192.168.0.0/24
P1_NET=1.1.1.128/25
P_PPP_NET=2.2.2.254/32
P101_NET=192.168.101.0/24

ip route flush table ER
ip route flush table RT
ip route add $P1_NET dev $IF1 src $IP1 table ER
ip route add default via $P1 table ER
ip route add $P_PPP_NET dev $IF_PPP src $IP_PPP table RT
ip route add default via $P_PPP table RT
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P_PPP_NET dev $IF_PPP src $IP_PPP
ip rule flush
ip rule add from all pref 32766 table main
ip rule add from all pref 32767 table default
ip rule add from $IP1 table ER
ip rule add from $IP_PPP table RT
ip rule add to 89.239.131.7 table RT
ip rule add to 89.239.139.130 table RT
ip rule add to 89.239.139.131 table RT
ip route flush cache
exit 0
Если шлюз перезагрузить или выключить на пару минут, то регистрация на сип с астериска отваливается. После включения шлюза в консоли астериска наблюдаются множественные попытки зарегистрироваться
[Nov  2 04:04:41] NOTICE[2736]: chan_sip.c:11569 sip_reg_timeout:    -- Registration for 'XXXXXX@89.239.131.7' timed out, trying again (Attempt #53)
tcpdump на шлюзе при этом показывает
# tcpdump -ni ppp0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
03:51:46.629510 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 545
03:51:46.660514 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 545
03:51:46.829653 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 501
03:51:47.244664 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 545
03:51:47.343674 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 545
03:51:47.828657 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 501
03:51:47.996670 IP 1.1.1.1.5060 > 89.239.131.7.5060: SIP, length: 545
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
При попытке запустить пинг до sip-сервера с asterisk наблюдается
$ ping -c4 89.239.131.7
PING 89.239.131.7 (89.239.131.7) 56(84) bytes of data.
64 bytes from 89.239.131.7: icmp_seq=1 ttl=251 time=6.03 ms
64 bytes from 89.239.131.7: icmp_seq=2 ttl=251 time=5.03 ms
64 bytes from 89.239.131.7: icmp_seq=3 ttl=251 time=8.09 ms
64 bytes from 89.239.131.7: icmp_seq=4 ttl=251 time=7.09 ms

--- 89.239.131.7 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 5.034/6.564/8.091/1.148 ms
tcpdump на шлюзе же говорит
# tcpdump -ni ppp0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
03:56:10.409096 IP 2.2.2.2 > 89.239.131.7: ICMP echo request, id 16168, seq 1, length 64
03:56:10.414895 IP 89.239.131.7 > 2.2.2.2: ICMP echo reply, id 16168, seq 1, length 64
03:56:11.410039 IP 2.2.2.2 > 89.239.131.7: ICMP echo request, id 16168, seq 2, length 64
03:56:11.414896 IP 89.239.131.7 > 2.2.2.2: ICMP echo reply, id 16168, seq 2, length 64
03:56:12.410988 IP 2.2.2.2 > 89.239.131.7: ICMP echo request, id 16168, seq 3, length 64
03:56:12.418895 IP 89.239.131.7 > 2.2.2.2: ICMP echo reply, id 16168, seq 3, length 64
03:56:13.411984 IP 2.2.2.2 > 89.239.131.7: ICMP echo request, id 16168, seq 4, length 64
03:56:13.418898 IP 89.239.131.7 > 2.2.2.2: ICMP echo reply, id 16168, seq 4, length 64
Регистрация с asterisk нормально проходит только если остановить его на пару минут и перезапустить шлюз или сеть на нем. Вопрос заключается в том, чтобы заставить сервер использовать нужный src-ip сразу после поднятия интерфейса ppp0 для всех соединений. И почему на данный момент у него такое поведение?



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

Вот увидев «ip ru» и «ip ro» для созданых таблиц маршрутизации было бы проще понять. Хорошо бы увидеть «ip -4 a» на шлюзе.

На шлюзе «conntrack -F» дает такой же результат что и перезагрузка ?

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

Выкладывать в общий доступ адреса не очень хотелось бы. Пакет conntrack не стоял. После установки и проверки вашей команды регистрация пошла.

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

мда, заменой в тексте пользоваться не умеем....

Я так и не понял, если вместо перезагрузки шлюза на нем выполнить «conntrack -F» то астериск отваливается ?

Нужно понять что является источником проблемы conntrack на шлюзе или это что-то другое.

vel ★★★★★
()
Ответ на: комментарий от vel
# ip ru
0: from all lookup local
32758: from all to 205.188.0.0/16 lookup RT
32759: from all to 64.12.0.0/16 lookup RT
32760: from 192.168.17.0/24 lookup RT
32761: from all to 89.239.139.131 lookup RT
32762: from all to 89.239.139.130 lookup RT
32763: from all to 89.239.131.7 lookup RT
32764: from 2.2.2.2 lookup RT
32765: from 1.1.1.1 lookup ER
32766: from all lookup main
32767: from all lookup default

# ip ro
2.2.2.254 dev ppp0 proto kernel scope link src 2.2.2.2
172.16.50.2 dev tun0 proto kernel scope link src 172.16.50.1
1.1.1.128/25 dev eth1 proto kernel scope link src 1.1.1.1
192.168.101.0/24 dev eth3.101 proto kernel scope link src 192.168.101.254
172.16.50.0/24 via 172.16.50.2 dev tun0
192.168.17.0/24 dev eth3.17 proto kernel scope link src 192.168.17.254
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.254
default via 1.1.1.254 dev eth1

# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
inet 1.1.1.1/25 brd 1.1.1.255 scope global eth1
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
inet 2.2.2.2 peer 2.2.2.254/32 scope global ppp0
7: eth3.101@eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.101.254/24 brd 192.168.101.255 scope global eth3.101
8: eth3.17@eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.17.254/24 brd 192.168.17.255 scope global eth3.17
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1243 qdisc pfifo_fast state UNKNOWN qlen 100
inet 172.16.50.1 peer 172.16.50.2/32 scope global tun0

После выполнения «conntrack -F» asterisk не отваливается. Наоборот после выполнения этой команды у него нормально начинает проходить регистрация на сип-сервере.

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

Очень транно выглядят 2 строки

ip ro
1.1.1.128/25 dev eth1 proto kernel scope link src 1.1.1.1
ip a
inet 1.1.1.1/25 brd 1.1.1.255 scope global eth1

Зачем делить сеть на 2 подсети таким странным образом ? Такие загадочные конструкции обычно являются источником трудноуловимых глюков.

На шлюзе NAT для астериска применяется ? В тот момент, когда начинаются таймауты с сип-сервером нужно взглянуть на «conntrack -L» и найти строку соответствующую попытке соединения с сип-сервером. Если оно имеет статус INVALID , то можно попробовать в явном виде в iptables разрешить пересылку данных между астериском и сип-сервером.

Вообще перезагрузка шлюза с nat и/или full-state фильтрацией является серьезной проблемой для долгоживущих соединений

на счет pppoe. В качестве кастыля можно попробовать в ip-up прописать «ip ro flush table cache» и «conntrack -F»

vel ★★★★★
()
Ответ на: комментарий от vel
# conntrack -L | grep 89.239.131.7
conntrack v0.9.14 (conntrack-tools): 142 flow entries have been shown.
udp      17 29 src=192.168.101.1 dst=89.239.131.7 sport=5060 dport=5060 packets=465 bytes=256545 [UNREPLIED] src=89.239.131.7 dst=1.1.1.1 sport=5060 dport=5060 packets=0 bytes=0 mark=0 secmark=0 use=2

А если попробовать положить скрипт, прописывающий правила для iproute2, в /etc/network/if-pre-up.d/ ? Он сможет корректно выполниться, если интерфейсов еще не будет?

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

Сейчас смотрю еще в сторону NOTRACK. Может, это то, что мне нужно.
Не нужно, так как после этого прекращает работать NAT.

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

NAT применяется. Теперь возникает проблема другого характера.

# tcpdump -ni ppp0 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
12:03:31.425810 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:31.525861 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:31.626902 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:33.326101 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:33.426008 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:33.525771 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
12:03:33.626821 IP 192.168.101.1.5060 > 89.239.131.7.5060: SIP, length: 364
Теперь src-адресом с внешнего интерфейса подставляется ip астериска за NAT. При этом dns-запросы, пинги, tcp прекрасно натятся. «conntrack -F» уже не спасает.

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

Нашел проблему. Правило с NOTRACK сохранилось.

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

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

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