refactor: improve clarity in IP block detection and health settings descriptions

This commit is contained in:
Daniel Lavrushin 2026-08-08 18:05:13 +02:00 committed by Daniel Lavrushin
parent 7be08fbe76
commit f91fd4288e
2 changed files with 4 additions and 4 deletions

View file

@ -20,9 +20,9 @@
- FIXED: **System diagnostics reported jq, sha256sum and nohup as missing while they were installed** - the check looked in fewer folders than a terminal session does.
- FIXED: **Flow offloading was reported as a problem even when it had been set up to leave b4 alone** - the check could not tell a fast path that skips b4 entirely from one held back until b4 has seen the start of a connection.
- CHANGED: **IP block detection also covers a destination that never answers its SYN** - the feature is described for addresses the firewall drops at the IP level, but it counted TLS ClientHello retransmissions, and a ClientHello exists only once a handshake has completed. An address-level block kills the handshake itself, so the single case the description named was the one case the check could not see, and what it did catch was a stateful block after the handshake.
- ADDED: **The router tests a destination itself before treating it as blocked** - packets going unanswered for one device is equally consistent with a slow server, a brief routing glitch or an uplink outage, and acting on that alone resets connections to a destination nothing was ever wrong with. A dozen destinations failing within a minute reads as an uplink outage and suspends detection rather than condemning all of them.
- ADDED: **The router tests a destination itself before treating it as blocked** - packets going unanswered for one device is equally consistent with a slow server, a brief routing glitch or an uplink outage, so acting on that evidence alone resets connections to a destination nothing was ever wrong with, and an uplink that drops for a minute looks indistinguishable from every destination being blocked at once.
- FIXED: **A destination marked blocked stayed blocked for as long as anything kept trying it** - each lookup refreshed the entry's timestamp, so the five-minute expiry was never reached while a device kept retrying, and nothing re-tested the address in the meantime. A false positive, or a block that had since been lifted, held for the lifetime of the traffic.
- ADDED: **An IP Health section in Settings** - how long a destination stays marked unreachable had no control of its own, and it belongs there rather than among a set's options, since whether an address answers depends on the address and the path to it rather than on the set that happened to match it.
- ADDED: **An IP Health section in Settings** - whether an address answers depends on the address and the path to it rather than on the set that happened to match it, so the verdict is one shared judgement rather than a per-set one, and how long it lasts had no control of its own.
- ADDED: **A switch that strips unreachable addresses out of DNS answers** - a CDN answers with several addresses of which the firewall drops only some, so one device hangs on a blocked one while another on the same network loads the site. Pinning a working address by hand in the hosts file or as a `dnsmasq` alias had to be done per address, per domain, and again whenever the CDN changed its addresses.
## [1.74.2] - 2026-08-02

View file

@ -20,9 +20,9 @@
- ИЗМЕНЕНО: **Несколько адресов Worker перебираются в случайном порядке** - они перебирались строго как записаны, поэтому первый принимал весь трафик и все ограничения по частоте запросов.
- ИСПРАВЛЕНО: **Flow offloading отмечался как проблема, даже когда был настроен так, чтобы не мешать b4** - проверка не отличала быстрый путь, полностью обходящий b4, от того, который включается только после начала соединения.
- ИЗМЕНЕНО: **Обнаружение блокировки по IP охватывает и адрес, который не отвечает на SYN** - функция описана для адресов, отбрасываемых файрволом на уровне IP, но считала повторы TLS ClientHello, а ClientHello появляется только после установленного рукопожатия. Блокировка по адресу убивает само рукопожатие, поэтому единственный случай, названный в описании, оказался тем самым, который проверка увидеть не могла, а ловила она блокировку с отслеживанием состояния уже после рукопожатия.
- ДОБАВЛЕНО: **Роутер сам проверяет адрес, прежде чем считать его заблокированным** - отсутствие ответов у одного устройства одинаково хорошо объясняется медленным сервером, кратким сбоем маршрутизации или обрывом аплинка, и решение по одному этому признаку сбрасывало соединения к адресу, с которым всё было в порядке. Десяток адресов, отвалившихся за минуту, читается как обрыв аплинка и приостанавливает обнаружение, вместо того чтобы записать их все в заблокированные.
- ДОБАВЛЕНО: **Роутер сам проверяет адрес, прежде чем считать его заблокированным** - отсутствие ответов у одного устройства одинаково хорошо объясняется медленным сервером, кратким сбоем маршрутизации или обрывом аплинка, поэтому решение по одному этому признаку сбрасывало соединения к адресу, с которым всё было в порядке, а аплинк, пропавший на минуту, было не отличить от разом заблокированных адресов.
- ИСПРАВЛЕНО: **Адрес, помеченный как заблокированный, оставался таким, пока к нему хоть что-то обращалось** - каждая проверка кэша обновляла отметку времени, поэтому пятиминутный срок не наступал, пока устройство продолжало попытки, и ничто не перепроверяло адрес. Ложное срабатывание или уже снятая блокировка держались столько же, сколько шёл трафик.
- ДОБАВЛЕНО: **Раздел «Доступность IP» в настройках** - у срока, в течение которого адрес числится недоступным, не было собственной настройки, и место ей именно там, а не среди параметров сета: отвечает адрес или нет, зависит от самого адреса и пути к нему, а не от сета, который его поймал.
- ДОБАВЛЕНО: **Раздел «Доступность IP» в настройках** - отвечает адрес или нет, зависит от самого адреса и пути к нему, а не от сета, который его поймал, так что вердикт один на все сеты, а у срока его жизни не было собственной настройки.
- ДОБАВЛЕНО: **Переключатель, вырезающий недоступные адреса из DNS-ответов** - CDN отдаёт несколько адресов, из которых файрвол отбрасывает лишь часть, поэтому одно устройство зависает на заблокированном, пока другое в той же сети открывает сайт. Рабочий адрес приходилось прописывать вручную в hosts или через alias в `dnsmasq` - для каждого адреса, для каждого домена и заново при каждой смене адресов у CDN.
## [1.74.2] - 2026-08-02