Не удается перенаправить с Wireguard на виртуальную машину.

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

У меня есть ноутбук и физический сервер. Оба связаны через туннель Wireguard (wg0 как интерфейс на обоих), их IP-адреса соответственно 172.16.0.0 и 172.16.1.0.

На сервере имеется виртуальная машина (VM) с IP-адресом 192.168.122.173; интерфейс на хосте (virbr0) — 192.168.122.1.

Я хотел бы пинговать VM со своего ноутбука, но безуспешно. Вот что я сделал:


  1. Поместил оба интерфейса на сервере в одну зону Firewalld с форвардом и маскарадингом:

    $ sudo firewall-cmd --zone=home --list-all
    
    home (active)
      target: ACCEPT
      ingress-priority: 0
      egress-priority: 0
      icmp-block-inversion: no
      interfaces: virbr0 wg0
      sources: 
      services: dhcpv6-client mdns samba-client ssh
      ports: 
      protocols: 
      forward: yes
      masquerade: yes
      forward-ports: 
      source-ports: 
      icmp-blocks: 
      rich rules: 
    
  2. Активировал ip-forward в sysctl:

    $ sysctl net.ipv4.ip_forward
    net.ipv4.ip_forward = 1
    
  3. Маршрут, кажется, настроен правильно:

    $ ip route
    default via 192.168.1.1 dev enp8s0 proto dhcp src 192.168.1.25 metric 100 
    172.16.0.0/24 dev wg0 scope link 
    172.16.1.0/24 dev wg0 proto kernel scope link src 172.16.1.0 
    172.16.2.0/24 dev wg0 scope link 
    192.168.1.0/24 dev enp8s0 proto kernel scope link src 192.168.1.25 metric 100 
    192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
    

Но при попытке пинговать VM с ноутбука ничего не происходит:

    $ ping 192.168.122.173
    PING 192.168.122.173 (192.168.122.173) 56(84) bytes of data.
    From 172.16.1.0 icmp_seq=1 Destination Port Unreachable
    From 172.16.1.0 icmp_seq=2 Destination Port Unreachable
    From 172.16.1.0 icmp_seq=3 Destination Port Unreachable

Вот что можно увидеть на интерфейсе wg0 на сервере при пинге:

    $ sudo tcpdump -n -v -i wg0 icmp
    dropped privs to tcpdump
    tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
    16:19:24.721476 IP (tos 0x0, ttl 64, id 36462, offset 0, flags [DF], proto ICMP (1), length 84)
        172.16.0.0 > 192.168.122.173: ICMP echo request, id 44, seq 312, length 64
    16:19:24.721513 IP (tos 0xc0, ttl 64, id 14442, offset 0, flags [none], proto ICMP (1), length 112)
        172.16.1.0 > 172.16.0.0: ICMP 192.168.122.173 protocol 1 port 52925 unreachable, length 92
            IP (tos 0x0, ttl 63, id 36462, offset 0, flags [DF], proto ICMP (1), length 84)
        172.16.0.0 > 192.168.122.173: ICMP echo request, id 44, seq 312, length 64

И на интерфейсе virbr0 ничего нет при использовании tcpdump.

Однако, при пинговании интерфейса virbr0 с ноутбука, все работает:

    $ ping 192.168.122.1
    PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
    64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=6.11 ms
    64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=6.12 ms

А при пинге VM с сервера также все работает:

    $ ping 192.168.122.173
    PING 192.168.122.173 (192.168.122.173) 56(84) bytes of data.
    64 bytes from 192.168.122.173: icmp_seq=1 ttl=64 time=0.151 ms
    64 bytes from 192.168.122.173: icmp_seq=2 ttl=64 time=0.194 ms
    64 bytes from 192.168.122.173: icmp_seq=3 ttl=64 time=0.185 ms

Вывод заключается в том, что трафик не может быть маршрутизирован с wg0 на virbr0 на сервере, несмотря на активированный форвард и правильно настроенные маршруты.

У меня нет идеи, что можно сделать дальше, или как я мог бы искать решение.

Большое спасибо!

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

Чтобы решить проблему перенаправления трафика с Wireguard на виртуальную машину (VM), давайте рассмотрим шаги и возможные решения, учитывая предоставленные сведения.

Анализ проблемы

  1. Настройки Wireguard: У вас есть соединение через Wireguard между ноутбуком и физическим сервером, что обеспечивает удаленное подключение. Пинги с ноутбука до интерфейса virbr0 проходят успешно, что исключает проблемы на уровне Wireguard-туннеля.

  2. Сетевые настройки и маршрутизация: При команде ping к IP виртуальной машины 192.168.122.173 с ноутбука возникает ошибка "Destination Port Unreachable". Это говорит о том, что пакеты не достигают конечного IP-адреса виртуальной машины. Трафик, направленный на интерфейс virbr0 (IP 192.168.122.1), доставляется успешно, что указывает на некорректную маршрутизацию между wg0 и virbr0.

  3. Настройка Firewalld: Интерфейсы wg0 и virbr0 находятся в одной зоне Firewalld с разрешенным перенаправлением и маскарадингом, но это не решает проблему.

  4. IPForwarding: Включение IPv4-форвардинга на сервере (net.ipv4.ip_forward = 1) само по себе недостаточно. Необходимо проверить дополнительные сетевые правила и маршруты.

Потенциальные решения

  1. Проверка правил IPTables/NFTables: Помимо конфигурации Firewalld, необходимо убедиться, что в IPTables или NFTables отсутствуют правила, блокирующие трафик между wg0 и virbr0. Особенно важно настроить masquerading и NAT на virbr0.

    sudo iptables -t nat -A POSTROUTING -o virbr0 -j MASQUERADE
  2. Проверка правил маршрутизации: Убедитесь, что маршрутизация настроена правильно. Необходимо, чтобы сервер знал, как передавать трафик с интерфейса wg0 на virbr0. При этом может потребоваться явное добавление маршрута:

    sudo ip route add 192.168.122.0/24 dev virbr0 via 172.16.1.0
  3. Проверка политики безопасности SELinux/AppArmor: Если используется SELinux или AppArmor, они могут ограничивать перенаправление трафика. Временно отключите их, чтобы проверить влияние:

    sudo setenforce 0 # для SELinux
  4. Диагностика и логирование: Использование утилит tcpdump на интерфейсах может помочь увидеть, где теряется трафик. Запустите tcpdump на virbr0, чтобы идентифицировать приходящий трафик.

    sudo tcpdump -i virbr0 -n
  5. Утилита virt-manager настройки сети: Проверьте настройки virt-manager. Возможно, неправильно настроен интерфейс сети виртуальной машины, что препятствует правильной маршрутизации.

Вывод

Успешное решение задачи с перенаправлением зависит от последовательного устранения всех потенциальных ошибок в настройках сетевых правил и маршрутизации. Постарайтесь следовать шагам, описанным выше, и внимательно анализировать логи. Если проблема остаётся, подумайте о привлечении профессиональной технической поддержки для детального анализа.

Оцените материал
Добавить комментарий

Капча загружается...