тоже не силён в сетях

однако, вопросы возникают

DNS=8.8.8.8 8.8.4.4
Address=10.0.0.2/30

Если, контейнер и хост локально общаются откуда DNS «придет»? Адрес «размытый» (блин забыл как это называется, гуглить сейчас некогда) почему?

адрес 127.0.0.1 где «связан» с 10.0.0.1

В теме сетей не сильно силён))

«Источник вдохновения»...

P.S. Так эта настройка не работает или...

127.0.0.1 на хосте? По сети - никак.

Погуглил хоть, что за адрес такой - 127.0.0.1

чтобы из контейнера можно было достучаться до сервисов хоста, которые слушают на адресе 127.0.0.1

Ты делаешь хрень, не делай так. Достучаться через fqdn хоста.

Внутри docker-контейнера хостовый IP-шник можно получить следующим образом (в bash):

hostip="`ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print $2 }'`"
echo "${hostip}  dockerhost" >> /etc/hosts

Лучше это сделать в скрипте начального запуска контейнера (типа docker-entrypoint.sh, имеющегося во многих готовых контейнерах) а дальше в настройках уже использовать символическое имя хоста.

Запустим mysql, пусть слушает 127.0.0.1:5555 на стороне хоста, а из контейнера подключимся к нему используя 10.0.0.1:5555.

Вот только если слушать именно 127.0.0.1 и ты хочешь связать контейнер с хостом виртуальным интерфейсом, то у тебя нигде не получится. mysql должен слушать тогда либо все IP-шники, либо 127.0.0.1 + IP-шник виртуального интерфейса, который на стороне хоста.

fqdn

немного офтоп, но не у всех хостов есть fqdn

чтобы из контейнера можно было достучаться до сервисов хоста, которые слушают на адресе 127.0.0.1

В принципе, можно туннель поднять между контейнером и хостом. Тогда ты сможешь ломиться на хостовые сервисы, которые на 127.0.0.1 висят.

Эта настройка работает, и работает стабильно))

В этом и суть, mysql тут лишь для примера. Есть сервис, который может слушать лишь 1 ip адрес. Вот и хочу сделать, чтобы до сервиса нельзя было достучаться из сети, только локально из контейнеров.

Хмм... А с использованием тоннелей можно каждому контейнеру присвоить свой ip? Можно ли будет организовать общение между контейнерами?

А с использованием тоннелей можно каждому контейнеру присвоить свой ip?

Нет, там каждому удаленному сервису выделяется локальный tcp-port, который сопоставляется с каким-либо портом на удаленном сервере, и когда ты коннектишься на локальный порт через свой 127.0.0.1, tcp-cоединение пробрасывается на удаленный сервер на соответствующий порт. Это подразумевает, что на хосте у тебя должен висеть соответствующий туннельный демон.

Я так PostgreSQL админю на VPS в графическом режиме – поднимаю SSH-туннель, запускаю локально pgAdmin и вперёд...

Можешь попробовать для эксперимента поднять в контейнере SSH-туннель на хост:

ssh -f -N -L 127.0.0.1:5555 :127.0.0.1:5555 -p <host_ssh_port> <host_login>@<host_ip>

<host_ip> - я так понимаю, у тебя 10.0.0.1. <host_ssh_port> - по умолчанию 22-й, если ты его не менял. <host_login> - любой логин, до которого можно достучаться по SSH.

Ну и в контейнере просто подключайся к хостовой mysql через 127.0.0.1:5555.
Грохнуть потом туннель в контейнере можно командой:

pkill -f '5555:127.0.0.1:5555'

(bash-скрипты себе соответствующие нацарапай)

Для реальной работы лучше, конечно, подобрать облегченный туннель — без шифрования.

Можно ли будет организовать общение между контейнерами?

В принципе, можно. Только какой смысл? Внутри контейнеров не имеет особого смысла слушать только 127.0.0.1 – там можно слушать все. Просто для спокойной жизни на хосте нужно аккуратно Netfilter настроить.

Если ты хочешь запускать одновременно несколько LXC-контейнеров, с какими-то чисто внутренними сервисами, то тебе правильнее организовать для них внутреннюю сетку — сконфигурить на хосте «virtual switch» и на него навесить виртуальные интерфейсы из контейнеров и из хоста. Тогда они все смогут общаться друг с другом по IP-шникам этой внутренней сетки. Ну а снаружи, естественно, доступ к этой внутренней сетке должен быть закрыт.

Можешь почитать, как это дело в Docker-е устроено, и сделать себе подобное на LXC.

Небольшое уточнение: реально для таких дел используется не switch, а bridge (мост) – то, что в Debian/Ubuntu устанавливается пакетом bridge-utils. У тебя этот пакет, по идее, должен быть уже установлен, да и мост скорее всего уже создан (попробуй в консоли «brctl show»).

На эту тему — как организовать внутреннюю сетку для LXC-контейнеров - полно в инете инфы. Погугли...

Что ж, всё оказалось гараздо проще. На помощь прилетел iptables. Вся задача сводится к запуску одной команды в консоли c root правами:

sysctl -w net.ipv4.conf.ve-machine1.route_localnet=1 && \
iptables --table nat --append PREROUTING \
    --in-interface ve-machine1 --protocol all
    --destination 10.0.0.1 \
    --jump DNAT --to 127.0.0.1

Лично мне это решение нравится, довольно удобно и без лишних пакетов/мостов. Без нареканий работает уже чуть больше месяца.

P.S. Мб кто-нибудь заметить какие-либо минусы/уязвимости данного подхода?