Проблемы с tinc vpn - Self DDos - PullRequest
0 голосов
/ 10 апреля 2019

Обзор:

У нас есть настройка 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, но нельзя ли это сделать с помощью конфигурации системы? Я просто хочу избежать доступа ко всем узлам и запускатинк таким образом.)

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

...