Проблемы с tinc vpn - Self DDos

Question

Обзор:

У нас есть настройка VPN, основанная на tinc-vpn, в нашей инфраструктуре, содержащей ~70 пиров / узлов / хост-машин (или как вы хотите их вызывать). Подготовка каждого из узлов в нашей инфраструктуре была выполнена с использованием Ansible playbooks и с использованием этого playbook в качестве справочного материала. Установка прошла успешно и полностью работает уже более года. Узлы соединяются блестяще, и нет проблем, связанных с недоступными узлами.

Проблема:

Время от времени мы сталкивались с некоторыми странными утверждениями в наших системных журналах, которые регистрировались демоном tinc, который работает на каждом хосте, и выглядит так:

Apr 10 13:01:31 <our-host-name> tinc.<our-vpn-name>[862]: Metadata socket read error for <our-target-host-name-to-which-connection-was-attempted> (<target-host-ip> port <target-host-port>): Connection reset by peer
Apr 10 13:16:31 <our-host-name> tinc.<our-vpn-name>[862]: Metadata socket read error for <our-target-host-name-to-which-connection-was-attempted> (<target-host-ip> port <target-host-port>): Connection reset by peer
Apr 10 13:46:31 <our-host-name> tinc.<our-vpn-name>[862]: Metadata socket read error for <our-target-host-name-to-which-connection-was-attempted> (<target-host-ip> port <target-host-port>): Connection reset by peer

Эти журналы принадлежат хосту, который пытается прочитать метаданные с целевого хоста, но не может этого сделать, поскольку соединение было разорвано. Мы попытались найти журналы на целевом хосте, надеясь получить больше информации о том, почему целевой хост разорвал соединение, но журналы на целевом хосте были такими же, разорвало соединение. И никакой другой информации.

Эти журналы согласованы на каждом узле в нашей настройке vpn.

Катастрофа:

В одну прекрасную пятницу наша инфраструктура вышла из строя. На всех 69 узлах загрузка ЦП составляла 90+, и демон tinc потреблял большую часть ЦП. Мы смотрели на /var/log/syslog на каждом узле и в строках журнала, указанных выше, было просто затопление. Мы ничего не могли понять из этих строк журнала, и в конечном итоге нам пришлось отключить всю инфраструктуру и загрузить ее обратно, что сработало для нас. Но это был очень наивный подход, и мы не хотели бы делать это снова. То же самое случалось и раньше, но обсуждение по ссылке не привело ни к какому выводу.

Текущая ситуация

Даже сейчас мы видим строки журнала, похожие на приведенные выше, которые часто появляются в системном журнале.

Конфигурация Tinc

На каждом узле tinc.conf имеет номер ConnectTo = <host-name> равно количеству узлов в VPN - 1 (самостоятельно). Так что, в основном, ячеистый VPN.

Мои вопросы

1. Мой первый подход состоял в том, чтобы увеличить уровень журнала демона tinc, чтобы я мог получить больше информации о проблемах, которые у нас есть, но в документации нет никаких упоминаний о запуске tinc с определенным уровнем журнала с использованием конфигурации. Мы запускаем tinc, используя systemd и включенный сервис. Так как же мне дать команду systemd запустить tinc с определенным уровнем журнала? (Я знаю, что могу сделать tincd -n <netname> -d5 но нельзя ли это сделать с помощью системного конфига? Я просто хочу избежать достижения всех узлов и запуска tinc таким образом.)

2. Как я уже говорил, у нас есть полная сетка vpn, которая хороша для надежности, но в этом случае tinc генерирует много метаданных. Может ли это быть связано с проблемой разрыва соединения, которая у нас есть?