Question

概述：

我们在基础架构上基于tinc-vpn的VPN设置包含约70个对等/节点/主机（或者您想调用它们）。我们使用Ansible剧本并以this 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个节点上，CPU利用率为90+，而tinc守护程序正在消耗大部分CPU。我们在每个节点上查看了/var/log/syslog，上面提到的日志行只是泛滥。我们不能从这些日志行中暗示任何内容，最终我们不得不将整个基础架构关闭并重新启动，这对我们来说是有用的。但这是一种非常幼稚的方法，我们不想再做一次。 The same case发生在之前，但链接中的讨论并未得出任何结论。

当前情况

即使现在我们也可以看到类似于上面的日志行经常出现在syslog中。

Tinc配置

在每个节点上，tinc.conf的数量ConnectTo = <host-name>等于VPN-1（自身）中的节点数量。所以基本上是全网状VPN。

我的问题

我的第一种方法是增加tinc守护程序的日志级别，以便我可以记录有关我们遇到的问题的更多信息，但是在文档中没有提及以某个日志级别启动tinc使用配置。我们使用systemd及其启用的服务运行tinc。 那我该如何指示systemd以某个日志级别启动tinc？（我知道我可以做tincd -n <netname> -d5，但是使用system config不能完成吗？我只是想避免接触所有节点并以这种方式启动tinc。）
正如我提到的那样，我们有一个全网状的VPN，这对可靠性很有帮助，但是tinc会生成大量的元数据。无论如何，这可能与我们断开连接的问题有关吗？

tinc vpn的问题-自我DDos

0 个答案: