+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Медленное установление соединения за NAT.

Медленное установление соединения за NAT., RouterOS

Lister169126

Guest

12.01.2017 19:06:00

Привет, у меня проблема с моим MikroTik. У меня два бриджа: один с публичными IP, другой — с приватной сетью. Из приватного бриджа я делаю NAT на публичный. Когда пытаюсь пинговать любой сервер в публичной сети — всё очень быстро. Когда пингуешь приватную сеть — открывается долго, но скорость нормальная.

Публичный бридж:
root@ts:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) байт данных.
64 байта от prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=57 время=3.77 мс

real 0m0,008s
user 0m0,000s
sys 0m0,000s

Приватный бридж:
root@robot:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) байт данных.
64 байта от prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=56 время=3.76 мс

real 0m5.014s
user 0m0.000s
sys 0m0.004s

Фаервола особенного нет, только базовый (defconf) с парой дополнительных правил и переадресаций:

/ip firewall address-list
add address=x.x.x.x list=allow

/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="Allowed connection" dst-port=8291 protocol=tcp src-address-list=allow
add action=accept chain=input dst-port=8081 protocol=tcp src-address-list=allow
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=bridge1-public
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=bridge1-public

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=bridge1-public
add action=dst-nat chain=dstnat comment="SSH robot" dst-port=22024 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.11 to-ports=22022
add action=dst-nat chain=dstnat comment=bmc dst-port=8088 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.2 to-ports=80
add action=dst-nat chain=dstnat comment=vsphere dst-port=8080 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.3 to-ports=443
add action=dst-nat chain=dstnat dst-port=902 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.3 to-ports=902
add action=dst-nat chain=dstnat comment=ts dst-port=9987 in-interface=bridge1-public protocol=udp to-addresses=192.168.4.10 to-ports=9987
add action=dst-nat chain=dstnat dst-port=9988 in-interface=bridge1-public protocol=udp to-addresses=192.168.4.10 to-ports=9988
add action=dst-nat chain=dstnat comment="ts file transfer" dst-port=30033 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.10 to-ports=30033
add action=dst-nat chain=dstnat comment="ts server query" dst-port=10011 in-interface=bridge1-public protocol=tcp src-address-list=allow to-addresses=192.168.4.10 to-ports=10011
add action=dst-nat chain=dstnat comment=auta dst-port=80 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=80
add action=dst-nat chain=dstnat comment=https dst-port=443 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=443
add action=dst-nat chain=dstnat comment=FTP dst-port=21 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.11 to-ports=21
add action=dst-nat chain=dstnat comment="SSH vSphere" dst-port=22023 in-interface=bridge1-public protocol=tcp to-addresses=192.168.4.3 to-ports=22

Модель роутера — 850Gx2, но температура высокая: 52°C. Может быть из-за этого проблема? Нужно ли дамп чего-то еще? Спасибо за ответ и помощь.

paranoidsat

Guest

26.09.2018 10:05:00

Здравствуйте, у меня такая же проблема на двух совершенно новых 850Gx2. Все клиенты за NAT испытывают медленное разрешение DNS. Но при этом нужно, чтобы клиенты использовали внешний nameserver, например 8.8.8.8. Также необходимо отключить локальный DNS-кэш на клиенте. Иначе вы не столкнетесь с этой ошибкой. Лучший способ показать проблему — установить машину с Ubuntu. Проверьте /etc/resolv.conf, убедитесь, что не используется systemd-resolved (127.0.0.53). Команда apt update ожидает 2–3 секунды на разрешение DNS, с любым другим routerboard такой проблемы нет. Клиенты не менялись. Проблему видят только продвинутые пользователи и администраторы. Пользователи с локальным DNS-кэшем страдают от этого меньше. При той же конфигурации на любом другом routerboard такой проблемы не наблюдаю. Похоже, затрагивается только DNS. Вот моя конфигурация:

[admin@MikroTik] > export compact
jan/02/1970 00:03:41 by RouterOS 6.43.2
software id = 0ZJB-YVJ6
model = 850Gx2
serial number = 71DC04D5BEC5

/ip address
add address=192.168.65.1/24 interface=ether2 network=192.168.65.0

/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 src-address=192.168.65.0/24

/system routerboard settings
set silent-boot=no

С уважением,

Lister169126

Guest

27.09.2018 07:33:00

Подтверждаю. Я настроил другой Mikrotik CRS109 с такими же параметрами — работает отлично. С 850Gx2 нашёл два решения для Debian (эта проблема есть только на 850Gx2 и касается только Linux). Проблема описана здесь и здесь (обратите внимание на улучшение DNS NSS). Простое решение — добавить директиву «options timeout:1» в resolv.conf. Это заставит систему не ждать долго ответа для ipv6 (проблема именно в таймауте) — будет ждать всего 1 секунду. Кроме того, можно поставить директиву «options single-request» в resolv.conf, тогда система не будет пытаться разрешать ipv6, так как запрос решается в первом (ipv6) запросе. (не рекомендуется) Более правильный вариант — установить собственный системный DNS-резольвер или отдельный DNS-резольвер в сети (не Mikrotik). Можно использовать bind, dnsmasq, а самый маленький и лучший, который я нашёл, — nscd. После установки в resolv.conf укажите его IP. Это даст активный ответ на запросы ipv6. Локальный DNS-резольвер теперь будет кэшировать все запросы и не будет ждать таймауты на Mikrotik (напряжение возникает только при первом запросе).

paranoidsat

Guest

28.09.2018 03:49:00

Здравствуйте! Большое спасибо за ваш ответ. Этот обходной путь совершенно не подходит для моих задач. Мы могли бы использовать 850gx2 как гигабитный коммутатор (в режиме моста — никаких проблем). Вы уже обращались в поддержку по адресу support@mikrotik.com? Если нет, я бы отправил им supout.rif с ссылкой на эту ветку. С уважением,

Lister169126

Guest

28.09.2018 10:19:00

Да, в режиме моста все работает нормально. Нет, я не писал в поддержку. Думаю, они читают этот форум и постараются помочь. Через несколько дней я нашёл это временное решение и забыл про проблему. Если сможете, пожалуйста, отправьте им письмо. С уважением.

paranoidsat Guest	#6 0 01.10.2018 06:34:00 Хорошо, я отправил письмо на support@mikrotik.com с файлом supout.rif. С уважением,

paranoidsat

Guest

03.10.2018 14:31:00

Для документации rb850gx2 добавляет задержку в 5 секунд при DNS-запросах
RB850Gx2 плохой
16:21:49 markus@i5:~$ cat /etc/resolv.conf
nameserver 8.8.8.8
16:21:51 markus@i5:~$ ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever
inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether d4:5d:df:10:00:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.65.2/24 brd 192.168.65.255 scope global enp0s31f6 valid_lft forever preferred_lft forever
3: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 8e:0a:34:7b:9e:df brd ff:ff:ff:ff:ff:ff
16:21:53 markus@i5:~$ ip r sh
default via 192.168.65.1 dev enp0s31f6
192.168.65.0/24 dev enp0s31f6 proto kernel scope link src 192.168.65.2
16:21:57 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=26.5 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.455/26.455/26.455/0.000 ms
real 0m5.140s user 0m0.005s sys 0m0.004s
16:22:08 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=24.1 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.121/24.121/24.121/0.000 ms
real 0m5.132s user 0m0.005s sys 0m0.004s
16:22:18 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=54 time=25.5 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.531/25.531/25.531/0.000 ms
real 0m5.134s user 0m0.007s sys 0m0.002s
16:22:25 markus@i5:~$
RB600A хороший
16:22:25 markus@i5:~$ cat /etc/resolv.conf
nameserver 8.8.8.8
16:23:51 markus@i5:~$ ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever
inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether d4:5d:df:10:00:81 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 74:e5:f9:8d:49:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.154.76/23 brd 192.168.155.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7162sec preferred_lft 7162sec
inet6 fe80::49e6:e29d:52cd:e0ef/64 scope link noprefixroute valid_lft forever preferred_lft forever
16:23:53 markus@i5:~$ ip r sh
default via 192.168.155.5 dev wlp1s0 proto dhcp metric 600
192.168.154.0/23 dev wlp1s0 proto kernel scope link src 192.168.154.76 metric 600
16:24:02 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=27.8 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.843/27.843/27.843/0.000 ms
real 0m0.172s user 0m0.006s sys 0m0.003s
16:24:06 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=33.7 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.678/33.678/33.678/0.000 ms
real 0m0.127s user 0m0.005s sys 0m0.004s
16:24:08 markus@i5:~$ time ping > www.google.at > -c 1
PING > www.google.at > (216.58.207.35) 56(84) bytes of data.
64 bytes from fra16s24-in-f3.1e100.net (216.58.207.35): icmp_seq=1 ttl=55 time=25.8 ms
— > www.google.at > ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.794/25.794/25.794/0.000 ms
real 0m0.109s user 0m0.009s sys 0m0.001s
16:24:11 markus@i5:~$

dksoft Guest	#8 0 17.05.2021 14:06:00 Есть ли какие-то новости по этой проблеме? Я могу использовать DNS-сервер Mikrotik на своих Linux-клиентах с включёнными IPv4/IPv6 только если в /etc/resolv.conf выставлены опции "single-request" или "single-request-reopen".

Lister169126

Guest

17.05.2021 17:23:00

Привет! Несколько недель назад я поставил обычный Linux на свой ноутбук. Похоже, в новой версии Mikrotik эта проблема решена. У меня никаких багов не возникало. У тебя эта проблема ещё есть? Могу запустить и проверить. Я где-то видел описание этой проблемы, там автор говорил про ядро Linux и упоминал, что в новой версии ядра сделали исправление. Так что, возможно, в новом ядре Linux это уже пофикшено.

dksoft Guest	#10 0 18.05.2021 08:24:00 Да, у меня эта проблема сохраняется на всех установках Linux. Ядро версии 5.4.106. Она появляется только на системах с IPv4 и IPv6, и именно это вызывает проблему.

Lister169126 Guest	#11 0 18.05.2021 09:41:00 Хорошо. Значит, можно отключить IPv6 — это решает большинство проблем с исходящими соединениями, особенно в приложениях. В файле /etc/sysctl.d/disableipv6.conf нужно прописать: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 Далее перезагружаемся или выполняем sysctl -p. Но теперь такое же поведение проявляется в Linux-приложениях типа ping, traceroute, curl, wget, потому что они используют glibc (как я уже говорил). Быстрое решение — добавить опцию timeout:1 в resolv.conf. Это гораздо лучше, чем ждать пять секунд . Можно установить nscd — это кеш DNS, и с этого момента долго будет только первый запрос. Больше ничего менять не нужно. Или можно использовать упомянутую опцию single-request, но это скорее временный костыль, который в некоторых ситуациях может замедлить другие соединения. Хорошее решение — отдельно (от Mikrotik) поставить DNS-сервер, например bind или dnsmasq. Лучшее решение — заставить Mikrotik исправить это… Но, видите ли, спустя многие годы проблема всё ещё актуальна.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры