Почему контейнер с сетью «bridge» на VPS сервере не может подключиться к API?

Question

[Ayudag]

Привет.
Столкнулся с проблемой при запуске контейнера на VPS.

Используя команду

docker run -d --name test-app --restart unless-stopped -p 8001:8080 test-app

(cеть "bridge"), приложение не может подключиться к внешнему API.
Однако, если запускать контейнер с сетью "host":

docker run -d --name test-app --restart unless-stopped --network host test-app

- приложение работает без проблем.
При этом на локальной машине контейнер с сетью "bridge" запускается и взаимодействует с внешним API корректно.

Понимаю, что использование сети "host" — не лучшая практика, поэтому хочу разобраться, в чем может быть причина такой ситуации.

Примечание: моя программа - это Телеграм-бот. Бот успешно обрабатывает сообщения пользователя и отвечает ему. Но когда программе нужно подключиться к внешнему API, ей не удается этого сделать.

Comments

[shurshur]

Для начала зайти внутрь контейнера и проверить изнутри что с сетью.

docker exec -it test-app /bin/bash

(Надеюсь баш внутри есть, если нет то возможно есть /bin/sh)

Дальще пробовать curl, ping и всё такое - в теории тоже может быть вырезано из контейнера.

Самая простая причина - это наверчено в iptables. Например, если в конфиге демона docker (/etc/docker/daemon.json) выключено управление iptables, то сеть не будет автоматически настроена так, как надо, и это придётся делать вручную.

Но в целом может быть ещё стопоцот других причин, например, выключенный ip_forward или криво указанный upstream dns. Надо тестить, искать ошибки, реагировать на найденное.

[Valentin Barbolin]

Кастомные настройки firewall делал?
sudo iptables-save в студию.

[Ayudag]

shurshur, внутри контейнера ping работает, файл daemon пустой, ip_forward включен. В правилах iptables в FORWARD прописан DROP - может быть в этом проблема или это правильная настройка?

[Ayudag]

Valentin Barbolin, кастомные настройки не делал.
iptables:

# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 19:40:43 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Oct 23 19:40:43 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 19:40:43 2024
*nat
:PREROUTING ACCEPT [2850:133435]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [87:6603]
:POSTROUTING ACCEPT [87:6603]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
COMMIT
# Completed on Wed Oct 23 19:40:43 2024

[Valentin Barbolin]

Ayudag, Судя по выводу контейнер test-app выключен либо работает в режиме host.

[shurshur]

Ayudag, DROP тут это policy, это что делется в случае если другие правила в этой цепочке не подошли. А судя по отсутствию правил, связанных с IP-адресами контейнеров, в цепочке DOCKER, ни одного контейнера не запущено или они не в bridge-сетях.

Можно посмотреть docker network inspect test-app для изучения чё как запущен контейнер. А также docker network inspect bridge - там будет в том числе список контейнеров с адресами.

[shurshur]

Ayudag, ещё я бы проверил нет ли на хосте какой-нить управлялки iptables типа firewalld.

[Ayudag]

Valentin Barbolin, виноват, не запустил контейнер.

# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 22:51:04 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Oct 23 22:51:04 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 22:51:04 2024
*nat
:PREROUTING ACCEPT [1995:93938]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [129:9071]
:POSTROUTING ACCEPT [129:9071]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 8080 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8001 -j DNAT --to-destination 172.17.0.2:8080
COMMIT
# Completed on Wed Oct 23 22:51:04 2024

[Ayudag]

shurshur, я не запустил контейнер, извиняюсь. вот с запущенным контейнером:

# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 22:51:04 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Oct 23 22:51:04 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Wed Oct 23 22:51:04 2024
*nat
:PREROUTING ACCEPT [1995:93938]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [129:9071]
:POSTROUTING ACCEPT [129:9071]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 8080 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8001 -j DNAT --to-destination 172.17.0.2:8080
COMMIT
# Completed on Wed Oct 23 22:51:04 2024

--------------------------------------------------------------------------------------------------

управлялок iptables на хосте не нашел.
docker network inspect bridge:

[
{
"Name": "bridge",
"Id": "7602bbdfd9d4f63f4fbac77020790bfff29b3f346b17babd572065aa5eb72aa1",
"Created": "2024-10-23T21:00:12.612812129+03:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"ecf0bdd22cde20a91a028e09c2ff8e4541fcbac2a4b9cc8b388c59102c47625b": {
"Name": "test-app",
"EndpointID": "67c1b82eafa238fe2753200c00fbde26ddd3184f5d6a23b1628b1442dcd8bfb3",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]

но насколько я разобрался, проблем здесь нет.
если нужно, могу отправить что выводится после команды sudo inspect test-app

[Valentin Barbolin]

Ayudag, В iptables все ровно. Надо пробовать внутри контейнера проводить диагностику.

внутри контейнера ping работает

Что насчет curl ? какая вообще ошибка когда приложение не может подключиться к API ?

[Ayudag]

Valentin Barbolin, В момент подключения к API, приложение будто замирает - логи перестают поступать в консоль и при этом исключения не выскакивают. Потом я добавил в программу таймауты к подключению и чтению:

connection.setConnectTimeout(5000); // 5 seconds connection timeout
connection.setReadTimeout(10000); // 10 seconds read timeout

Теперь когда этот контейнер запускаю на серваке выскакивает след исключение:

java.net.SocketTimeoutException: Read timed out
        at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:283)
        at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:309)
        at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350)
        at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803)
        at java.base/java.net.Socket$SocketInputStream.read(Socket.java:961)
        at ...

Попробовал внутри контейнера отправить запрос к этому API с помощью curl - тишина минуты 3, потом выводится следующее:
curl: (35) Recv failure: Connection reset by peer

Я использую YandexGPT API и возможно проблемы именно с ним. Когда с помощью курла отправляю тестовый запрос на другой API - всё работает. Насколько я знаю, при отправке запроса к YandexGPT именно из браузера - выскакивает cors ошибка (нужна доп настройка). Может ли быть такое, что моя проблема тоже связана с этим?

[shurshur]

Ayudag, если это легальный API для приложений - то ограничения CORS к нему никто не будет применять, вместо этого контроль запросов происходит через ключи доступа.

[Valentin Barbolin]

Ayudag, Попробуй еще запустить пустой контейнер с debian и в нем выполнить curl.

[Ayudag]

Valentin Barbolin, попробовал из другого контейнера - тоже самое:
curl: (35) Recv failure: Connection reset by peer

Еще запустил контейнер с другим Телеграм-ботом в bridge, который работает с другим API - проблем никаких нет.

[Ayudag]

shurshur, такой вопрос: если у меня 1 или 2 контейнера будут работать в сети host, а остальные контейнеры в сети bridge (между собой они не общаются) - это приемлемая практика или это совсем плохо?

[shurshur]

Ayudag, Connection reset by peer - это RST, может быть признаком блокировки. Не блокируется ли этот API в стране пребывания сервиса?

[shurshur]

Ayudag, вполне нормально разные контейнеры запускать по-разному. Например, один из способов поднять VPN - это запустить его в host-контейнере.

Нужно только понимать, что host-контейнер это как запуск напрямую на хосте без сетевой изоляции. Если это понимать и учитывать - то всё нормально. А то например пусть есть сервис на порту 123 у которого есть ещё порт 456 с админским интерфейсом. Когда мы его запускаем в стандартной bridge-сети - то порт 123 мы явно публикуем, а порт 456 нет и это не вызывает вопросов. Но порт 456 в host-контейнере будет доступен снаружи, так что надо будет об этом позаботиться (выключить админский интерфейс или зарезать к нему внешний доступ явно).

[Ayudag]

shurshur, всё понял, спасибо!

Решил свою проблему - поменял значение MTU с 1500 на 1450 в конфигурационном файле docker.service. Помогли в поддержке провайдера.

Спасибо большое за помощь, узнал много нового!

[Ayudag]

Valentin Barbolin, решил свою проблему - поменял значение MTU с 1500 на 1450 в конфигурационном файле docker.service. Помогли в поддержке провайдера.

Большущее спасибо за помощь!

[shurshur]

Ayudag, у нас в конторе раньше ходила шутка, что все проблемы сводятся к трём:

1. Проблемы с дисками.
2. Проблемы с DNS.
3. Неправильный MTU.

Была однажды история, задеплоили новый сервер и забыли ему понизить MTU (мы всегда делаем, чтобы во все ipsec пролазило). И вот идёт трафик по протоколу с маленькими пакетами, всё работает, пока не случается всплеск трафика и пакеты склеиваются, переставая влезать в MTU, что приводит в итоге к потере этих пакетов и реконнекту по таймауту. Поддержка несколько часов пыталась убедить поставщика, что у нас всё хорошо и это у них проблемы :)

[Ayudag]

shurshur, поучительная история, надо взять на заметку это правило :DD

[shurshur]

Ayudag, это не всегда нужно, но у нас просто ICMP запрещены политикой сетевой безопасности и если пакет в транзитном узле пошлёт ICMP о фрагментации, то мы его не получаем.

Если вот прям все уменьшат MTU до 1450, то интернет перейдёт с 1500 на 1450 и таким как мы надо будет уменьшать MTU ещё сильнее, чтобы обходить проблему.

Что у провайдера не работает 1500 это само по себе уже нетиповая ситуация. Например, там VPN (какой-нить PPPoE) и это в него не пролазит 1500. На хосте MTU по умоланию ставится VPN-клиентом в 1450, а докер создаёт новый сетевой неймспейс с 1500. По идее, там могло бы работать и с фрагментацией, инициированной хостом, но что-то вот не работает, хотя возможно и это можно было бы починить (но работа с постоянной фрагментацией пакетов это всё равно нехорошо для эффективной работы сети).

[Ayudag]

shurshur, понял, спасибо за пояснение. Полезная информация, не сталкивался с таким раньше.