ip route show и traceroute показывают противоречивую информацию.

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

# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
default via 10.1.0.20 dev virbr0 metric 128
default via 10.0.0.1 dev enp1s0 proto dhcp src 10.0.0.100 metric 1024
10.0.0.0/24 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
10.0.0.1 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
<local, broadcast, multicast, ipv6 omitted>

# ip rule
0:      from all lookup local
32764:  from 10.1.0.0/24 lookup lan
32766:  from all lookup main
32767:  from all lookup default

# ip route get 1.1.1.1
1.1.1.1 via 10.1.0.20 dev virbr0 src 10.1.0.1 uid 0
    cache

# traceroute 1.1.1.1
1 _gateway (10.0.0.1) ...
...

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

Конфликт между выводами команд ip route get и traceroute может возникать по нескольким причинам, связанным с конфигурацией маршрутизации и правилами выбора маршрутов. Давайте разберемся по порядку.

1. Понимание вывода команд

• ip route show table all: Эта команда показывает все маршруты, которые известны системе, включая маршруты в разных таблицах маршрутизации. В вашем выводе видно, что существует несколько маршрутов по умолчанию, и для virbr0 указан маршрут с меньшим метриком, что может влиять на выбор маршрута.

• ip rule: Правила маршрутизации определяют, какие таблицы маршрутизации будут использованы на основе источника трафика. В вашем случае правило 32764 указывает на использование таблицы lan для трафика из сети 10.1.0.0/24. Однако правила по умолчанию могут изменять поведение маршрутизации в зависимости от источника.

• ip route get 1.1.1.1: Эта команда показывает, какой маршрут будет использоваться для доступа к IP-адресу 1.1.1.1, и в вашем случае выбран маршрут через интерфейс virbr0. Однако это не всегда означает, что этот маршрут будет использован в реальности.

• traceroute 1.1.1.1: Эта команда фиксирует фактический путь, по которому пакеты проходят через сеть. Если traceroute показывает, что пакеты идут через 10.0.0.1 (шлюз на enp1s0), это может говорить о том, что система использует другой маршрут, нежели тот, который предполагался.

2. Возможные причины конфликта

1. Конфликт маршрутизации: Из-за существования различных маршрутов по умолчанию (virbr0 и enp1s0) система может предпочесть маршрут через enp1s0, поскольку он имеет меньшую метрику (если интерфейс находится в состоянии "up"). Это может произойти, если в определенный момент времени маршрут через virbr0 недоступен.

2. Кеширование маршрутов: Иногда система может кешировать информацию о маршрутах или правилах, что приводит к использованию устаревших данных.

3. Проблемы с настройкой VPN: Если WireGuard настроен неправильно на виртуальной машине, он может не обрабатывать трафик, как ожидалось, тем самым направляя трафик обратно на шлюз 10.0.0.1.

3. Рекомендации по устранению конфликта

1. Проверьте состояние интерфейсов: Убедитесь, что интерфейс virbr0 поднят (up) и настроен на передачу трафика.

2. Убедитесь, что VPN работает корректно: Проверьте конфигурацию WireGuard на предмет ошибок и убедитесь, что он настроен для правильной маршрутизации трафика.

3. Меняйте метрики: Попробуйте изменить метрики маршрутов так, чтобы предпочтение отдавало вашему VPN, или убедитесь, что правила маршрутизации корректно настроены для использования нужной таблицы.

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

5. Используйте более сложные команды отладки: Чтобы лучше понять, как работает маршрутизация, полезно использовать команды для мониторинга трафика, такие как tcpdump, чтобы увидеть, куда фактически отправляются пакеты.

Ваша цель – убедиться, что трафик действительно направляется через виртуальную машину и что VPN корректно обрабатывает его. Таким образом, вам нужно будет синхронизировать таблицы маршрутизации и проверить работоспособность всех компонентов системы.