openbsd

[babut85]

не знаю как описать.

mtg run /etc/mtg4.conf

{"level":"debug","configuration":{"debug":true,"allowFallbackOnUnknownDc":false,"secret":"бла-бла","bindTo":"0.0.0.0:8444","proxyProtocolListener":false,"preferIp":"","autoUpdate":false,"domainFrontingPort":0,"domainFrontingIp":"","domainFrontingProxyProtocol":false,"tolerateTimeSkewness":"","concurrency":0,"publicIpv4":"","publicIpv6":"","domainFronting":{"ip":"","port":0,"proxyProtocol":false},"defense":{"antiReplay":{"enabled":false,"maxSize":"","errorRate":0},"blocklist":{"enabled":false,"downloadConcurrency":0,"urls":null,"updateEach":""},"allowlist":{"enabled":false,"downloadConcurrency":0,"urls":null,"updateEach":""},"doppelganger":{"urls":null,"repeats_per_raid":0,"raid_each":"","drs":false}},"network":{"timeout":{"tcp":"","http":"","idle":"","handshake":""},"keepAlive":{"disabled":false,"idle":"","interval":"","count":0},"dohIp":"","dns":"","proxies":null},"stats":{"statsd":{"enabled":false,"address":"","metricPrefix":"","tagFormat":""},"prometheus":{"enabled":false,"bindTo":"","httpPath":"","metricPrefix":""}}}
,"logger":"","timestamp":1775606822334,"message":"configuration"}
{"level":"info","logger":"allowlist.ipblocklist.firehol","timestamp":1775606822335,"message":"ip list was updated"}

постучать телегой- тишина. постучать телнетом- тишина, причём соединение принимает, но не рвётся, какой бы мусор туда не вводить. брал готовый бинарник, собирал по месту- без разницы, поведение идентичное. конфиг- меньше уже некуда:
debug = true
secret = "бла-бла"
bind-to = "0.0.0.0:8444"

либо вы не проверяете сборки на железе, либо я феерично туплю

[9seconds]

Сделайте запрос курлом в прокси и покажите логи со включенным debug. Чтобы исключить побольше переменных, лучше всего, если сделаете запрос прямо с той же машины, где запущен mtg

[babut85]

я не смог решить ребус с curl- как и телнет он не может ничего из требуемого, как и телнет не оставляет ничего в логах, как и телнет висит бесконечно:

curl -kvI --resolve yandex.ru:8444:127.0.0.1 https://yandex.ru:8444/

• Added yandex.ru:8444:127.0.0.1 to DNS cache
• Hostname yandex.ru was found in DNS cache
• Trying 127.0.0.1:8444...
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• SSL Trust: peer verification disabled

я думаю, что истина где-то тут:

mtg doctor /etc/mtg4.conf

Deprecated options
✅ All good
Time skewness
✅ Time drift is 2.750131ms, but tolerate-time-skewness is 2h0m0s
Validate native network connectivity
❌ DC 1: cannot configure TCP keepalive: set tcp []:24474->[2001:b28:f23d:f001::a]:443: protocol not available
❌ DC 2: cannot configure TCP keepalive: set tcp []:28258->[2001:67c:4e8:f002::a]:443: protocol not available
❌ DC 3: cannot configure TCP keepalive: set tcp []:21531->[2001:b28:f23d:f003::a]:443: protocol not available
❌ DC 4: cannot configure TCP keepalive: set tcp []:26394->[2001:67c:4e8:f004::a]:443: protocol not available
❌ DC 5: cannot configure TCP keepalive: set tcp []:28462->[2001:b28:f23f:f005::a]:443: protocol not available
❌ DC 203: cannot configure TCP keepalive: set tcp []:16901->[2a0a:f280:203:a:5000::100]:443: protocol not available
Validate fronting domain connectivity
✅ yandex.ru:443 is reachable
Validate SNI-DNS match
❌ Hostname yandex.ru is resolved to "2a02:6b8:a::a", "77.88.44.55", "5.255.255.77", "77.88.55.88" addresses, not *
т.е. затык, предположительно, происходит при обращении mtg к серверам телеги, но эта ситуация для mtg неожиданная и никак не обрабатывается- не пишется с лог, не рвётся клиенсткое соединение- mtg просто повисает сферическим конём в вакууме.
и сразу говорю, что telemt на этой же машине, на этом же адресе, на этом же порту(т.е. при замене один в один, при том же самом окружении) работает кошерно

[9seconds]

Обращается или нет, должна быть какая-то запись в логах с параметром debug, если соединение вообще устанавливается и начинает обрабатываться. Я посмотрю на днях, в чем может быть проблема, если разыщу хост с openbsd, пока что идей нет.

[babut85]

опёнок маленький и прекрасно живёт на виртуалках. ну почти прекрасно- например, kvm, сконфигурированный без учёта некоторой багнутости реализации atapi в опёнке, может вызвать ядерную ошибку при попытке прочесть смонтированный iso-шник. но я с таким встречался лишь раз. в таком случае, если нет другой возможности, то опёнок можно доустановить по сети

[dolonet]

@babut85 @9seconds разобрался — это OpenBSD-специфичная проблема. Воспроизводить под рукой OpenBSD-хост не нужно: из Go source видно сразу.

Корневая причина: OpenBSD не поддерживает per-socket TCP keepalive (TCP_KEEPIDLE/TCP_KEEPINTVL/TCP_KEEPCNT там попросту нет, тайминг управляется системным sysctl net.inet.tcp.keepidle/keepintvl). Go это знает — src/net/tcpsockopt_openbsd.go возвращает ENOPROTOOPT для любого ненегативного значения. mtg по дефолту собирает net.KeepAliveConfig с нулевыми Idle/Interval/Count и отдаёт его в (*TCPConn).SetKeepAliveConfig в двух местах: network/sockopts.go (внутри Listener.Accept на каждом принятом коннекте, плюс в default network) и network/v2/sockopts.go (на каждом dial'е v2-сети). На OpenBSD оба пути валятся "protocol not available".

Это объясняет всю симптоматику: в mtg doctor ошибка по каждому DC, а в mtg run ядро принимает TCP-сокет, потом Listener.Accept закрывает его до того, как прокси-сервер его вообще увидит — отсюда "telnet висит и ничего не пишется в лог". Конфиг-обхода нет: keep-alive.disabled = true обнуляет только Enable, а Go всё равно дальше вызывает per-socket-сеттеры.

Прислал PR с фиксом: #459. Тот же build-tag-стаб, что в sockopts_lowat/sockopts_usertimeout/sockopts_congestion, только для keepalive: на OpenBSD вызываем SetKeepAlive(cfg.Enable) и оставляем тайминг системному sysctl, на остальных платформах поведение не меняется. Кросс-собрал под openbsd/amd64 и openbsd/arm64, go test ./network/... зелёный.

[babut85]

вроде проблема решилась. неплохо бы включить в сорцы, так как искать в issues- это не очень тривиально

[babut85]

и чтобы дважды не вставать- можно реализовать возможность биндить на разные адреса и стеки(ipv4/6) сразу, а не запускать кучу клонов ради такой возможности? я это к тому, что 0.0.0.0, наверное, на практике никому не нужен, так как 443 один, а желающих много, так что там на фронте стоит какой-нибудь sniproxy, а всякие mtg, xray, httpd и т.п. раскиданы по внутренним адресам