一、现象
外网连公司内部的一个sftp服务失败，提示如下：
kex_exchange_identification: read: Connection reset by peer
Connection reset by xxxx port 21888
Connection closed.
Connection closed
二、初步排除
首先检查网络连通性，发现ping正常，但是telnet连接上后立刻断开，如下：
$ telnet xxxxx 21888
Trying xxxxx...
Connected to xxxxx.
Escape character is '^]'.
Connection closed by foreign host.
根据经验，请求已经到达了服务端，但是因为某些原因服务端把其连接给中断了。
由于外网进来经过了外网防火墙、负载均衡，故尝试在本地直接访问该SFTP服务对应的负载均衡IP，发现能支持sftp及telnet。故判断服务端服务没有问题，问题应该出在外网防火墙及负载均衡之间。
和网络同事一起抓包分析，折腾了半天，发现reset的操作是服务端过来的，推翻前面的推断。
三、检查客户端
服务端是一台windows主机，上面部署了一个提供sftp的服务。先尝试万能大法重启没效果。
检查sftp应用日志，没有任何可用信息。检查防火墙，没发现异常。
检查windows自带的日志事件，在安全事件下发现如下事件：
Windows 筛选平台已阻止连接。
应用程序信息:
进程 ID: 8664
应用程序名称: \device\harddiskvolume2\program files (x86)\freeftpd\freeftpdservice.exe
网络信息:
方向: 入站
源地址: 负载均衡IP
源端口: 34255
目标地址: 服务端IP
目标端口: 21888
协议: 6
筛选器信息:
筛选器运行时 ID: 68682
层名称: 接收/接受
层运行时 ID: 44
从该事件看，确认是服务端自己阻止了这个链接。
四、 根因分析
知道是服务端阻止了，但是具体是谁阻止的还不清楚。但是按经验，一般是安全软件惹的祸。但是恰巧安全同事不在，而该主机上又存在卡巴杀毒软件及EDR安全防护，两个都可能产生。而且有时安全那边也查不到什么就会扯皮了。那怎么确认到底是谁阻止了呢？查资料发现可以根据筛选规则来进一步确认。
我们先导出客户端上所有的筛选规则：
C:\>netsh wfp show filters
数据收集成功；输出 = filters.xml
然后打开filters.xml文件，根据上面事件中的筛选器运行时 ID: 68682 中的 68682 来搜索，就能找到下面这条规则：
<item>
<filterKey>{7e415384-ff3f-4753-932a-317da063a9e8}</filterKey>
<displayData>
<name>Kaspersky Lab WFP ALE auth accept V4 filter</name>
<description>Kaspersky Lab WFP ALE auth accept V4 filter</description>
</displayData>
<flags numItems="2">
<item>FWPM_FILTER_FLAG_PERSISTENT</item>
<item>FWPM_FILTER_FLAG_PERMIT_IF_CALLOUT_UNREGISTERED</item>
</flags>
<providerKey>{de6c7dfb-2fb8-4bd6-8556-60fca0fc4969}</providerKey>
<providerData/>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
<subLayerKey>{77d0703b-4fbb-4f82-a540-d5aa0ec6e213}</subLayerKey>
<weight>
<type>FWP_EMPTY</type>
</weight>
<filterCondition/>
<action>
<type>FWP_ACTION_CALLOUT_TERMINATING</type>
<calloutKey>{a15a1001-4551-4178-ad95-69f78225bdc4}</calloutKey>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>68682</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>0</uint64>
</effectiveWeight>
</item>
从 <name>Kaspersky Lab WFP ALE auth accept V4 filter</name> 可以得知，这个是Kaspersky 生成的一条规则，也即是卡巴斯基阻止了该链接。
至于为何卡巴斯基会阻止，那就只能等安全同事那边再分析了。
五、总结
- 不能太相信经验，内部能访问服务不代表服务端没问题。
- 优先检查下windows自带的事件日志，如果没开启能尽可能开启失败日志的收集。
...