Отдельный шлюз для виртуальных машин

Основное направление поиска это «policy based routing» aka PBR.

А при чем тут pbr, если у человека 2 дефолта? Он даже и не сработает, т.к это взаимоисключающие методы маршрутизации. Тут либо 1 дефолт правильно сделать, либо убрать оба и таки вешать костыль

Настроить DHCP клиент так, чтобы он игнорировал шлюз по умолчанию из Lan. Остальное вроде и так ничего.

Это ящик с виртуалками, т.е. читаем - «сервер». Я бы вообще статикой прибил адресацию, ну и вопрос с GW почти сам собой при этом отпал бы.

А при чем тут pbr, если у человека 2 дефолта?

Именно при том, что «у человека 2 дефолта». Т.е. он о pbr даже не задумывался.

Но если там wifi, и управление роутером недоступно, какая статика? Как минимум на WiFi будет dhcp по-любому. А так - да.

Он и про DHCP не задумывался, перестань :)

и управление роутером недоступно

А, верно. Но тут от уровня смелости (наглости) зависит. Прибить гвоздями последний выданный адрес и надеяться что wifi-роутер его не отдаст в ту минуту, когда хост в ребуте. А когда хост в норме, то dhcp переживет это самоуправство.

И что DHCP ? От у меня тоже DHCP от двух провов, но это мне не мешает использовать PBR.

А зачем здесь PBR, если достаточно просто игнорировать прилетевший по DHCP шлюз?

Ну проигнорировали, а дальше что делать?

Так а всё. NAT у него уже есть, маршрут будет в сеть через роутер через WiFi. Я так понял, что это ему и нужно.

Если хочется совсем без PBR - нужно сделать bridge с внешней wifi картой в одной из виртуалок и запускать dhcp клиент на виртуалке в ВМ, а на самом wifi адаптере только поднимать шифрование канала, т.е. wpa_supplicant, можно ещё маки назначить, но думаю тут не нужно.

И уже внутри сети виртуалок маршрутизировать трафик через ту отдельную виртуалку, интерфейс которой в бридже с физическим wifi адаптером. На виртуалке, конечно нужны две сетевые карту.

Остальное - хоть squid поднимать в той ВМ, либо PBR, но в этом случае не нужно отказываться от DHCP шлюза и надеяться, что адресация в wifi сети не поменяется, если с хоста нужно выходить в нет.

Но это всё как-то костыльно, но возможно.

Так а всё. NAT у него уже есть, маршрут будет в сеть через роутер через WiFi.

Простите но вы предлагаете «просто игнорировать прилетевший по DHCP шлюз» куда по вашему мнению должны полететь пакеты при отсутствии defgw ?

Если трафик от ВМ будет маршрутизировать хост - так не сработает, разве что прописать маршруты до конкретных IP / сетей.

А, ну да. Я имел в виду игнорировать шлюз, прилетевший от локальной сети. Прилетевший от WiFi не игнорировать. Мне как-то показалось это очевидным.

Почему не сработает?

ТС Нужен «Отдельный шлюз для виртуальных машин», а не все строем одним маршрутом.

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

Тебе нужна будет отдельная таблица маршрутизации и пбр через нее. Без этого не заработает.

Спасибо всем за участие в обсуждении! Посмотрю, что получиться сделать воспользовавшись вашими подсказками.

Если wifi-адаптер используется только для виртуальных машин, то можно сделать wifi-маршрутизатор в отдельном сетевом пространстве имен:

# включаем передачу пакетов между сетевыми интерфейсами
sysctl -w net.ipv4.ip_forward=1

# смотрим имена беспроводного адаптера и сетевого интерфейса
iw dev

# в выводе будет что-то похожее на
phy#0
        Interface wlx112233445566
# имя адаптера - phy0, сетевого интерфейса - wlx112233445566

# создаем сетевое пространство имен vmwl0
ip netns add vmwl0

# переносим в него беспроводной адаптер
iw phy phy0 set netns name vmwl0

# создаем виртуальный сетевой интерфейс для доступа снаружи
ip link add veth-vmwl0 type veth peer name veth0

# один конец veth-vmwl0 остается снаружи, другой veth0 переносится в vmwl0
ip link set veth0 netns vmwl0

# создаем мост для виртуальных машин
ip link add br-vmwl0 type bridge
ip link set dev br-vmwl0 up

# подключаем виртуальный сетевой интерфейс к мосту
ip link set veth-vmwl0 master br-vmwl0
ip link set veth-vmwl0 up

# входим в сетевое пространство имен vmwl0
ip netns exec vmwl0 bash

# назначаем адрес для виртуального сетевого интерфейса
ip addr add 192.168.222.1/24 dev veth0
ip link set veth0 up

# подключаемся по wifi
wpa_supplicant -B -c/opt/my-wifi.conf -iwlx112233445566
dhclient wlx112233445566

# включаем NAT
nft -f /opt/vmwl0-nft.conf

# выходим из сетевого пространства имен vmwl0
exit

# запускаем vm
qemu-system-x86_64 -accel kvm -cpu host -m 1G -nic bridge,br=br-vmwl0,model=virtio-net-pci -cdrom alpine-standard-3.23.2-x86_64.iso

# т. к. dhcp-сервер не настроили, то внутри vm настраиваем сеть вручную
ip addr add 192.168.222.10/24 dev eth0
ip link set eth0 up
ip route add default via 192.168.222.1 dev eth0

# после этого должен работать доступ по ip-адресам
ping 8.8.8.8

Файл настроек /opt/my-wifi.conf для wpa_supplicant:

network={
    ssid="my-wifi-name"
    psk="my-password"
}

Файл настроек /opt/vmwl0-nft.conf для nft

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;
    }
    chain forward {
        type filter hook forward priority 0;
    }
    chain output {
        type filter hook output priority 0;
    }
}

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 192.168.222.0/24 ip daddr != 192.168.222.0/24 masquerade
    }
}

Для полноценной работы интернет в vm надо бы еще DNS настроить.

Вместо ручной настройки всего этого можно запустить OpenWRT в контейнере.

Если wifi-адаптер используется только для виртуальных машин, то можно сделать wifi-маршрутизатор в отдельном сетевом пространстве имен:

На br-vmwl0 назначить IP, и трафик можно роутить и с хоста.
Но wpa_supplicant, как я понял, из неймспейса vmwl0 запускается?

На br-vmwl0 назначить IP, и трафик можно роутить и с хоста.

Можно, но по условиям вопроса интернет есть по проводу.

Но wpa_supplicant, как я понял, из неймспейса vmwl0 запускается?

Да wpa_supplicant и dhcp-клиент запускаются в отдельном сетевом пространстве имен.

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

Отдельный шлюз для виртуальных машин можно настроить в самих виртуальных машинах.

Вы это как в задаче ТС видите?

Я видимо не очень понял задачу ТС. «Задача заставить виртуалки ходить в интернет через Wlan.». Для этого достаточно указать в виртуалках шлюзом 10.194.118.1 и маршрут до 10.194.118.1 напрямую через мост.

Для этого достаточно указать в виртуалках шлюзом 10.194.118.1

Вы перечитайте вводные указанные в теме, указать в виртуалках-то вам шлюзом хоть 8.8.8.8 никто не запрещает, но от этого оно робить не начнет.

Виртуалки в бридже с NAT-ом на Wlan.

Начнёт.

Нет.