Инвалидация адресов в ipset

[Danstiv]

Приветствую! Настраивал по этой статье. Всё вроде работало, но вчера случайно заметил, что google.com маршрутизируется через туннель. После service firewall restart маршрутизация пошла через isp, в моём понимании произошло следующее.

1. Кто-то в локалке зарезолвил что-то гугловое, youtube.com например.
2. ip попал в ipset.
3. Через какое-то время случилась некая ротация, и google.com стал ссылаться на ip, который ранее был зарезолвлен, из-за чего он стал маршрутизировать его через туннель.

И если моя теория верна, то возникает вопрос, какая оптимальная стратегия инвалидации ip-шников в ipset?

[Danstiv]

Снова google пошёл через туннель. Добавил в скрипт такую строчку. nft flush set inet fw4 vpn_domains Вот только есть одно но. Я добавил в скрипт эту строчку, оно неделю крутилось, и где-то через 4 часа после последнего срабатывания скрипта я обнаружил, что google.com маршрутизируется через туннель. Т.е. очистка ipset-а - не 100% решение. Теоретически можно делать следующее:

1. При запросе сервера у dns запоминаем ip, домен и время добавления записи.
2. При отправке пакета на ip проверяем время добавления записи, если оно произошло более 10 минут назад, идём к dns, и ещё раз спрашиваем ip.
3. Если ip не изменился, обновляем время.
4. Если изменился, выбрасываем запись, а пакет отправляем через isp.

Но это лишь теория...

[Danstiv]

А ещё, в теории, google.com и youtube.com в один момент времени могут ссылаться на один и тот же ip, вот просто потому, что почему бы и нет?.. Им то пофиг, они по заголовку Host раскидают куда надо, а вот с роутера подлезть в туннель не так и просто. Но тут уже совсем сложная схема должна быть, которая будет всё это учитывать. Нужно либо эвристически угадывать, куда хочет сходить конкретный клиент, т.е. сопоставлять dns query и последующее открытие соединения на ip. Либо залезать в туннель, как, например, adguard. Вот только Adguard делает это на клиентском устройстве, а на роутере такое завести будет сложнее.