Mikrotik.moscow [тема: Ошибка времени ожидания при обновлении]

Mikrotik.moscow [тема: Ошибка времени ожидания при обновлении] http://mikrotik.moscow Новое в теме Ошибка времени ожидания при обновлении форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Wed, 12 Aug 2026 09:22:42 -0400 Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Потому что «related» пропускает трафик, который является ответом на исходящие соединения. Если вы не разрешаете «related», вам нужно создавать соответствующие входящие правила для всех возможных исходящих соединений, а это быстро становится непрактично. Прочитайте документ о прохождении пакетов в роутере MikroTik или в обычной Linux-системе, чтобы понять, зачем нужно входящее правило для исходящего трафика.
27.11.2018 13:02:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392565 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392565 Tue, 27 Nov 2018 13:02:00 -0500 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Итак, подытожим: входящее PPTP-соединение к PPTP-серверу воспринимается как переадресация куда-то внутрь, для успешного соединения/туннеля в цепочке INPUT нужен протокол 47 (PPTP pass-through), иначе срабатывает правило DROP в INPUT. Исходящее соединение к серверам Mikrotik воспринимается как ВХОДЯЩЕЕ и попадает под правило DROP в INPUT. Это правило DROP в INPUT раньше, кажется, имело галочку Connection:“related”, и тогда всё работало нормально, так что я её вернул, когда вспомнил:

3 ;;; default configuration
chain=input action=accept connection-state=related in-interface=ether1-gateway log=no log-prefix=“”

После этого PPTP и «Проверка обновлений» стали работать нормально. Почему же connection-state=related так важен для работы?
26.11.2018 22:43:00, DrLove73.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392564 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392564 Mon, 26 Nov 2018 22:43:00 -0500 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Вот мои правила файрвола, по крайней мере те, что RouterOS показывает через терминал:

[admin@Preventiva] /ip firewall> address-list print
Flags: X - отключено, D - динамическое
LIST ADDRESS CREATION-TIME TIMEOUT
0 PristupSpolja xxx.xxx.xxx.xx/29 26 нояб. 2018 11:56:16
1 PristupSpolja aaa.aaa.aaa.aaa 26 нояб. 2018 11:57:11
2 PristupSpolja sss.sss.sss.sss 26 нояб. 2018 11:57:25

[admin@Preventiva] /ip firewall> filter print
Flags: X - отключено, I - некорректно, D - динамическое
0 X ;;; стандартная конфигурация chain=input action=accept protocol=tcp dst-address=89.216.xx.xxx in-interface=ether1-gateway dst-port=80 log=no log-prefix=""
1 X ;;; стандартная конфигурация chain=input action=accept protocol=tcp dst-address=89.216.xxx.xx in-interface=ether1-gateway dst-port=443 log=no log-prefix=""
2 ;;; стандартная конфигурация chain=input action=accept protocol=icmp log-prefix=""
3 ;;; стандартная конфигурация chain=input action=accept connection-state=related in-interface=ether1-gateway log=no log-prefix=""
4 chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=1194 log=no log-prefix=""
5 X chain=input action=accept protocol=tcp src-address=xxx.xxx.xxx.xx/29 in-interface=ether1-gateway dst-port=25 log=no log-prefix=""
6 X chain=input action=accept protocol=tcp src-address=xxx.xxx.xxx.xx/29 in-interface=ether1-gateway dst-port=22 log=no log-prefix=""
7 X chain=input action=accept protocol=udp src-address=xxx.xxx.xxx.xx/29 in-interface=ether1-gateway dst-port=25 log=no log-prefix=""
8 ;;; PPTP chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=1723 log=no log-prefix=""
9 ;;; PPTP chain=input action=accept protocol=gre in-interface=ether1-gateway log=no log-prefix=""
10 ;;; Mikrotik Autoupdate chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=38412 log=no log-prefix=""
11 ;;; Mikrotik Autoupdate chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=38414 log=no log-prefix=""
12 chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=8291 log=no log-prefix=""
13 chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=8391 log=no log-prefix=""
14 X chain=input action=accept protocol=tcp in-interface=ether1-gateway dst-port=22 log=no log-prefix=""
15 X ;;; Пустить всё, что не WAN chain=input action=accept in-interface=ether1-gateway log=no log-prefix=""
16 X ;;; Пустить всё, что не WAN chain=forward action=accept in-interface=ether1-gateway log=no log-prefix=""
17 ;;; стандартная конфигурация chain=input action=drop in-interface=ether1-gateway log=no log-prefix="DropSveOstalo"
18 X chain=forward action=accept src-address=192.168.9.0/24 dst-address=192.168.2.1 in-interface=eoip-bridge log-prefix=""
19 chain=forward action=accept src-address=192.168.9.10 dst-address=192.168.0.0/16 in-interface=eoip-bridge log-prefix=""
20 chain=forward action=drop src-address=192.168.9.0/24 dst-address=192.168.0.0/16 in-interface=eoip-bridge log-prefix=""
21 chain=forward action=drop src-address=192.168.10.0/24 dst-address=192.168.0.0/16 in-interface=eoip-bridge log-prefix=""

[admin@Preventiva] /ip firewall> mangle print
Flags: X - отключено, I - некорректно, D - динамическое

[admin@Preventiva] /ip firewall> nat print
Flags: X - отключено, I - некорректно, D - динамическое
0 ;;; стандартная конфигурация chain=srcnat action=masquerade to-addresses=0.0.0.0 out-interface=ether1-gateway log=no log-prefix=""
1 chain=dstnat action=redirect to-ports=8291 protocol=tcp src-address=0.0.0.0 in-interface=ether1-gateway dst-port=8391 log=no log-prefix=""
2 chain=dstnat action=redirect to-ports=22 protocol=tcp src-address=0.0.0.0 in-interface=ether1-gateway dst-port=122 log=no log-prefix=""
3 ;;; Indico VM chain=dstnat action=dst-nat to-addresses=192.168.2.240 to-ports=443 protocol=tcp in-interface=ether1-gateway dst-port=443 log=yes log-prefix="indico"
4 ;;; Indico VM chain=dstnat action=dst-nat to-addresses=192.168.2.240 to-ports=80 protocol=tcp in-interface=ether1-gateway dst-port=80 log=yes log-prefix="indico"

[admin@Preventiva] /ip firewall> raw print
Flags: X - отключено, I - некорректно, D - динамическое

[admin@Preventiva] /ip firewall> service-port print
Flags: X - отключено, I - некорректно
NAME PORTS
0 ftp 21
1 tftp 69
2 irc 6667
3 h323
4 sip 5060 5061
5 pptp
6 udplite
7 dccp
8 sctp
26.11.2018 22:31:00, DrLove73.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392563 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392563 Mon, 26 Nov 2018 22:31:00 -0500 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
У меня проблема с “ERROR: connection timed out” на hEX (RouterBOARD 750G r3), когда я пытаюсь обновиться через “Check for Updates”. Это началось недавно, я пробовал обновиться с версии 6.42.6, но не удалось. Всё началось, когда внезапно перестало устанавливать соединение с моим PPTP-сервером на этом устройстве с домашнего Mikrotik “hAP lite”. Раньше всё работало нормально несколько лет, а сегодня утром после изменения правил фаервола перестало. PPTP-сервер должен был принять TCP-соединение с домашнего Mikrotik, но дальше ничего не происходило, словно всё зависло. Тогда я попытался обновить RouterOS и получил ошибку таймаута.

Я покопался, но решить проблему не удалось. Я отключил недавно созданные правила, но потом прочитал, что нужно отключить последнее правило DROP в цепочке INPUT. Как только я это сделал, и PPTP-соединение с домашнего устройства чудесным образом установилось (требовалось отключить и включить PPTP-клиент), и “Check for Upgrade” заработал. После включения правила input-drop опять и PPTP-соединение, и обновление перестали работать.

Тогда я начал вести лог этого правила input-drop, пытался подключиться по PPTP и нажимал “Check for Update”. Для PPTP в логе видно, что протокол 47 должен проходить, НО PPTP-сервер у меня на этом же Mikrotik, так что должно быть открыто только TCP-порт 1723:
22:45:50 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto 47, 212.69.xxx.xx->89.216.yy.yyy, len 59
22:45:50 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto 47, 212.69.xxx.xx->89.216.yy.yyy, len 54
22:45:51 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto 47, 212.69.xxx.xx->89.216.yy.yyy, len 59

С “Check for Upgrade” вообще странно, в логе видно, что правило INPUT-DROP ловит ИСХОДЯЩЕЕ соединение с сервером Mikrotik (159.148.147.204)!:
22:50:31 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto TCP (SYN,ACK), 159.148.147.204:80->89.216.122.99:38422, len 60
22:50:32 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto TCP (SYN,ACK), 159.148.147.204:80->89.216.yy.yyy:38422, len 60
22:50:33 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto TCP (SYN,ACK), 159.148.147.204:80->89.216.yy.yyy:38422, len 60
22:50:34 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto TCP (SYN,ACK), 159.148.147.204:80->89.216.yy.yyy:38422, len 60
22:50:36 firewall,info DropSveOstalo input: in:ether1-gateway out:(unknown 0), src-mac 2c:ab:eb:27:88:19, proto TCP (SYN,ACK), 159.148.147.204:80->89.216.yy.yyy:38422, len 60

22:50:38 system,info filter rule changed by admin
26.11.2018 21:57:00, DrLove73.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392562 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392562 Mon, 26 Nov 2018 21:57:00 -0500 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Мне кажется, у вас только один маршрут по умолчанию, и он использует интерфейс с динамическим адресом (то есть BTInfinity). Вам нужно добавить маршрут по умолчанию, привязанный к интерфейсу со статическим публичным IP-адресом (BTDSLModem). Чтобы динамический IP-адрес вам не мешал, можно изменить настройки dhcp-клиента и добавить опцию «add-default-route=no» (в webfig изменить поле «Add Default Route» на «no»).
23.07.2018 10:54:00, mkx.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392561 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392561 Mon, 23 Jul 2018 10:54:00 -0400 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Спасибо за предложение, но в моём случае это не работает. Наверное, я что-то делаю не так. Вот вывод /ip route print:

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 BTInfinity 1
1 ADC 81.148.160.1/32 81.148.161.20 BTInfinity 0
2 ADC 172.30.0.0/24 172.30.0.1 bridge-local 0
3 ADC 172.31.0.0/24 172.31.0.1 bridge-dmz 0
4 ADC 172.31.1.0/24 172.31.1.1 bridge-dmz 0
5 ADC AAA.BB.CC.DD/29 AAA.BB.CC.DD BTDSLModem 0

Обратите внимание, что у моего маршрута по умолчанию distance равен 1, а у всех остальных — 0. Я пробовал разные варианты, но ничего не работает. В WebFig, если кликнуть по любому из этих маршрутов, не получается изменить preferred source — такой опции нет. Через командную строку тоже нельзя отредактировать существующие маршруты или снизить distance. Есть старые темы на форуме (например, Dynamic Routes and Preferred Source), где говорят, что нельзя задать preferred source для DAC маршрутов.

Точно так же не получается создать статический маршрут с distance 0 или поднять distance у динамического выше 0. Честно, я в этом пока новичок. Но как тогда задать preferred source для динамического маршрута?
22.07.2018 16:50:00, GeneralMarmite.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392560 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392560 Sun, 22 Jul 2018 16:50:00 -0400 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Вы можете задать предпочитаемый исходящий адрес источника в таблице IP-маршрутизации (в маршруте по умолчанию, в данном случае).
22.07.2018 10:39:00, pe1chl.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392559 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392559 Sun, 22 Jul 2018 10:39:00 -0400 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
У меня есть данные по этой проблеме. Я использую версию 6.42.6 на RB2011iL. У меня бизнес-DSL от BT в Великобритании. Как и кто-то другой уже упоминал, когда я отключаю правило «drop everything else» внизу моего набора входящих правил, обновление проходит успешно. Если оставляю это правило, обновление проваливается. У меня есть объяснение, но оно может касаться только меня. Тем не менее, это может помочь и другим, поэтому вот детали.

Мой провайдер выделяет мне случайный динамический IP /32, как это обычно делают большинство домашних провайдеров. Однако я оплачиваю у провайдера диапазон /29, и использую только эти адреса. У меня нет маршрутов или правил, которые включают этот динамический IP. Он как бы просто есть — я его игнорирую. Все мои правила используют адреса из моего /29.

Вот как выглядит список IP:
[admin@router] > /ip address print
Flags: X - отключен, I - недействителен, D - динамический
# ADDRESS NETWORK INTERFACE
0 172.30.0.1/24 172.30.0.0 bridge-local
1 172.31.0.1/24 172.31.0.0 bridge-dmz
2 X.X.X.X/29 X.X.X.X BTDSLModem
3 172.31.1.1/24 172.31.1.0 bridge-dmz
4 D 81.148.161.20/32 81.148.160.1 BTInfinity

Когда роутер инициирует обновление, исходный IP его пакетов — этот динамический адрес /32. Поэтому SYN/ACK от Cloudfront блокируются — у меня нет правила, которое разрешало бы им возвращаться. Я включил логирование для моего drop-правила, нажал кнопку обновления в WebFig и посмотрел, что зафиксировалось в логах моего drop-правила. В логе видны два изменения правила — когда я включал логирование на этом drop-правиле и когда отключал.

01:12:47 system,info filter rule changed by admin
01:12:53 firewall,info drop input: in:BTInfinity out:(unknown 0), proto TCP (SYN,ACK), 159.148.172.226:80->81.148.161.20:60822, len 60
01:12:54 firewall,info drop input: in:BTInfinity out:(unknown 0), proto TCP (SYN,ACK), 159.148.172.226:80->81.148.161.20:60822, len 60
01:12:55 firewall,info drop input: in:BTInfinity out:(unknown 0), proto TCP (SYN,ACK), 159.148.172.226:80->81.148.161.20:60822, len 60
01:12:56 firewall,info drop input: in:BTInfinity out:(unknown 0), proto TCP (SYN,ACK), 159.148.172.226:80->81.148.161.20:60822, len 60
01:12:58 firewall,info drop input: in:BTInfinity out:(unknown 0), proto TCP (SYN,ACK), 159.148.172.226:80->81.148.161.20:60822, len 60
01:13:08 system,info filter rule changed by admin

Мне непонятно, как контролировать исходный IP, который роутер использует для отправки пакетов. Например, когда он работает как рекурсивный DNS-резолвер и посылает DNS-запросы, он выбирает этот динамический IP в качестве исходного. Когда он устанавливает исходящее соединение с upgrade.mikrotik.com, то тоже использует динамический IP. Мне бы хотелось, чтобы он использовал конкретный IP из моего диапазона, а не этот динамический, «случайный». Возможно, у кого-то еще возникают те же проблемы из-за исходного IP, с которого роутер инициирует соединения. Я не знаю, как написать правила, которые либо отключают этот динамический IP, либо делают его допустимым источником трафика.
22.07.2018 10:17:00, GeneralMarmite.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392558 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392558 Sun, 22 Jul 2018 10:17:00 -0400 RouterOS Ошибка времени ожидания при обновлении Ошибка времени ожидания при обновлении RouterOS в форуме RouterOS.
Привет, сообщество! Наши Mikrotik 2011UiAS и 3 cAPs столкнулись с проблемой — они больше не могут подключиться к серверам обновлений. Хотя они корректно получают changelog, соединение прерывается с ошибкой «connection timeout» вскоре после нажатия кнопки download&upgrade. Есть какие-то советы или известные проблемы? Интернет, конечно, работает — даже пинг до upgrade.mikrotik.com проходит. Спасибо!
10.08.2016 13:27:00, tomZ.]]> http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392557 http://mikrotik.moscow/forum/forum57/85035-oshibka-vremeni-ozhidaniya-pri-obnovlenii/message392557 Wed, 10 Aug 2016 13:27:00 -0400 RouterOS