什么会延迟Jenkins服务器和SSL SVN服务器之间的握手(两者都没有互联网访问)？

tsm1rwdh 于 2023-05-16 发布在 Jenkins

关注(0)|答案(4)|浏览(233)

我们有一个运行Jenkins（1.477，1.480.3和1.508）的VM（在VMWare集群中）来构建SVN存储库（Collabnet SVN 1.7.5-3150.92）的提交。该存储库通过SSL连接访问。出于安全原因，两台计算机（构建服务器或SVN服务器）都不能访问互联网。当Jenkins构建开始SVN更新时，作业的控制台会在更新“https://vcfs01.redacted-address.com/svn/MTCM/Trunk”时暂停30 - 90秒。一旦更新开始，它是相当快的。
为了排除Jenkins是罪魁祸首的可能性，我使用TortoiseSVN从构建服务器进行了一次检出，从而重现了同样的问题。Tortoise也有同样的延迟，一旦文件开始传输，传输速率范围为50 - 70 KB/s（这很棒）。
我们使用卡巴斯基，并已排除它作为一个问题，因为这个问题不会发生在程序员的电脑上有卡巴斯基。我们还尝试排除两个服务器，以确保%100。
有一段时间我确信这是证书吊销检查的问题，因为我看到WireShark尝试从http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?dca976bb02bdc2e3进行HTTP GET。使用this KB article中的步骤，我在Jenkins服务器和SVN服务器上禁用了证书撤销检查（尽管我怀疑后者是否重要）。一旦我做了这个更改，我就不再尝试连接windowsupdate服务器，而是看到了来自http://crl.globalsign.com/gs/gsorganizationvalg2.crl的HTTP GET。我偶然发现了this article on disabling CRL checking。我遵循了两个服务器的步骤，不再看到HTTP GET到外部（互联网）地址。
当Jenkins服务器可以访问互联网时，Tortoise中的握手时间约为5秒（而防火墙阻止访问时约为90秒）。尽管Tortoise的握手速度很快，但Jenkins的速度与防火墙到位时相同！
我对Jenkins做了一些研究（我还将Jenkins从版本1.477更新到了1.508），发现了一篇关于SVNKit在符号链接方面存在问题的文章。据我所知，没有使用任何符号链接。
我在WireShark中看到的是，在Jenkins服务器和SVN服务器之间有一些初始活动（创建加密连接）。在初始活动后约30秒过去，然后有更多的活动（发送应用程序数据）。在应用程序数据之后，还有一个~30秒的延迟，然后发送更多的应用程序数据，重置加密连接，并开始更新。
我和网络小组讨论了@Chris和@Barmar写的东西，网络小组说：
我们的DNS服务器已经有一个反向168.192查找区，它是由相当多的服务器填充。除了搜索内部服务器的旧流氓条目外，我很少对这些区域做任何事情。
我想这意味着它不是一个查找问题，但我在这里超过我的头。以下是Jenkins机器（172.25.2.106）和SVN服务器（172.25.2.106）之间的过滤捕获，显示了数据包传输之间的暂停：

这两台计算机都是Win 2K 8 R2 Datacenter VMware计算机。根据我们的网络组，这些服务器的DNS条目/查找已配置且工作正常。

Jenkins

来源：https://stackoverflow.com/questions/15641656/what-could-delay-the-handshake-between-a-jenkins-server-and-an-ssl-svn-server-n

4条答案

按热度按时间

2hh7jdfx1#

**问题：**在防火墙服务器上通过命令行调用SVN后，15秒内没有任何可见的操作，然后程序退出，出现以下错误：

svn：E170013：无法连接到位于URL 'SVN. REPOSITOY.REDACTED'的存储库
svn：E730054：运行上下文时出错：远程主机强制关闭了现有连接。

**调查：**对上述错误的互联网研究没有发现任何相关信息。

进程跟踪（procmon）显示，在与SVN服务器进行SSL/TLS握手后，尝试连接Akamai（云服务）服务器。进程跟踪中未显示服务器的主机名。反向DNS查找显示主机名为a184-51-112-88.deploy.static.akamaitechnologies.com或a184-51-112-80.deploy.static.akamaitechnologies.com，IP为184.51.112.88或184.51.112.80（DNS缓存中有2个条目）。
数据包捕获工具（MMA）显示，ctldl.windowsupdate.com在与SVN服务器进行SSL/TLS握手后，尝试连接主机名www.example.com。
Windows Crypto API试图连接到Windows Update以检索证书吊销信息（CRL -证书吊销列表）。CRL检索的默认超时为15秒。服务器上的身份验证超时为10秒;因为15大于10，所以失败。

**解决方案：**互联网研究发现以下内容：（另见底部图片）

解决方案1：减少CRL超时组策略->计算机配置->Windows设置->安全设置->公钥策略->证书路径验证设置->网络检索-见下图。
https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698
support.microsoft.com/en-us/kb/2625048
blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx
解决方案2：为CRL流量打开防火墙
support.microsoft.com/en-us/kb/2677070
解决方案3：SVN命令行标志（未测试）
serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - alternate svn command line flag solution.

**其他信息：**调试此问题特别困难。SVN 1.8禁用了对 neon HTTP RA（存储库访问）库的支持，而支持删除客户端调试日志的Serf库。[1]另外，返回的SVN错误码与svn_error_codes. h中给出的字符串不匹配[2]另外，SVN错误码不能很容易地Map回它们的ENUM标签，在这种情况下，SVN错误码E170013Map到SVN_ERR_RA_CANNOT_CREATE_SESSION.

stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
code.google.com/archive/p/serf/issues/172

建议的SVN更改：

1.为所有操作启用命令的详细程度，如
1.将错误ENUM名称添加到stderr
1.为伺服器库调试日志添加配置标志。

赞(0）回复(0）举报 2023-05-16

vdzxcuhz2#

它仍然看起来像是DNS解析问题，证书吊销列表问题或（！）IPv6问题。我不能为您提供一步一步的解决方案，但这里是要检查的事项列表：

DNS

验证DNS解析在受影响的计算机（客户端和服务器）上是否正常工作，
验证所有涉及的计算机在DNS上都有PTR（反向查找区域）记录，并且这些记录正确。
证书
延迟是否会在普通HTTP上重现？
您是否在SVN服务器上安装了 * 自签名证书 *？证书在您的网络上是受信任的还是由证书颁发机构签名的？
IPv6
您是否尝试在客户端禁用IPv6并尝试访问SVN服务器？这个案子有延迟吗？

还有另一种方法可以帮助我们解决延迟问题：
您可以在Subversion客户端启用低级别日志记录，然后尝试在命令行客户端重现该问题.检查客户端上的调试输出，并查看延迟发生的确切时间。延迟之前和之后会发生什么？
如何启用客户端日志记录：
1.将以下字符串添加到客户端服务器文件上%APPDATA%\subversion\servers的[global]部分：
neon-debug-mask = 395
1.重现问题。查看操作何时开始“滞后”或间歇性停止（您应该注意操作何时中断）。
有关neon-debug-mask的更多详细信息，请参阅SVNBook：
霓虹灯调试屏蔽
这是一个整数掩码，底层HTTP库 neon 使用它来选择要生成的调试输出类型。默认值为0，这将使所有调试输出静音。有关Subversion如何使用 neon 的更多信息，请参见Chapter 8, Embedding Subversion.