Qemu виртуальная машина не отвечает через VPN

Содержание

Вопрос или проблема
Ответ или решение
Проблема с доступом к виртуальной машине QEMU через VPN: возможные причины и решения
1. Настройка сети QEMU
2. Маршрутизация
3. Настройки iptables
4. Проверка настроек OpenVPN
5. Логирование и отладка
Заключение

Вопрос или проблема

У меня есть машина с сервером OpenVPN и несколько виртуальных машин на ней. Раньше они были в VirtualBox (сеть: мост), но я перехожу на QEMU.

Все, кроме машины, которую я переместил в QEMU, работает нормально. Однако новоперемещённая машина не может ответить мне, когда я подключаюсь через VPN (соединение сброшено пэром). Она работает нормально, когда к ней обращаются из LAN. Все другие машины (VirtualBox) по-прежнему могут нормально отвечать мне через VPN.

Я предполагаю, что мне не хватает маршрута, который бы говорил виртуальной машине, как получить доступ к 10.8.0.0/24?

Вот детали:

QEMU/VPN/Virtualbox HOST IP: 192.168.99.20
QEMU guest static IP: 192.168.99.19
OPENVPN net: 10.8.0.0/24


root@R3:~# nmcli connection show
NAME    UUID                                  TYPE      DEVICE 
br0     c66d9827-b2f3-4ab3-bfdd-6d1e5ffe383e  bridge    br0    
10G-BR  08aa8e2b-df95-408d-aeb2-a7f2b04ebf23  ethernet  enp1s0 
lo      e886dbf1-d7fd-4af3-a796-3e03a905db70  loopback  lo     
tun0    52629a83-8049-4f8e-992b-2a720abbf857  tun       tun0   
vnet2   cc718301-2dc7-4691-afb4-dcc4f6e6e317  tun       vnet2 


root@R3:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 04:92:26:d1:21:4a brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 74:fe:ce:ea:d6:dc brd ff:ff:ff:ff:ff:ff
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ea:6e:5b:0a:b2:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.20/24 brd 192.168.99.255 scope global noprefixroute br0
       valid_lft forever preferred_lft forever
    inet6 2a00:ee2:1205:fc00:6e3:89aa:7e1d:f181/64 scope global temporary dynamic 
       valid_lft 889sec preferred_lft 889sec
    inet6 2a00:ee2:1205:fc00:210f:23c8:b78a:3007/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 889sec preferred_lft 889sec
    inet6 fe80::cfb8:a019:63af:9832/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
16: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:72:34:28 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe72:3428/64 scope link 
       valid_lft forever preferred_lft forever
17: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.1/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::ae8f:b2f9:8f98:a495/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever



root@R3:~# route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    425    0        0 br0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.99.0    0.0.0.0         255.255.255.0   U     425    0        0 br0

И правила брандмауэра для доступа к LAN и NET из VPN (изменил это с enp1s0 на br0, и теперь сеть и LAN работают через VPN):

root@R3:~# iptables -A FORWARD -o br0 -i tun0 -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
root@R3:~# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
root@R3:~# iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

Есть идеи?

Спасибо!

Ответ или решение

Проблема с доступом к виртуальной машине QEMU через VPN: возможные причины и решения

При работе с виртуальными машинами и настройками VPN может возникнуть множество проблем, особенно при переходе с VirtualBox на QEMU. Ваш случай, когда виртуальная машина на QEMU не отвечает при доступе из VPN, но работает в локальной сети, требует тщательного анализа настроек сети. Давайте рассмотрим возможные причины и их решения.

1. Настройка сети QEMU

Убедитесь, что ваша виртуальная машина QEMU настроена на использование правильного сетевого интерфейса. Вы уже используете br0, что является правильным подходом для Bridged Networking. Это позволяет виртуальной машине действовать как обычный компьютер в вашей локальной сети.

Проверьте конфигурацию QEMU:

qemu-system-x86_64 \
  -enable-kvm \
  -m 2048 \
  -hda /path/to/your/image.qcow2 \
  -net nic \
  -net bridge,br=br0

2. Маршрутизация

Поскольку виртуальная машина (192.168.99.19) плохо реагирует на VPN (10.8.0.0/24), возможно, не хватает маршрутов для передачи данных в эту подсеть. Ваши текущие маршруты соответствуют нужным, но есть смысл проверить, правильно ли установлены маршруты в самом клиенте VPN.

Проверьте таблицу маршрутизации на клиенте VPN и убедитесь, что маршруты 10.8.0.0/24 направляются на ваш VPN-сервер (IP 10.8.0.1).

3. Настройки iptables

Ваши правила iptables выглядят корректно, так как вы используете MASQUERADE для преобразования адресов NAT, что необходимо для доступа к вашим машин из VPN. Однако убедитесь, что правила применяются к нужным интерфейсам.

# Разрешаем трафик от VPN к локальной сети
iptables -A FORWARD -o br0 -i tun0 -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

# Разрешаем возвращающий трафик
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Применяем MASQUERADE для исходящего трафика
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

4. Проверка настроек OpenVPN

Убедитесь, что в настройках вашего OpenVPN-сервера указаны директивы для маршрутизации. В частности, вам может понадобиться добавить строки, такие как:

push "route 192.168.99.0 255.255.255.0"

Это позволит клиентам VPN заниматься маршрутизацией трафика к вашей локальной сети.

5. Логирование и отладка

Если проблема сохраняется, рекомендуется включить режим отладки в OpenVPN и просмотреть логи. Сразу после подключения клиента проверьте, какие пакеты отправляются и принимаются.

# Включите отладочные логи
verb 3

Заключение

Настройка доступа к виртуальным машинам через VPN может быть сложной задачей, особенно при переходе между различными технологиями виртуализации. Убедитесь, что вы проверили все вышеперечисленные аспекты настройки сети, маршрутизации, правил iptables и конфигурации OpenVPN. Следуя этим рекомендациям, вы сможете устранить проблему с доступом к виртуальной машине QEMU через VPN. Если после выполнения этих шагов проблема не решится, возможно, стоит рассмотреть дополнительные методы диагностики сети, такие как использование tcpdump для анализа трафика между клиентом, сервером и виртуальной машиной.