Вопрос или проблема
Я использую Mullvad VPN на моем хосте (Fedora 41), который настраивает интерфейс WireGuard, wg0-mullvad, и хочу, чтобы трафик в и из пространства имен bl обходил его, с конечной целью подключения к AnyConnect VPN моей компании изнутри bl и, после этого, RDP-подключения к моему офисному компьютеру, весь остальной интернет-трафик будет проходить через Mullvad.
$ 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: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:11:c0:d6 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp1s0
valid_lft 81301sec preferred_lft 81301sec
inet6 fec0::e777:52d6:5436:4997/64 scope site dynamic noprefixroute
valid_lft 86366sec preferred_lft 14366sec
inet6 fe80::bc4e:6885:3d23:b51b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: veth-bl-root@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 62:fb:a5:45:d4:e3 brd ff:ff:ff:ff:ff:ff link-netns bl
inet 192.168.11.2/24 scope global veth-bl-root
valid_lft forever preferred_lft forever
inet6 fe80::60fb:a5ff:fe45:d4e3/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
4: vpn0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1207 qdisc fq_codel state DOWN group default qlen 500
link/none
10: wg0-mullvad: <POINTOPOINT,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.136.199.175/32 scope global wg0-mullvad
valid_lft forever preferred_lft forever
veth-bl-root это виртуальный ethernet интерфейс, соединяющий корневое пространство имен с моим пространством имен bl. Вы можете игнорировать vpn0. Это упомянутый мной VPN компании, и пока что я могу использовать его только когда Mullvad отключен.
Я следовал этому руководству для настройки пространства имен и подключения его к Интернету, что означает, что я включил пересылку IP, пересылку пакетов и IP-маcкeрaдирование. Когда Mullvad VPN отключен, это работает, но когда я включаю VPN, запросы истекают по времени. Я предполагаю, что это из-за того, что IP-маcкeрaдирование не выполняется до тех пор, пока пакеты не будут маршрутизированы через enp1s0, и VPN Mullvad препятствует этому:
$ ip route get 8.8.8.8 from 192.168.11.2
8.8.8.8 from 192.168.11.2 dev wg0-mullvad table 1836018789 uid 1000
cache
Хотя на практике wg0-mullvad является маршрутом по умолчанию, он не кажется установленным таким образом.
$ ip route
default via 10.0.2.2 dev enp1s0 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp1s0 proto kernel scope link src 10.0.2.15 metric 100
10.64.0.1 dev wg0-mullvad proto static
192.168.11.0/24 dev veth-bl-root proto kernel scope link src 192.168.11.2
$ ip rule list
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0x6d6f6c65 lookup 1836018789
32766: from all lookup main
32767: from all lookup default
$ ip route show table 1836018789
default dev wg0-mullvad proto static
Поскольку он использует как маркировку пакетов, так и собственную таблицу маршрутизации, я попробовал два подхода, использующих каждый из этих элементов.
Попытки Исправления
Отдельная Таблица Маршрутизации
Сначала я попробовал создать новую таблицу маршрутизации, где единственным маршрутом было enp1s0, и добавил правило, уточняющее, что весь трафик, поступающий с IP-адреса пространства имен, должен использовать эту таблицу.
$ ip route show table bl
default via 10.0.2.15 dev enp1s0
$ ip rule
0: from all lookup local
32763: from 192.168.11.2/24 lookup bl
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0x6d6f6c65 lookup 1836018789
32766: from all lookup main
32767: from all lookup default
Поскольку это имело приоритет над правилами Mullvad, я надеялся, что это сработает. Действительно, ip route get выглядел обнадеживающе:
$ ip route get 8.8.8.8 from 192.168.11.2
8.8.8.8 from 192.168.11.2 dev enp1s0 table bl uid 1000
cache
К сожалению, запросы истекали по времени.
$ sudo ip netns exec bl traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C
$ sudo ip netns exec bl ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2076ms
tcpdump -n -i veth-bl-root icmp поймал пакеты, но tcpdump -n -i enp1s0 icmp ничего не показал. Пакеты всё ещё проходили через wg0-mullvad:
# Это то, что произошло при запуске `ping -c 3 8.8.8.8`.
$ sudo tcpdump -n -i wg0-mullvad icmp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0-mullvad, link-type RAW (Raw IP), snapshot length 262144 bytes
08:55:53.448220 IP 10.136.199.175 > 10.64.0.1: ICMP echo request, id 13627, seq 601, length 50
08:55:53.532425 IP 10.64.0.1 > 10.136.199.175: ICMP echo reply, id 13627, seq 601, length 50
08:55:59.449654 IP 10.136.199.175 > 10.64.0.1: ICMP echo request, id 13627, seq 602, length 50
08:55:59.534057 IP 10.64.0.1 > 10.136.199.175: ICMP echo reply, id 13627, seq 602, length 50
08:56:05.451552 IP 10.136.199.175 > 10.64.0.1: ICMP echo request, id 13627, seq 603, length 50
08:56:05.535728 IP 10.64.0.1 > 10.136.199.175: ICMP echo reply, id 13627, seq 603, length 50
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Маркировка Пакетов Из bl
Поскольку Mullvad, кажется, игнорирует пакеты, маркированные 0x6d6f6c65, я попробовал добавить правило, которое проставляло бы эту метку на пакеты из bl.
$ sudo nft add rule inet mullvad prerouting ip saddr 192.168.11.2 meta mark set 0x6d6f6c65
$ sudo nft list ruleset | grep mullvad
table inet mullvad {
chain prerouting {
type filter hook prerouting priority -199; policy accept;
iif != "wg0-mullvad" ct mark 0x00000f41 meta mark set 0x6d6f6c65
ip saddr 170.62.100.66 udp sport 10501 meta mark set 0x6d6f6c65
ip saddr 192.168.11.2 meta mark set 0x6d6f6c65
}
...
}
Это ничего не изменило, однако.
$ ip route get 8.8.8.8 from 192.168.11.2
8.8.8.8 from 192.168.11.2 dev wg0-mullvad table 1836018789 uid 1000
cache
$ sudo ip netns exec bl traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C
Сделал ли я какие-то ошибки или мой подход в корне ошибочен?
Ответ или решение
Для решения вашей задачи, связанной с маршрутизацией трафика из сетевого пространства имен (namespace) так, чтобы он обходил интерфейс WireGuard wg0-mullvad на вашей машине с Fedora 41, необходимо более внимательно рассмотреть конфигурацию сетевых маршрутов и правил. Давайте разберем эту проблему детально.
Теоретическая часть
Когда вы используете VPN, такое как Mullvad, он обычно перенастраивает маршруты на вашем хосте таким образом, чтобы всё исходящее интернет-соединение направлялось через туннель. Это может вызывать конфликты, если вы хотите, чтобы часть трафика обошла этот туннель, как это происходит в вашем случае с маршрутизацией пакетов в сетевом пространстве bl.
WireGuard использует собственную таблицу маршрутизации, которая имеет приоритет над основными системными правилами маршрутизации. Это достигается через натсройки iproute2, при которых пакеты помечаются и перенаправляются в WireGuard. Проблема возникает тогда, когда трафик из сетевого пространства bl проходит через интерфейс wg0-mullvad, даже если вы настроили отдельные правила маршрутизации.
Пример
В вашем случае, вы уже пытались создать отдельную таблицу маршрутизации bl, которая бы направляла трафик через enp1s0. Это – правильное направление, однако необходимо убедиться, что все пакеты из пространства bl действительно помечаются таким образом, чтобы обходить таблицу, используемую WireGuard.
Также, вы упомянули попытку пометить пакеты с помощью nftables с целью заставить их обходить Mullvad. Но эта попытка не принесла успеха, так как правила пометок не влияют на конечное направление пакетов, если таблица маршрутизации WireGuard перехватывает управление.
Применение
-
Перенастройка маркировки и правил маршрутизации:
Проверьте порядок применения ваших правил маршрутизации. Вы должны убедиться, что правила, которые перенаправляют пакеты из сети
192.168.11.2(ваше пространствоbl), имеют приоритет выше, чем правила Mullvad. Это может быть достигнуто использованием корректных приоритетов и правильной структуры правилiprule.ip rule add from 192.168.11.0/24 table bl pref 100 ip route add default via 10.0.2.2 dev enp1s0 table blВ этом примере
pref 100делает правило более высоким приоритетом, чем большинство других правил. -
Альтернативный подход с использованием
nftables:Вместо того, чтобы пытаться напрямую манипулировать маркировкой в
nftables, можно заставить маршрутизатор либо игнорировать маркер (если его установка обязана для работы других приложений), либо использоватьnftablesдля создания источника политики маршрутизации. -
Проверка правил:
Убедитесь в том, что при выводе таблиц маршрутизации, ваши изменения действительно применяются. Вывод
ip route getдолжен показывать, что конкретный маршрут выбирается из вашей таблицы:ip route get 8.8.8.8 from 192.168.11.2Этот запрос должен возвращать маршрут с использованием интерфейса
enp1s0, если правила настроены корректно. -
Диагностика с помощью трассировки и
tcpdump:Используйте инструменты для диагностики сетевых проблем, такие как
tcpdump, чтобы убедиться, что правильные пакеты уходят изenp1s0. Например:tcpdump -i enp1s0 net 192.168.11.0/24Это может помочь определить, где трафик теряется или почему не проходит через
enp1s0.
В итоге вы должны получить систему, где трафик из bl действительно идет в обход VPN Mullvad, позволяя подключаться к AnyConnect из вашего собственного пространства имен. Этот подход гарантирует, что вся ваша другая активность идет через WireGuard, сохраняя общую защищенность и приватность, обеспечиваемую VPN, для остального трафика.
Такой уровень настройки потребует точного подхода и знания вашего сетевого окружения, поэтому может потребовать некоторых попыток и тестирования, чтобы достичь желаемого результата.