Вопрос или проблема
Я пытаюсь изменить ответы ICMP time-exceeded (тип 11) для пакетов traceroute, но только если они являются ответами на проверки traceroute от конкретной виртуальной машины (VM). Моя настройка такова:
- Хост ОС под управлением Ubuntu с использованием nftables
- Гостевая VM под управлением Ubuntu, подключенная через интерфейс моста “spod”
- IP-адреса мостового интерфейса: Хост 137.205.192.1, VM 137.205.192.5
- Интернет-интерфейс хоста: wlo1 (192.168.110.187), шлюз 192.168.110.1
- Трафик VM подвергается маскарадингу через хост
Текущие рабочие правила (но они изменяют ВСЕ пакеты типа 11, а не только те, что для VM):
nft add table ip icmp_mod
nft add chain ip icmp_mod prerouting { type filter hook prerouting priority -300; }
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP1 counter snat ip to 146.97.180.159
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP2 counter snat ip to 146.97.35.246
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP3 counter snat ip to 146.97.35.18
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP4 counter snat ip to 146.97.35.197
При запуске traceroute как с хоста, так и с VM до 1.1.1.1 ответы ICMP типа 11 выглядят одинаково в цепочке prerouting.
Мне нужно изменить эти правила, чтобы они только соответствовали и изменяли пакеты ICMP типа 11, которые являются ответами на запросы traceroute от VM, а не от хоста. Каков правильный синтаксис nftables для проверки и сопоставления на основе конечного назначения пакетов?
Итак, решение этой задачи было на удивление простым. Просто переместите правила и цепочку nft в postrouting вместо prerouting. Пакеты, перенаправляемые на VM, проходят через postrouting только для VM, а не для ОС хоста.
Итак, итоговые команды nft такие:
nft add table ip icmp_pos
nft add chain ip icmp_pos postrouting { type filter hook postrouting priority -300 \; }
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP1 ip saddr set 146.97.180.159
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP2 ip saddr set 146.97.35.246
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP3 ip saddr set 146.97.35.18
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP4 ip saddr set 146.97.35.197
Ответ или решение
Теория
Манипулирование ICMP ответами по превышению времени (тип 11) для пакетной трассировки может быть важным инструментом для различных сценариев, включая тестирование сетевой безопасности или эмуляцию определённых сетевых сред. В описанной конфигурации задача заключается в изменении сети таким образом, чтобы только ответы на определённые ICMP-запросы от конкретной виртуальной машины (VM) изменялись, в то время как ответы, относящиеся к хосту, оставались неизменными.
Проблема, с которой сталкивается пользователь, заключается в том, что текущие правила в nftables изменяют все ICMP-пакеты типа 11, включая те, которые предназначены для хоста. Это приводит к тому, что невозможно отделить пакетные трассировки виртуальной машины от хоста, что может быть требованием для сохранения корректной работы или для специализированной конфигурации сети.
Пример
Ваше первоначальное решение состоит в использовании правил в цепи prerouting, так что все пакеты, пересекающие интерфейсы, попадают под их параметры. Первоначальные правила:
nft add table ip icmp_mod
nft add chain ip icmp_mod prerouting { type filter hook prerouting priority -300; }
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP1 counter snat ip to 146.97.180.159
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP2 counter snat ip to 146.97.35.246
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP3 counter snat ip to 146.97.35.18
nft add rule ip icmp_mod prerouting ip protocol icmp icmp type time-exceeded ip saddr $HOP4 counter snat ip to 146.97.35.197В таких правилах каждый ICMP-пакет будет изменён, если его адрес источника соответствует определённым хопам. Это не позволяет отделить трафик, исходящий от виртуальной машины, от трафика, предназначенного для хоста.
Применение
Решение заключается в том, чтобы переместить правила nftables в цепь postrouting. В цепи postrouting пакеты будут обрабатываться только после того, как они покинут виртуальную сеть, что позволяет обработать пакеты конкретной ВМ без влияния на пакеты хоста. Это позволяет различить маршруты вызова и обработки завершения для различных источников трафика.
Модифицированные правила будут следующими:
nft add table ip icmp_pos
nft add chain ip icmp_pos postrouting { type filter hook postrouting priority -300; }
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP1 ip saddr set 146.97.180.159
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP2 ip saddr set 146.97.35.246
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP3 ip saddr set 146.97.35.18
nft add rule ip icmp_pos postrouting ip protocol icmp icmp type time-exceeded ip saddr $HOP4 ip saddr set 146.97.35.197Перемещая правила в postrouting, вы добиваетесь того, что правила применяются только к ICMP-пакетам от ВМ после того, как они покинули сетевую виртуальную область. Это отличается от обработки в prerouting, где все приходящие пакеты, независимо от их отправителя, попадают под действие тех же самых трансформаций.
Используя nftables грамотно, вы можете улучшить сетевую архитектуру таким образом, чтобы обеспечить лучший контроль над маршрутизацией и фильтрацией пакетов, которые необходимо изменить только в определённых контекстах. Такого рода изменения обеспечивают гибкость и строгость адаптированной конфигурации, учитывая нужды виртуализированной среды и её элементов.