kvm/раздать интернет/

Надо в virt-manager вызвать свойства коннекта к гипервизору qemu system, на вкладке network создать еще одну сеть, стартануть ее. libvirt при этом создаст для этой сети бридж virbrN. Затем в обоих виртуальных машинах подключить сетевые адаптеры к этой сети. Виртуальные машины станут directly connected в этой сети через этот бридж. И никакой магии с iptables на хосте не нужно.

И никакой магии с iptables на хосте не нужно.

Это в обычном случае вроде как и не нужно, проблема вся в том, что создается виртуальный свитч virbr1 для этой изолированной сети. У меня он настроен в режиме none, не имеет ip адреса по логике вещей и не нужно, т.к. он не является шлюзом. Ну а трафик через него гонится в любом случае. А фильтруется он как раз через iptables на хосте.

Запутался окончательно...

Так сформулируйте чётко исходную задачу, которая поставлена перед вами.
А то пока совершенно непонятно, зачем городить весь этот огород с виртуалками, фаерволами, натами и проксями.

Так сформулируйте чётко исходную задачу, которая поставлена перед вами.

Ну одну задачу я выполнил, гость ВМ1 удачно ходит через прокси. Задача номер два, поднять на ВМ1 впн соединение. что тоже удачно. Настроить форвардинг на госте ВМ1 и заставить ВМ2 ходить в интернет через ВМ1. Т.е. маскарадинг (Nat) настроен через tun устройство на ВМ1. Но ВМ2 не хочет ходить в инет как задумано, пинг на ней получается меньше чем на ВМ1.

Ошибка в том, что перечисленное вами в реальности не является исходной задачей.
Вы описали лишь один из вариантов реализации некоторой концепции.
Нет никаких гарантий, что этот вариант решит исходную задачу корректно.

1. Почему решили, что заворачивать трафик средствами прокси будет лучше, чем маршрутизировать его через VPN-интерфейс?
   
2. Зачем вообще нужно поднимать виртуалки, чего не хватает в хостовой операционке?
   
3. Для чего создавать именно 2 виртуалки, а не 1, 3 или 5?
   
4. Почему выбран KVM, а не LXC или что-то иное?
   
5. Зачем трафик гостя #2 заворачивать через гостя #1, разве не будет эффективнее пустить их параллельно?

Короче говоря, не понимая цели работы, тут можно наворотить такого, что потом придётся всё переделывать.

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

Короче говоря, не понимая цели работы, тут можно наворотить такого, что потом придётся всё переделывать.

1.Трафик и так заварачивается сначала в впн. Потом в прокси. Точнее в ссш туннель, который заворачивается в тор, который живет в отдельном контейнере. 3. 3,5 не нужно надо просто раздать интернет с шлюза на другую сеть. 4. Было выбрано что доступнее, т.к. запустилось на grsec ядре.На virtbox такая сеть работает без проблем, т.к. там концепция внутренней сети другая и хостом не контролируется, но virtbox не поднимается на grsec из за своих модулей. 5.Это будет не такая цепочка, если пустить их параллельно, точнее придется поднимать впн внутри каждой виртуальной машины, а хочется на шлюзе.

Почему в конфигурации с виртуальными машинами и бриджом бридж должен что-то фильтровать?

Я не до конца понимаю, т.к. квм особо не пользовался. Но трафик не идет если не добавить это правило:

iptables -t nat -A REDSOCKS_FILTER -i virbr1 -j RETURN

virsh domiflist ВМ1
vnet1 NAT  #virbr0 сеть NAT
vne2  isolated # вот это свитч virbr1 изол. сеть
virsh domiflist ВМ2
vnet0 isolated #вот это свитч virbr1 
внутри машины ВМ1 поднимаются адаптеры  eth0 #virbr0, eth1 # это подключено к virbr1
внутри машины ВМ2 один адаптер eth0 #virbr1
Если не добавить правило выше, то http трафик от eth0 (вм2) не идет к eth1 (вм1)

В огороде бузина, а в Киеве дядька. Нат выполняет ВМ1, а магическое правило добавляется на хост в какую-то нестандартную цепочку, да не в фильтр, а в нат. Ну бред же. «Дорогая редакция, у меня в подполье стук.»

какую-то нестандартную цепочку, да не в фильтр, а в нат. Ну бред же.

Чтоб вы поняли дальнейший смысл IPTABLES -t nat -A PREROUTING -p tcp -j REDSOCKS_FILTER

Можно еще так сделать, чтоб трафик пошел от ВМ2 к ВМ1

iptables -t nat -A PREROUTING -p tcp ! -i virbr1 -j REDSOCKS_FILTER

Да трафик между виртуалками вообще не должен в IP стек хоста попадать. Потому что destination mac адреса у этого трафика принадлежат интерфейсам, у которых нет IP адресов на хосте. Этот трафик должен коммутироваться бриджом на хосте с одного tun интерфейса на другой tun интерфейс (vnetN интерфейсы это tun). Может ты вручную на хосте добавил адреса на tun интерфейсы? Так это «наши руки не для скуки».

Может ты вручную на хосте добавил адреса на tun интерфейсы?

С vnet интерфейсами вообще ни каких манипуляций не производил. Добавил изол. сеть из xml:

<network>
  <name>isolated</name>
  <bridge name='virbr1' stp='on' delay='0'/>
</network>

STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003, length 35

Да трафик между виртуалками вообще не должен в IP стек хоста попадать.

Попробовал пересобрать libvirtd на разных версиях одинаковое поведение. Стоит добавить правило в цепочку PREROUTING, трафик не идет между виртуалками. Почему тогда в описании изолированной сети говорится, что ограничение трафика только для внешнего мира, но не для хоста. вот например http://integrator.adior.ru/index.php/gui-kvm/349-nastrojka-virtualnoj-seti-kvm-kak-isolated-set.

Это всё из-за того, что libvirt добавляет на бриджовый интерфейс ip адрес. После этого броадкасты, попадающие в этот бридж, доставляются и на этот адрес и попадают в ip стек хоста. Но юникасты на адреса виртуалок всё равно не должны попадать в ip стек хоста.

Можно попытаться сделать виртуальную сеть без настроек ip в virt-manager. Но тогда адреса виртуалок в этой сети надо либо задавать на виртуалках статически, либо одна из виртуалок должна раздавать их по DHCP.

Мне кажется я понял, в чём твоя проблема. Если в виртуальной сети задана конфигурация IPv4, libvirt добавляет на бриджовый интерфейс адрес (чтобы хост тоже был в этой сети) и запускает на этом бриджовом интерфейсе dnsmasq. Этот dnsmasq (это dhcp сервер и dns forwarder в одном приложении) в качестве маршрута по умолчанию и dns сервера выдаёт по dhcp адрес хоста на этом бриджовом интерфейсе. Виртуалка, получившая настройки IPv4 по DHCP от этого dnsmasq, будет использовать хост в качестве шлюза по умолчанию и dns сервера. А тебе надо, чтобы вм2 в качестве шлюза по умолчанию и dns сервера использовала вм1. Надо на вм2 статически настроить шлюз по умолчанию, и адрес dns сервера.

А тебе надо, чтобы вм2 в качестве шлюза по умолчанию и dns сервера использовала вм1. Надо на вм2 статически настроить шлюз по умолчанию, и адрес dns сервера.

Только наверно вм1 должна быть шлюзом она же раздает интернет. Сразу так и сделал. Вот еще что пишется в офиц. доке, самый последний абзац. https://libvirt.org/formatnetwork.html#examplesPrivate Если создать сеть без gateway addresses (У меня virbr1 не имеет ip адреса). То вроде должна быть сеть как они пишут «very private» or «very isolated». А так чет пока не могу догнать как это вм2 должна быть шлюзом, если интернет она получает от вм1? Чет все в моей голове перевернулось=) И еще почему то при таких настройках демон ebtables пихает свои правила вроде как они и не нужны, зачем открыты порты на сервер dhcp и днс, если ifconfig virbr1

 virbr1 Link encap:Ethernet  HWaddr 52:52:x:x
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

iptables-save | grep virbr1 

-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEP 

Пока у меня так, на ВМ1 на которой есть интернет:

auto eth1 #интерфейс который смотрит в "локалку"
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0

на ВМ2, которая должа получить инет:

eth0 - адрес 192.168.1.27
шлюз - 192.168.1.1
днс - да любой может быть хоть гугл 8.8.8.8

Попробывал шлюз прописал на вм1 и на вм2. Такие же симптомы.