在出现经过认证的加密网关之前，网络工程师的生活是幸福而无忧无虑的。同意，处理旨在根据GOST加密数据传输通道的解决方案并非易事。如果这些是已知的并且可以理解的产品，则很好。让我们回想一下相同的“ S-Terra”（我们已经写过关于它们的“ S-Terra网关” ）。但是，如何使用基于其自己的加密协议的更特殊的解决方案，例如“ Continent”（来自“安全代码”）或ViPNet Coordinator HW（来自“ Infotex”），该怎么办？在本文中，我将尝试促进融入ViPNet的世界（有一天我们还将讨论大陆），并告诉您我面临的问题以及如何解决这些问题。
我将立即预约，我们将讨论今天经过FSB和FSTEC认证的4.2.1版本。在当前的版本4.3.x中，出现了许多有趣的事情，例如DGD（死网关检测）和改进的群集机制，该机制提供了几乎无缝的切换，但是现在这是未来。我将不深入介绍配置命令和文件，而是重点介绍关键命令和变量，并且可以在文档中找到这些“关键”的详细说明。
首先，让我们弄清楚它们是如何工作的。因此，ViPNet协调器执行多项功能。首先，它是一个加密网关（CG），可让您实现站点到站点和RA VPN。其次，它是信封的服务器路由器，其中包含加密的服务数据（目录和密钥）或客户端应用程序的数据（文件交换，商业邮件）。顺便说一句，是在目录中存储包含有关ViPNet网络对象信息的文件，包括其名称，标识符，地址，连接。协调员还是为其客户提供服务信息的来源。
此外，它还可以通过未安装ViPNet软件的网络计算机传送流量。顺便说一句，使用此解决方案的人们通常将打开的主机称为“隧道”，而不是“隧道节点”。对于习惯于其他VPN解决方案的工程师来说，这可能会造成混乱，因为隧道指的是网络之间的PtP连接。
IPlir也由Infotex开发，在ViPNet中用作加密协议。要封装流量，传输协议为IP / 241（如果流量没有离开广播域），UDP / 55777和TCP / 80（如果UDP不可用）。
建立安全连接的概念是基于两种类型的所谓“连接”。需要前者（在节点级别）来建立节点之间的安全连接，而后者（在用户级别）则需要客户端应用程序的操作。但是有一个例外：ViPNet管理员节点需要两种通信类型。
这个方案有什么问题？如实践所示，确实有很多工作特性，并且并非没有“听众的帮助”就无法直观地解决所有问题，但有些事情是理所当然的。
协调器不可用
“我们没有协调员/客户/隧道。该怎么办？” -设置ViPNet时，新手最常提出的问题。在这种情况下，唯一正确的措施是在协调器上打开所有流量的注册，并查看IP数据包日志，这是解决各种网络问题的最重要工具。此方法可节省80％的情况。使用IP数据包日志还有助于更好地了解ViPNet网络节点的运行机制。
信封未送达
但是，就信封而言，IP数据包日志毫无用处。它们使用传输模块（mftp）进行传输，该模块具有自己的日志和队列。默认情况下，信封被发送到客户端的“自己的”协调器（即在其上注册该节点的协调器），然后通过在协调器之间配置的服务器间通道（即，不直接通过安全通道）发送。这意味着，如果您想通过商务邮件发送信件，则客户会将其包装在信封中，然后首先发送给其协调员。再有可能会有更多的协调员，只有在此之后，信封才会到达收件人的节点。
由此得出两个结论。首先，不必检查客户端之间的通信（通过按F5和菜单中的相应图标）来发送信封。其次，如果仍然检查它们之间的连接，则不能保证传送，因为问题可能出在服务器间通道之一。
在不太明显的情况下，可以使用日志和信封队列以及协调器上的日志来诊断信封通过服务器间通道或在客户端与协调器之间的通过。此外，可以将ViPNet客户端传输模块配置为直接发送信封，通过共享文件夹或SMTP / POP3进行传递（但这是一个完全不同的选择）。我们不会深入探讨这些设置。
闪烁的后果
例如，升级到已经使用了很长时间的旧硬件的当前版本（例如，作为备件）可能会出现问题。在此过程中，可能会出现“不支持的硬件”错误，表明您确实拥有过时的G1线路（这些硬件是HW100 E1 / E2和HW1000 Q1）真正不支持的硬件平台，或者是有关BIOS设置问题或嵌入的错误信息。 DMI。每个人是否自己决定是否管理DMI，因为存在将设备变成无用的“砖”的风险。使用BIOS，它变得容易一些：在禁用的HT（超线程）功能或在HDD的禁用ACHI（高级主机控制器接口）模式下，系统设置不正确。为了不弄清楚到底是什么问题，可以参考从其生产固件的USB闪存驱动器。将在其上创建带有诊断信息的文件，特别是在verbose.txt文件中列出了所有受支持的平台，并与您进行了检查。例如，错误cpu ::供应商（＃3）=='GenuineIntel'24次=> [失败]最有可能表明HT被禁用。顺便说一句，刷新通常与更新混淆，但这是不同的过程。在更新期间，将保存所有设置，并且不检查上述参数。刷新后，您将返回到出厂设置。在更新期间，将保存所有设置，并且不检查上述参数。刷新后，您将返回到出厂设置。更新时，将保存所有设置，并且不检查上述参数。刷新后，您将返回到出厂设置。
非信息性配置
硬件的主要配置文件是“ iplir.conf”，但并不总是反映当前设置。事实是，在加载IPlir驱动程序时，此配置将根据设置的逻辑进行解释，并且并非所有信息都可以加载到驱动程序中（例如，如果存在IP地址冲突）。与Linux软件协调器合作的工程师可能知道“ iplirdiag”命令，该命令显示了加载到驱动程序中的当前节点设置。在硬件中，该命令也以“管理员转义”模式出现。
最受欢迎的结论是：
iplirdiag -s ipsettings --node-info <节点ID> ##显示有关节点的信息
iplirdiag -s ipsettings --v-tun-table ##显示加载到驱动程序中的所有隧道
让我们稍微介绍一下“管理员逃生”模式。实际上，这是从ViPNet Shell到bash的退出。在这里，我同意供应商的意见，供应商建议仅将此模式用于诊断，并且仅在供应商的技术支持的监督下进行任何修改。这不是您通常的Debian，在这里，任何不小心的动作都可能会禁用操作系统，其保护机制将把您的“主动性”视为潜在的威胁。结合默认情况下锁定的BIOS，这将使您无法维修（读为“昂贵”）。
（联合国）拆分隧道
并非所有人都知道的另一个事实：默认情况下，ViPNet客户端在拆分隧道模式下工作（当您可以指定要封装到隧道中的流量，而不能指定封装到隧道中的流量时）。 ViPNet具有“开放Internet”技术（后来更名为“受保护的Internet网关”）。许多人错误地将此功能归因于协调器而不是客户端。在使用此功能向协调器注册的客户端上，将创建两组预设过滤器。第一个只允许与协调器本身及其隧道进行交互，第二个与其他对象进行交互，但是拒绝访问OI协调器及其隧道。此外，根据供应商的概念，在第一种情况下，协调器必须通过隧道传输代理服务器，或者必须是代理服务器本身。服务流量，以及信封的接收和发送（两种服务，和应用程序）可以在任何配置下工作。
TCP-
一旦我遇到了一个不想通过协调器以任何方式工作的应用程序。这就是我了解到的协调器具有服务端口的功能，通过这些服务端口可以阻止未加密的流量，而无需进行任何配置。这些包括UDP / 2046、2048、2050（基本ViPNet服务），TCP / 2047、5100、10092（对于ViPNet Statewatcher）和TCP / 5000-5003（MFTP）。在这里，我总结了TCP隧道功能。 ISP喜欢过滤高UDP端口已经不是什么秘密了，因此，为了提高CN的可用性，管理员启用了TCP隧道功能。在这种情况下，DMZ中的资源（通过TCP隧道端口）将变得不可用。这是由于TCP隧道端口也成为服务端口，并且不再有防火墙规则和NAT（网络地址转换）规则。很难诊断出以下事实：该流量没有记录在IP数据包日志中，就好像根本不存在一样。
更换协调员
迟早会有一个问题，那就是用更有生产力或临时性的选择来代替协调员。例如，用HW2000替换HW1000或用PAK替换软件协调器，反之亦然。困难在于每个表演在NCC（网络控制中心）中都有其自己的“角色”。如何在不失去凝聚力的情况下正确地改变角色？首先，在NCC中，我们将角色更改为一个新角色，即目录，但不发送（！）它们。然后，我们在UCC中发布新的DST文件，并初始化新的协调器。之后，我们进行替换，并在确保所有交互功能均正常之后，发送参考书。
集群和节点崩溃
任何大型站点都必须具有热储备，因此，总是从它们中购买一堆较旧的型号（HW1000，HW2000，HW5000）。但是，由于供应商的许可政策，不可能从更紧凑的加密网关（HW50和HW100）创建集群。结果，小型站点的所有者不得不严重多付并购买HW1000（很好，或者没有容错能力）。今年，供应商终于为初级协调器模型获得了更多许可。因此，随着4.2.x版本的发布，可以将它们收集到群集中。
首次设置集群时，可以通过不以向导模式或使用CLI命令配置接口来节省大量时间。您可以立即在群集配置文件中输入必要的地址（故障转移配置编辑），只是不要忘记指定掩码。当故障转移守护程序以集群模式启动时，它将自己为相应的接口分配地址。同时，假设地址已更改为被动或单模式地址，许多人都害怕停止守护程序。不用担心：接口将保留守护程序停止时的地址。
在群集版本中，存在两个常见问题：被动节点的周期性重新引导以及其无法切换到主动模式。为了了解这些现象的本质，让我们了解集群操作的机制。因此，活动节点对接口上的数据包进行计数，如果在分配的时间内没有数据包，则将ping发送到testip。如果ping通过，则计数器重新启动；如果不通过，则注册接口故障，并且活动节点进入重新引导状态。同时，被动节点在failover.ini（群集配置文件，其中包含主动节点和被动节点接收的地址）中描述的所有接口上发送常规ARP请求。如果至少一个地址的ARP记录消失，则被动节点将切换到主动模式。
让我们回到集群问题。我将从一个简单的开始-不切换到活动模式。如果没有活动节点，但是其MAC地址仍然存在于ARP表的非活动节点中（inet show mac-address-table），则需要转到交换机管理员（以这种方式配置ARP缓存，否则可能会失败）。被动节点的循环重载稍微复杂一些。发生这种情况的原因是，被动节点看不到ARP记录处于活动状态，而是切换到主动模式，并且（注意！）通过HB链路轮询邻居。但是我们的邻居处于活动模式，并且具有更长的正常运行时间。此时，由于发生了状态冲突，被动节点意识到出了点问题，然后重新启动。这将无限期地继续下去。如果发生此问题，则需要检查failover.ini和交换中的IP地址设置。如果协调器上的所有设置都正确，那么是时候将网络工程师与问题联系起来了。
交叉地址
在我们的实践中，我们经常会遇到不同协调器后面的隧道地址的交集。
在这种情况下，ViPNet产品中存在地址虚拟化。虚拟化是一种NAT，无需监视一对一连接的状态或范围。默认情况下，此功能在协调器上是禁用的，尽管您可以在iplir.conf中的相邻协调器部分中的“ to”之后的“隧道”行中找到潜在的虚拟地址。若要全局启用整个列表的虚拟化，请在[可见性]部分中，将“ tunneldefault”参数更改为“ virtual”。如果要启用特定邻居，则需要在其[id]部分中添加参数“ tunnelvisibility = virtual”。同样值得确保将tunnel_local_networks参数设置为“ on”。要编辑虚拟地址，必须将tunnel_virt_assignment参数设置为“手动”模式。相反，您需要执行类似的操作。 “ usetunnel”和“ exclude_from_tunnels”参数还负责隧道设置。可以使用我上面提到的“ iplirdiag”实用程序来检查所执行工作的结果。
当然，虚拟地址会带来一些不便，因此基础架构管理员希望尽量减少使用。例如，当组织连接到某些政府机构的信息系统（IS）时，将向这些组织颁发DST文件，其中包含来自IS地址计划的固定范围的隧道。如我们所见，没有考虑到联系人的意愿。如何适应这个游泳池，每个人都自己决定。有人将工作站迁移到新的地址，有人在从主机到协调器的途中使用SNAT。某些管理员使用SNAT绕过较低平台的许可限制并不是什么秘密。我们不承诺评估此类“生活骇客”的道德标准，但请不要忘记平台本身的性能仍然存在局限性，当过载时，通信通道的质量将开始下降。
不能工作GRE
当然，每种IT解决方案在支持的用例上都有其自身的局限性，ViPNet协调器也不例外。一个相当烦人的问题是无法通过NAT将GRE（以及使用它的协议）从多个源工作到单个目标。以一个银行-客户系统为例，该系统建立了到银行公共地址的PPTP隧道。问题是GRE协议不使用端口，因此，在流量通过NAT之后，此类流量的套接字对变得相同（我们具有相同的目标地址，相同的协议，而我们只是将源地址转换为相同的地址）。协调器通过在错误104的背景下阻止流量来对此做出反应-连接已经存在。看起来像这样：
因此，如果您使用多个GRE连接，则应避免将NAT应用于这些连接。作为最后的选择，执行1：1广播（尽管在使用公共地址时这是不切实际的解决方案）。
不要忘记时间
我们继续使用事件编号4-IP数据包超时进行阻止的主题。这里的一切都是平庸的：当ViPNet网络节点（协调器和ViPNet客户端）之间的绝对时间（不包括时区）之间存在差异时，会发生此事件。在硬件协调器上，最大差异为7200秒，并在IPlir配置文件的“ timediff”参数中设置。我不在本文中考虑HW-KB协调器，但值得注意的是，在KB2版本中，timediff默认为7秒，在KB4中为50秒，并且该事件可能不是4生成的，而是112生成的，这可能令人困惑习惯于“常规”硬件的工程师。
未加密流量，而不是加密流量
对于初学者来说，可能很难在IP数据包日志中了解22事件的性质-来自网络节点的非加密IP数据包。这意味着协调器原本希望从该IP地址获得加密的流量，但未加密的流量来了。最常见的情况是这样的：
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
许多防火墙，包括ViPNet Coordinator，都可能在通过NAT的SIP上出现问题。假定虚拟地址是内部NAT，即使未显式使用NAT，而仅使用虚拟地址，也会出现问题。协调器具有应解决这些问题的应用程序协议处理（ALG）模块，但这并不总是能按需工作。我不会详细介绍ALG的机制（可以在该主题上写一篇单独的文章），其原理对于所有ITU都是相同的，只是应用级别的标题会发生变化。为了通过协调器正确运行SIP协议，您需要了解以下内容：
- 使用NAT时必须启用ALG。
- 使用虚拟寻址时，即使仅在一侧设置了虚拟可见性，也必须在参与交互的两个节点（协调器-协调器，协调器-客户端）上启用ALG；
- 当使用真实可见性且没有NAT时，必须关闭ALG，以免干扰SIP；
- ALG 3.x和4.x行不兼容（严格来说，在3.x行中根本无法控制它）。在这种情况下，供应商不能保证SIP的正确运行。
该模块由特权模式（启用）中的“ alg模块”组的命令控制。
最后
我试图考虑最紧迫的问题，确定其根源并讨论解决方案。当然，这些还不是ViPNet的全部功能，所以我建议不要害羞-与支持小组联系并在社区中寻求建议（在供应商论坛，电报频道中，本文下方的评论中）。而且，如果您不想陷入使用ViPNet的所有困难或过于繁琐的工作，那么始终可以将ViPNet网络的管理交给专业人员。
作者：Igor Vinokhodov，Rostelecom-Solar第二行政管理工程师