• Не открывается внутренний сервис (Jira, LDAP, change-pass.iep.loc, git и т.п.) — ни в браузере, ни в curl
• Ошибка: Connection refused или Failed to connect на портах 80/443
• getent hosts hostname возвращает ожидаемый IP
• Проблема часто появляется после docker compose up или когда на машине много compose-проектов
• VPN подключён (tun0 / tun1 есть), но сервис недоступен

Docker создаёт bridge-интерфейсы (br-xxxxxxxxxxxx) с собственными подсетями:

• 172.17.0.0/16 — default bridge
• 172.22.0.0/16 — сеть проекта rpcserver_default
• 172.18.0.0/16 — status_app-network

Если подсеть Docker пересекается с корпоративной (часто диапазон 172.16.0.0/12, в IEP — 172.22.0.0/16), Linux направляет пакеты в Docker-bridge, а не в VPN.

Типичная ловушка: DNS и маршрут говорят разное про один и тот же хост. Поэтому кажется, что «имя резолвится — значит всё ок», а curl/браузер всё равно не открывают URL.

Выполняем подряд:

grep -n change-pass /etc/hosts /etc/resolv.conf 2>/dev/null
getent hosts change-pass.iep.loc
ip route get 172.22.224.153

Вывод при конфликте с Docker:

172.22.224.153  change-pass.iep.loc
172.22.224.153 dev br-355c08cd95dd src 172.22.0.1 uid 1891243316
    cache

Разбор по строкам:

docker compose down   # в проекте с сетью 172.22.0.0/16
ip route get 172.22.224.153

Ожидаемый маршрут:

172.22.224.153 via 10.5.192.1 dev tun0 src 10.5.193.211
    cache

Тот же IP 172.22.224.153, но теперь трафик идёт через VPN, а не в Docker-bridge.

HOST=change-pass.iep.loc
getent hosts "$HOST"

Если IP получен — резолв в порядке (DNS или /etc/hosts).

ip route get $(getent hosts "$HOST" | awk '{print $1; exit}')

Плохо — трафик в Docker:

172.22.224.153 dev br-355c08cd95dd src 172.22.0.1

Хорошо — трафик через VPN:

172.22.224.153 via 10.5.192.1 dev tun0 src 10.5.193.211

IP=$(getent hosts "$HOST" | awk '{print $1; exit}')
nc -vz "$IP" 80
nc -vz "$IP" 443
curl -vk --connect-timeout 5 "https://$HOST/"

При конфликте с Docker — Connection refused до VPN, даже если tun0 поднят.

ip route | grep 172.22
docker network ls
docker network inspect $(docker network ls -q) | grep -E '"Name"|Subnet|Gateway'

Ищите сеть, у которой Subnet совпадает с диапазоном корпоративных адресов.

Кейс 2026-08-13:

• Сеть: rpcserver_default
• Subnet: 172.22.0.0/16
• Bridge: br-355c08cd95dd
• Конфликт с: change-pass.iep.loc (172.22.224.153)

Сохраните как check-docker-network-conflict.sh:

check-docker-network-conflict.sh

#!/usr/bin/env bash
set -u
 
HOST="${1:-change-pass.iep.loc}"
 
echo "=== DNS ==="
getent hosts "$HOST" || { echo "DNS fail"; exit 1; }
IP=$(getent hosts "$HOST" | awk '{print $1; exit}')
echo "IP=$IP"
 
echo
echo "=== Route ==="
ip route get "$IP"
 
echo
echo "=== TCP 80/443 ==="
nc -vz "$IP" 80  2>&1 || true
nc -vz "$IP" 443 2>&1 || true
 
echo
echo "=== Docker routes (172.16/12) ==="
ip route | grep -E '172\.(1[6-9]|2[0-9]|3[0-1])\.' || echo "(none)"
 
echo
echo "=== Docker networks ==="
docker network inspect $(docker network ls -q) 2>/dev/null \
  | grep -E '"Name"|Subnet|Gateway' || echo "docker not available"

Запуск:

chmod +x check-docker-network-conflict.sh
./check-docker-network-conflict.sh change-pass.iep.loc

cd ~/projects/rpc.server
docker compose down

Проверка:

ip route get 172.22.224.153
curl -vk https://change-pass.iep.loc/

Маршрут должен идти через tun0, не через br-…. curl — HTTP 200.

В docker-compose.yml проекта задайте подсеть вне корпоративной:

networks:
  default:
    ipam:
      config:
        - subnet: 192.168.220.0/24

/etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "192.168.200.0/16", "size": 24 }
  ]
}

Применить:

sudo systemctl restart docker

1. Не использовать 172.16.0.0/12 для Docker, если работаете с IEP/RTLabs VPN
2. Перед docker compose up нового проекта: docker network inspect … | grep Subnet
3. При смене машины / VPN — один раз: ip route get <корп-хост>
4. Subnet каждого локального compose — в README проекта

# все маршруты Docker-bridge в 172.16/12
ip route | grep '^172\.'
 
# какой bridge за какой сетью
docker network ls
docker network inspect rpcserver_default
 
# удалить «висячую» сеть (если compose уже down)
docker network rm rpcserver_default

• Дата: 2026-08-13
• Хост: change-pass.iep.loc → 172.22.224.153
• Причина: Docker-сеть rpcserver_default (172.22.0.0/16) перехватывала маршрут
• Решение: docker compose down в rpc.server + subnet 192.168.220.0/24 в compose
• Результат: ip route get → via 10.5.192.1 dev tun0, curl → HTTP 200