Доступ к сервисам docker извне LAN

Правила файрвола дефолтные докеровские

Только докеровские, или все же ещё и дефолтные из firewalld?

Посмотри, какие зоны активны, добавь в нужную свою сеть wireguard

По tcpdump я вижу, что запросы на порт приходят, но, видимо, не уходят обратно.

а если из контейнера попробовать к чему-нибудь в сети WG подключиться, хотя бы телнетом?

Если я все правильно понимаю, то у меня все правила в nftables траслируются через iptables. firewalld нет, даже установленного. Дистр Debian 12.7

dpkg -L | grep firewall

*пусто*

Из контейнера я не могу пинговать клиентов wireguard.

ping 10.70.80.3
PING 10.70.80.3 (10.70.80.3) 56(84) bytes of data.
^C
--- 10.70.80.3 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4107ms

Тогда из легких проблем (с быстрым решением) в голову приходит только конфликт сетей в докере и в wg

посмотри ip route list на проблемном сервере

Если нет, то тебе все же придётся внимательно читать правила в файрволе

З.Ы. и на всякий случай посмотри /etc/docker/daemon.json, вдруг что бросится в глаза

З.З.Ы. я надеюсь, что это именно отдельный docker, а не нода кластера k8s с взрослым cni плагином и политиками безопасности?

Докер поднимает виртуальную сеть. Ты там конфиги какие-то в самом докере (композ файле) неправильно написал. Обсуждать нечего

Укажи, пожалуйста, что неправильно в конфиге

services:
  app:
    image: 'jc21/nginx-proxy-manager:2.11.3'
    container_name: nginx-proxy-manager
    restart: unless-stopped
    volumes:
      - /mnt/docker-ssd/containers/nginx-proxy-manager/data:/data
      - /mnt/docker-ssd/containers/nginx-proxy-manager/letsencrypt:/etc/letsencrypt
    environment:
      - DISABLE_IPV6="true"
    network_mode: host

default via 192.168.77.1 dev eno1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.19.0.0/16 dev br-8142574d5896 proto kernel scope link src 172.19.0.1
172.23.0.0/16 dev br-812b1483a0fc proto kernel scope link src 172.23.0.1
172.32.0.0/24 dev br-e94be26d266d proto kernel scope link src 172.32.0.1
192.168.77.0/24 dev eno1 proto kernel scope link src 192.168.77.30

Полные правила nftables - https://pastebin.com/VZn7nLnq

Файла daemon.json нет. Сам я ничего дополнительно не конфигурировал. По умолчанию он тоже не поставляется с пакетом докера.

Это не нода, не кластер, не сворм и т. п. Обычный докер на обычном домашнем сервере.

Добавил вручную маршрут на сервере

ip route add 10.70.80.0/24 via 192.168.77.1 src 192.168.77.30

и проблема решилась.

Я в общих чертах понимаю маршрутизацию, и всегда думал, что если у устройства нет статического маршрута до какой-то сети, то опрос идет всегда дефолтного маршрута. Т. к. у сервера не было маршрута до 10.70.80.0/24, он должен был спросить 192.168.77.1, который является пиром (сервером по сути) этой сети и знает маршрут до 10.70.80.0/24. Почему тогда соединение не проходило?

если у устройства нет статического маршрута до какой-то сети, то опрос идет всегда дефолтного маршрута

Как бы да, но RFC-1918.

Я понимаю, что это зарезервированная частная подсеть. К ним в этом отношении другие правила? В двух словах можно для?

В двух словах можно для?

Я тоже не настоящий сварщик. ☺

Вообще, это логично. Если у тебя дома условный 192.168.0.0/24 и 10.10.0.0/24 для личного VPN, то на работе 10.10.0.0/16 может оказаться служебной сетью, куда не нужно лезть, а в кафешке у работы 10.0.0.0/8 это вообще может оказаться ботнет какира из соседнего дома, которому в 192.168.0.0/16 доступ давать мягко говоря нежелательно.

Non-RFC1918 резольвится глобальными DNS, и в них как бы логично маршруты строить, а в локальные сети, где DNS вообще может не быть, какой вообще смысл строить маршруты, если это отдельные подсети?

За остальным — в RFC-1918. ☺ Там хоть и размазано, но мысль описана развёрнуто.

Не вижу, каким боком он тут относится

если у устройства нет статического маршрута до какой-то сети, то опрос идет всегда дефолтного маршрута

Не опрос. Пакет просто отправляется на дефолтный шлюз. Пусть лошадь думает, у нее голова большая

и проблема решилась.

Весьма странно

Вообще чудес не бывает, должна быть какая-то причина, но искать её тебе (если есть желание), и возможно долго

Есть несколько мыслей, куда можно копнуть

• Если сервер настраивал кто-то другой (и особенно если есть два шлюза из домашней сети), то там может быть policy based routing

• если nat на роутере участвует в обмене трафиком между туннелем и домашней сетью, то можно его посмотреть. Но тогда бы добавление маршрута ничего не поменяло

На роутере настроен NAT и форвардинг так, чтобы

• какие-нибудь протоколы динамической маршрутизации на сервере используются? bgp, osfp, is-is? Для них на сервере должен быть установлен демон frr, quagga или что-нибудь из их аналогов. Но в любом случае маршруты были бы видны в ip r l

• tc (traffic control) используется? Вообще он скорее для шейпинга, но при желании через него можно много что делать

• так, стоп. «Видимо» или не уходят?

По tcpdump я вижу, что запросы на порт приходят, но, видимо, не уходят обратно.

Здесь можно зацепиться и смотреть внимательно, как проходит трафик. Смотреть дамп внимательно - с какого адреса и на какой приходят пакеты. Есть ли ответ (возможно, на ДРУГОЙ адрес)

По очереди отслеживать путь пакетов через nft, ip rule list, ip route list

Т.е. смотреть, в каком порядке трафик идет через таблицы. И думать, под какие именно правила в таблицах он должен попасть. Версии проверять по счетчикам в nft

В docker image скорее всего не будет инструментов для отладки, но их можно запустить в отдельном image как sidecar, через тот же docker compose

Если сервер настраивал кто-то другой (и особенно если есть два шлюза из домашней сети), то там может быть policy based routing

ip rule list
ip route list $TABLE_NAME

Да.