Вопрос или проблема
У меня есть хост-машина и гость-Virtual Machine (VM). Я запускаю туннель VPN WireGuard на VM и хотел бы перенаправить весь трафик с хоста на VM, и в конечном итоге в туннель VPN. Производственная установка будет более сложной, но сейчас я просто хочу убедиться, что я правильно настраиваю маршруты на хосте.
На хосте:
# 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
<локальные, широковещательные, многоадресные, ipv6 опущены>
# 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
кеш
# traceroute 1.1.1.1
1 _gateway (10.0.0.1) ...
...
Таким образом, похоже, что результат ip route get 1.1.1.1 не соответствует фактическому маршруту, выбранному, когда я использую traceroute 1.1.1.1.
Какова может быть причина этого?
ПРАВКИ
Оказалось, что ping 1.1.1.1 был довольно полезен, потому что я заметил сообщение “Redirect Host(New nexthop: 10.1.0.1)”. Это часть IP, с которой я не был знаком, но, очевидно, шлюзы хотят быть эффективными и отправлять ICMP-сообщения, если есть более прямой маршрут.
Работающая конфигурация:
# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
10.0.0.1 dev enp1s0 table lan scope link
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 dhcp scope link src 10.0.0.100 metric 1024
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1
Таким образом, похоже, что отсутствующие компоненты были:
10.0.0.1 dev enp1s0 table lan scope link
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1
Хотя я все еще не уверен, почему пакеты направлялись к неправильному шлюзу, вместо того чтобы возвращаться как непроходимые.
ПРАВКА 2
Ошибка конфигурации заключалась в том, что была команда ip rule add from 10.1.0.0/24 table lan вместо ip rule from 10.1.0.20 table lan. Поскольку у хоста есть IP-адрес 10.1.0.1, который находится в 10.1.0.0/24, пакеты, отправленные с хоста, попали в эту таблицу.
Все еще не уверен, почему 10.0.0.1 не был обнаружен командой ip route get. Возможно, мне нужно было использовать ip route get from 10.0.0.100 to 1.1.1.1?
Ответ или решение
Ваш вопрос о конфликтующих результатах команд ip route get и traceroute является интересным и требует внимательного анализа маршрутизации вашей сети. Исходя из предоставленных вами данных, давайте разберем детали, которые могут быть причиной наблюдаемой проблемы и как их можно исправить.
1. Объяснение команд и выводов
-
ip route get 1.1.1.1: Эта команда показывает, какой маршрут будет использован для передачи пакета к адресу1.1.1.1. В вашем случае вывод говорит, что пакет будет направлен через шлюз10.1.0.20, что соответствует интерфейсуvirbr0. -
traceroute 1.1.1.1: Эта команда отображает фактический путь, по которому пакеты проходят к адресу1.1.1.1. Результаты показывают, что первый хоп — это10.0.0.1, что указывает на то, что связь осуществляется через интерфейсenp1s0.
2. Причины несоответствий
Несоответствие между выводами этих команд может быть вызвано несколькими факторами:
-
Изменение маршрута на основе ICMP сообщений: Как вы заметили, ICMP сообщения могут влиять на маршрутизацию. Например, если шлюз
10.0.0.1знает более оптимальный маршрут к адресу1.1.1.1, он может отправить ICMP редирект, что может привести к изменению маршрута. -
Правила маршрутизации: Ваша конфигурация правил маршрутизации может также играть ключевую роль. Убедитесь, что маршруты настроены правильно для всех входящих и исходящих IP-адресов.
3. Исправление конфигурации
Вы упомянули о том, что ваша настройка имела ошибку в правиле маршрутизации. Правильная команда должна быть:
ip rule add from 10.1.0.20 table lanЭто нужно для того, чтобы указать, что пакеты, отправляющиеся с IP 10.1.0.20, будут использовать таблицу маршрутизации lan. Также, если у вас есть другой интерфейс с IP-адресом 10.1.0.1, не забудьте провести настройку его маршрутов.
4. Проверка конфигурации
После изменений рекомендуется выполнить следующие команды, чтобы убедиться, что маршруты настроены правильно:
ip route show table all
ip rule showДля диагностики работы маршрутизации можно также использовать:
ip route get from 10.0.0.100 to 1.1.1.1Эта команда поможет вам понять, как именно пакеты из вашей сети будут маршрутизироваться.
5. Заключение
Проблемы с маршрутизацией могут быть сложными и зачастую требуют детального анализа всех параметров настройки сети. Если вы продолжаете сталкиваться с проблемами, рассмотрите возможность использования трассировки пакетов с помощью tcpdump или аналогичных инструментов для более глубокого анализа.
Не забывайте, что в сложных сетях важно поддерживать документацию всех изменений, чтобы упростить диагностику и устранение проблем в будущем.