Настройка NAT

eno1

К бриджу врядли относиться. С учетом отсутствия подробностей убрать -i eno1 в правиле PREROUTING

А так, выхлопы
ip a
brctl show
в студию.

Правильно, потому что ты делаешь только DNAT.

Смотри когда ты подключаешься из вне на порт 22066 или с самого 95.217.80.24 на порт 22066 у тебя происходит подмена адреса назначения и пакет перенаправляется на 192.168.0.66:22.

Ответ от самого 192.168.0.66 пойдёт на 95.217.80.24 т.к. он является шлюзом, например с IP 192.168.0.1.

Но если ты с виртуалки с адресом 192.168.0.77 подключаешься на 95.217.80.24 и порт 22066 и у тебя настроена только подмена адреса назначения.

Т.е. в пакете будет написано, что адрес источника 192.168.0.77, а адрес назначения 192.168.0.66, то ответный пакет от 192.168.0.66 обратно пойдёт не на 95.217.80.24, а сразу на адрес 192.168.0.77.

Т.е. 66 и 77 находятся в одной сети.

Тебе нужно делать ещё подмену и адреса источника, т.е. SNAT или разносить виртуалки в разные сети.

Вы путаете. Согласно топику, это локальные процессы.

Ну не знаю, я вижу такую схему:

  |--------------------
  |                      tun0   192.168.0.66
95.217.80.24 eth0   br0  tun1   192.168.0.77
  |              192.168.0.1      
  |--------------------

И при такой схеме подключиться что с внешнего мира на порт 22066 и попасть на 192.168.0.66, что с самого 192.168.0.66 получится, а с 192.168.0.77 подключаясь на 22066 на IP адрес 95.217.80.24 не получится.

В любом случае нужны данные со схемой от ТС.

Сначала не tun все-таки, а tap. Во вторых все будет работать, так как, что eth0, что br0 это локальный трафик а не транзитный.
Это частая ошибка когда забывают про локальный трафик и считают его транзитным. И таки да, что бы не быть голословным, у меня на подиванном все робит не первый год в такой схеме.

В любом случае нужны данные со схемой от ТС.

Вот тут верно. Может то что описано в ОП, мы поняли не правильно.

[quote] Это частая ошибка когда забывают про локальный трафик и считают его транзитным. [/quote] Ну где же он будет локальным? Он же написал, что поднял две отдельные виртуалки - значит для хоста 95.217.80.24 он не будет локальным.

Я не понимаю, пускай ТС схему нарисует.

Как не локальный? Если на одной машине? Стандартный пример, у вас eth0, eth1... ethN все что между ними у локальных процессах это локальный. Виртуалка это тот же локальный процесс.

Как не локальный? Если на одной машине?

Где он на одной машине? Он же пишет, что поднял виртуалки.

Т.е. у хоста есть внешний IP и IP для коннекта к виртуалкам.

И он с одной виртуалки подключается на порт на внешнем IP.

И это работает, т.к. он адрес назначения подменяется на самже хост ( 192.168.0.66 ) с которого подключаются.

А потом когда он подключается с IP 192.168.0.77, то ответный пакет обратно на внешний IP хоста не пойдёт, а подёт сразу на 0.77 от 0.66.

Где он на одной машине? Он же пишет, что поднял виртуалки.

Цитата из ОП

Есть физический сервер с одним реальным IP адресом: 95.217.80.24 На нем живут виртуалки на бридже

А потом когда он подключается с IP 192.168.0.77, то ответный пакет обратно на внешний IP хоста не пойдёт, а подёт сразу на 0.77 от 0.66.

С чего бы это? если один фиг через ведро хоста пройдет.
Повторюсь, не путайте когда у вас отдельные физические машинки подключены и локал процессы. И так же повторюсь это вполне рабочая схема.

Смотрите
192.168.0.77 отправляет с br0 пакет на 95.217.80.24
Хост меняет dst c 192.168.0.77 на 192.168.0.66
Ответ от 192.168.0.66 приходит на хост! (а куда ещё?) делается обратное преобразование src с 192.168.0.66 на 95.217.80.24 но dst у нас 192.168.0.77.
Дальше смотрим кому нам отправить, а отправить на 192.168.0.77 который в бридже, отлично отправляем ответ с правильным src.

С чего бы это?

С того, что у 0.66 и 0.77 есть коннектед сеть 192.168.0.0.

Смотрите мои исправления. Нет у них сети они через ведро хоста связаны.

С того, что у 0.66 и 0.77 есть коннектед сеть 192.168.0.0.

И кто кроме ведра хоста это обеспечивает по вашему мнению?

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

Если это не так, то это некорректно.

Но допускаю, что такое поведение возможно.

Надо промоделировать, тогда могу сказать да согласен или нет.

Если это не так, то это некорректно.

Полностью корректно. Долго и мутно читаем документацию. У вас одно ведро! И все что касается роутинга всё в нем. Сколько можно повторять. Вроде недавно кому-то тут приводил пример, повторю. Предположим у вас eth1 ip 1.1.1.1/24, eth0 ip 192.168.0.1/24 так вот предположим что вы прописали биндинг какого-то сервиса для внутреннего использования только на eth0, из глобальной сети конечно 192.168.0.1 доступен не будет. Однако я как мамких какер находящийся в сети 1.1.1.0/24 прописываю роутинг до 192.168.0.1 через 1.1.1.1, при не настроенном fw весело и с песней подключусь к вашему внутреннему ресурсу. Вы скорее всего запретили FORWARD но забыли про INPUT.

СПАСИБО

Действительно, если везде удалить eno1 (тоесть не указывать интерфейс) - то всё работает даже из локальной сети!

iptables -A PREROUTING -t nat -d 95.217.80.24/32 -p tcp -m tcp –dport 22066 -j DNAT –to-destination 192.168.0.66:22

-A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE

-A POSTROUTING -t nat -s 192.168.0.0/24 -j MASQUERADE

А вот тут совсем не обязательно убирать интерфейс. Опять-таки если мы догадались про вашу схему.

И тут порекламирую свой гитхаб: https://github.com/dimez/libvirt-hook-qemu :)