Почему Mikrotik путает адреса src-NAT?

Question

[kerneus]

Приветствую, комрады.
В своей организации использую оборудование Mikrotik, в качестве точек доступа и базовых маршрутизаторов сети, они же держат и VPN тунели между филиалами. В качестве АТС - vps на хостинге с Asterisk на борту и L2tp/IPsec сервером. В качестве абоненских устройств - Grandstream GXP-2135.
Между филиалами и "облачной" АТС лежат тунели:

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet ##.##.1.12  netmask 255.255.255.255  destination ##.##.1.102
        ppp  txqueuelen 3  (Point-to-Point Protocol)
ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet ##.##.1.12  netmask 255.255.255.255  destination ##.##.1.106
        ppp  txqueuelen 3  (Point-to-Point Protocol)
ppp2: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet ##.##.1.12  netmask 255.255.255.255  destination ##.##.1.101
        ppp  txqueuelen 3  (Point-to-Point Protocol)
 > /interface l2tp-client print detail
 2  R name="pbx.domainname.ru" max-mtu=1450 max-mru=1450 mrru=disabled 
      connect-to=#.##.##.### user="#######-home-hap" 
      password="********************************" profile=default-encryption 
      keepalive-timeout=60 use-peer-dns=no use-ipsec=yes 
      ipsec-secret="***************************" allow-fast-path=no 
      add-default-route=no dial-on-demand=no allow=chap,mschap1,mschap2
 > /ip route print detail
 6 ADC  dst-address=##.##.1.12/32 pref-src=##.##.1.106 gateway=pbx.domainname.ru 
        gateway-status=pbx.domainname.ru reachable distance=0 scope=10
> /ip firewall nat print detail
 0    chain=srcnat action=masquerade out-interface=pbx.domainname.ru log=no 
      log-prefix=""

Такой же конфиг на остальных маршрутизаторах, все поднимается и работает, до какого-то момента, который я уже месяц не могу отследить: в один прекрасный момент на АТС начинают поступать пакеты с неправильным source-IP
Лог АТС:

апр 03 16:37:23 sip asterisk[9056]: [Apr  3 16:37:23] NOTICE[9116]: acl.c:715 ast_apply_acl: SIP Peer ACL: Rejecting '10.28.4.9' due to a failure to pass ACL '(BASELINE)'
апр 03 16:37:23 sip asterisk[9056]: [Apr  3 16:37:23] NOTICE[9116]: chan_sip.c:28633 handle_request_register: Registration from '<sip:####@##.##.1.12>' failed for '10.28.4.9:5060' - Device does not match ACL

tcpdump -vv -i ppp1:

16:39:59.614710 IP (tos 0x68, ttl 63, id 7729, offset 0, flags [none], proto UDP (17), length 600)
    10.28.4.9.sip > sip.sip: [udp sum ok] SIP, length: 572
        REGISTER sip:##.##.1.12 SIP/2.0
        Via: SIP/2.0/UDP 10.28.4.9:5060;branch=z9hG4bK836453010;rport
        From: <sip:####@##.##.1.12>;tag=27982579
        To: <sip:####@##.##.1.12>
        Call-ID: [e-mail]
        CSeq: 2041 REGISTER
        Contact: <sip:####@10.28.4.9:5060>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD094B07>"
        X-Grandstream-PBX: true
        Max-Forwards: 70
        User-Agent: Grandstream GXP2135 1.0.11.16
        Supported: path
        Expires: 3600
        Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
        Content-Length: 0

Перехват со стороны маршрутизатора:

> tool torch interface=pbx.domainname.ru src-address=0.0.0.0/0 dst-address=0.0.0
.0/0 dscp=any
MAC-PROTOCOL    DSCP SRC-ADDRESS                               DST-ADDRESS                              
ip                             26 ##.##.1.12             	                      10.28.4.9

Адрес на микротике:

> /ip address print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 3 D address=10.28.4.9/24 network=10.28.4.0 interface=ether2-wan
     actual-interface=ether2-wan

Симптом абсолютно идентичен на всех маршрутизаторах, через какое-то время микрот начинает путать адреса источников при отработке правила маскировки и ломиться в АТС с адресом WAN интерфейса, но при все при этом, проблема наблюдаеться исключительно с SIP:

##.##.1.106.59995 > sip.ssh: Flags [.], cksum 0xd181 (correct), seq 1, ack 144, win 509, length 0
16:39:51.606533 IP (tos 0x68, ttl 63, id 7727, offset 0, flags [none], proto UDP (17), length 600)

Пробовал такой костыль - не помогло:

> /ip firewall nat print detail
Flags: X - disabled, I - invalid, D - dynamic 
 1    chain=srcnat action=src-nat to-addresses=##.##.1.106 
      dst-address=##.##.1.12 out-interface=pbx.domainname.ru log=no 
      log-prefix=""

Проблема, естественно временно, исправляется ребутом маршрутизатора, перезапуск тунеля/правил firewall - результата никакого не дает.
Сейчас появилась затея добавить правила маскировки непосредственно на VPS, но это не является ответом на исходный вопрос - почему микротик игнорирует правило NAT, и почему путает SOURCE IP?

Comments

[nApoBo3]

Что в этот момент в таблице соединений?

[kerneus]

113 SAC s udp ##.##.250.120:5060 ##.##.1.12:5060
Такое соединение висит и при наличии бага и в его отсутствие.

[Valentin Barbolin]

У меня тоже есть вопрос.
/ip firewall nat print detail
0 chain=srcnat action=masquerade out-interface=pbx.domainname.ru log=no
log-prefix="

Зачем нужен NAT в туннеле? Что бы не прописывать на АТС сети филиалов? Как по мне - это край безобразия!

[kerneus]

Andrey Barbolin, чтобы не возиться с динамическим добавлением маршрутов в x2ltpd

[Valentin Barbolin]

kerneus, Но при этом бороться c проблемами NAT+SIP. Скорее всего проблема в ipsec, в какой-то момент времени пакет сначала обрабатывается правилом ipsec, а уже потом попадает под правило NAT. Т.к. пакет оказывается зашифрован, то NAT не видит содержимое и не работает. Все же я рекомендую избегать подобных конфигураций.

[kerneus]

Andrey Barbolin, добавил ответ к вопросу, все проще оказалось.

Answer 1

[kerneus]

А вот и ответ на вопрос:


В процесе "неопределенных событий", скорее всего, на какое-то время происходит обрыв на стороне провайдера, в это время тунель прерывается и исчезает маршрут к АТС, в то же время существует 0.0.0.0/0 маршрут в сторону gw провайдера. После восстановления связи, снова появляется маршрут к АТС и происходит то, что описано на скриншотах.
Решение - запретить микроту маршрутизировать пакеты к АТС через WAN интерфейс:

> /ip firewall filter print detail 
Flags: X - disabled, I - invalid, D - dynamic 
12    chain=forward action=reject reject-with=icmp-network-unreachable 
       dst-address=##.##.1.12 out-interface-list=WAN 
      log=no log-prefix=""

Comments

[nApoBo3]

Это касается не только sip, а вообще всех соединений.
Насколько я помню лечится отказом от "маскарадига".
chain=srcnat action=masquerade.

[kerneus]

nApoBo3, не сочтите за грубость, но ответ из разряда -

- Доктор, когда я делаю вот так, у меня тут болит.
- А Вы так не делайте.

Проблемы с SIP - не используйте SIP, проблемы с masquerade - не используйте masquerade.
Я не вижу никаких проблем в использовании давно известной технологии.
Вернее, проблемы как видно конечно есть) но и для них есть решения.
Разве не для этого создан этот ресурс - не для поиска решений?

[nApoBo3]

kerneus,
Ну собственно говоря все так. Для решения проблем sip придумали iax. Но не кто ни говорит не используйте sip, просто sip и nat плохо сочетаются, по этому подобных конфигураций следует избегать.
Сложности с маршрутизацией решаются различными методами, например ospf.
Маскарадинг и connection traking работают вместе не очень если исходящий интерфейс может меняться, это известная особенность, если заменить маскарадинг на src nat проблемы не будет, или нужно при изменении маршрутов сбрасывать состояние соединений.