Назад | Перейти на главную страницу

Как включить правильную маршрутизацию с помощью интерфейса VPN?

Я установил wireguard на сервере в локальной сети и проблема с одним ping между двумя компонентами. топология следующая:

srv это машина Linux (Ubuntu 18.04), которая имеет один физический интерфейс с IP 192.168.10.2 и виртуальный интерфейс с IP 192.168.20.1
remote это машина, которая подключается к локальной сети через wireguard и имеет IP 192.168.20.2
internal это машина в локальной сети с IP 192.168.10.5

Вообще говоря, машины в реальной локальной сети находятся в 192.168.10.0/24 и на VPN в 192.168.20.0/24.
Нет iptables ограничения где угодно.
Переадресация IP включена srv.

Эта проблема: Я могу пинговать все отовсюду, Кроме 192.168.10.2 из 192.168.20.2 (физический IP-адрес сетевой карты на сервере с удаленного компьютера, подключенного к VPN).

В частности

Я могу связаться с remote как srv сторона wireguard (192.168.20.1) и все остальное в локальной сети (192.156.10.5 в списке выше).
- Я могу дотянуться remote из srv (через VPN)

Таблица маршрутизации на srv (br0 это "физический" интерфейс, на самом деле это мост, но здесь это не имеет значения)

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

Таблица маршрутизации на remote

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.237.76.1      10.237.78.2     25
      10.237.76.0    255.255.252.0         On-link       10.237.78.2    281
      10.237.78.2  255.255.255.255         On-link       10.237.78.2    281
    10.237.79.255  255.255.255.255         On-link       10.237.78.2    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.10.0    255.255.255.0     192.168.20.1     192.168.20.2    135
     192.168.20.0    255.255.255.0         On-link      192.168.20.2    291
     192.168.20.2  255.255.255.255         On-link      192.168.20.2    291
   192.168.20.255  255.255.255.255         On-link      192.168.20.2    291
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    281
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    281
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link       10.237.78.2    281
        224.0.0.0        240.0.0.0         On-link      192.168.20.2    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    281
  255.255.255.255  255.255.255.255         On-link       10.237.78.2    281
  255.255.255.255  255.255.255.255         On-link      192.168.20.2    291

В чем может быть причина отправки пакета из 192.168.20.2, хотя 192.168.20.1 не дотянуться 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

Первый добавляется как часть настройки wg0. Это правильно.

Второй получен от DHCP, который отправляет этот маршрут клиентам, чтобы они знали, как достичь 192.168.20.0/24, то есть сеть VPN.

Эта информация не только бесполезна для хоста, на котором находится VPN, но и вредна, поскольку [происходят ужасные вещи, я не уверен что], когда пакет из сети VPN направляется на сервер VPN (тот же хост)

Удаление второго маршрута решило проблему, но поднял еще один (не относится).