Я использую wireguard
(VPN) для подключения к серверу. Этот сервер имеет два интерфейса (представляющих интерес для моей проблемы - все остальные - это ссылки виртуального Ethernet для подключения к контейнерам, с ними проблем нет):
root@srv ~# ip a
(...)
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 12:5b:d3:1d:51:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global dynamic br0
valid_lft 60366sec preferred_lft 60366sec
(...)
25: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 192.168.20.1/32 scope global wg0
valid_lft forever preferred_lft forever
Маршрутизация
root@srv ~# ip r
default via 192.168.10.1 dev br0 proto dhcp metric 1024
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.2
192.168.20.0/24 via 192.168.20.1 dev wg0 proto static
192.168.20.0/24 via 192.168.10.2 dev br0 proto dhcp metric 1024
При подключении через VPN возможны следующие сценарии хорошо:
ssh
к IP Wireguard 192.168.20.1
ssh
к любым другим устройствам с защитой от проводов на 192.168.20.0/24
ssh
на любое другое устройство на 192.168.10.0/24
(кроме самого сервера, см. ниже)Тот, который KO является
ssh
к 192.168.10.2
- в br0
интерфейс на сервере, на котором установлена защита от проводовsshd
слушает *.22
и я могу ssh 192.168.10.2
(на IP-адрес моста) из другого места (так sshd
функционально).
Полагаю, это оставляет меня с маршрутизацией между интерфейсами. Когда пакеты отправлены 192.168.10.2
(интерфейс моста) проходит через Wireguard, его следующий переход ищется в таблице маршрутизации, и он соответствует строке
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.2
Это, наверное, нехорошо.
С другой стороны, я ожидал, что ядро будет иметь дело с этим пакетом, понимая, что он предназначен для локального интерфейса. А может я здесь ошибаюсь.
Мой вопрос: какова должна быть настройка сети, чтобы пакеты, проходящие через интерфейс Wireguard, могли достичь локального моста?