cassandra节点到节点加密抛出无法与对等方闲聊异常

我们目前在aws中运行一个多区域cassandra集群。它在四个区域中运行，每个区域12个节点。它运行时没有节点到节点的加密（或者客户端加密）。我们正在尝试启用数据中心节点间加密。然而，当我们翻转加密时，我们得到一个例外，即节点 unable to gossip with any peers. 可能是因为我们没有正确地构建jks密钥库/信任库（下面将详细介绍如何构建这些文件）。但是，我们还没有看到数据中心内部通信工作（应该设置为未加密通信）。另外，cqlsh也不能连接到节点；即使我们有（默认情况下） client_auth_required 设置为 false .

ERROR [main] 2019-08-15 18:46:32,241 CassandraDaemon.java:749 - Exception encountered during startup
java.lang.RuntimeException: Unable to gossip with any peers
        at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1435) ~[apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:566) ~[apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:823) ~[apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.StorageService.initServer(StorageService.java:683) ~[apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.StorageService.initServer(StorageService.java:632) ~[apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:388) [apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:620) [apache-cassandra-3.11.4.jar:3.11.4]
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:732) [apache-cassandra-3.11.4.jar:3.11.4]
INFO  [main] 2019-08-15 18:47:07,384 YamlConfigurationLoader.java:89 - Configuration location: file:/etc/cassandra/cassandra.yaml

需要注意的是，此错误消息发生在节点启动几分钟之后(i、 e.在引发此异常之前，两次启动之间存在延迟）。
关于我们的Cassandra设置的信息
Cassandra版本：3.11.4
jdk版本：openjdk-8。
linux:ubuntu18.04（仿生版）。
Cassandra.亚马尔

endpoint_snitch: Ec2MultiRegionSnitch

server_encryption_options:
  internode_encryption: dc
  keystore: <omitted>
  keystore_password: <omitted>
  truststore: <omitted>
  truststore_password: <omitted>

client_encryption_options:
  enabled: false

cassandra-rackdc.properties公司

prefer_local=true

ssh输出没有明显错误
当Cassandra开始 JVM_OPTS="$JVM_OPTS -Djavax.net.debug=ssl" 添加到 cassandra-env.sh 我们看到打印到stdout的ssl日志（注意：主题和发布者是故意省略的）。

found key for : cassy-us-west-2                                                                                                                                                                                                       
adding as trusted cert:                                                                                                                                                                                                               
  Subject: ...                                                                                                                                                      
  Issuer:  ...                                                                                                                                                      
  Algorithm: RSA; Serial number: 0xdad28d843fc73325d4c1a75207d4e74                                                                                                                                                                    
  Valid from Fri May 27 00:00:00 UTC 2016 until Tue May 26 23:59:59 UTC 2026  

...

trigger seeding of SecureRandom
done seeding SecureRandom

查看JavaSESSL/tls连接调试，这看起来是正确的。但要注意的是，我们看到这一系列消息（以及rsa密钥签名输出）在快速射击中重复了几次。我们从未观察到任何关于添加信任存储的消息；但是，这可能只是在客户机启动时发生（？）
此外，我们确实看到cassandra报告加密消息服务已经启动。

INFO  [main] 2019-08-15 18:45:31,022 MessagingService.java:704 - Starting Encrypted Messaging Service on SSL port 7001

似乎不是cassandra.yaml配置问题
我们可以通过简单地配置 internode_encryption: none . 此操作似乎排除了广播\u地址或rpc \u地址配置问题。
我们如何建立密钥库/信任库
我们遵循datastax文档的基本模板来准备ssl证书。一个小的区别是我们的私钥和csr是使用 openssl . 每个区域一个（我们计划跨区域中的节点共享密钥/签名证书）。这是使用命令模板创建的：

openssl req -new -newkey rsa:2048 -out cassy-<region>.csr -keyout cassy-<region>.key -config cassy-<region>.conf -subj "..." -nodes -sha256

生成的csr由内部根ca签名。因为我们使用openssl生成文件，所以我们必须通过将证书导入jks文件来构建jks文件。
生成信任库的命令
我们将这个文件分发给所有节点。

keytool -importcert 
    -keystore generic-server-truststore.jks 
    -alias rootCa  
    -file rootCa.crt 
    -noprompt
    -keypass omitted 
    -storepass omitted

生成密钥库的命令
这是每个地区做一次；但实际上，我们使用keytool创建了一个密钥库，然后删除了密钥条目，然后使用keytool从pkcs12文件导入了密钥条目。

keytool -genkeypair -keyalg RSA -alias cassy-${region} -keystore cassy-${region}.jks -storepass omitted -keypass omitted -validity 365 -keysize 2048 -dname "..." 

keytool -delete -alias cassy-${region} -keystore cassy-${region}.jks -storepass omitted

openssl pkcs12 -export -in signed_certs/${region}.pem -inkey keys/cassandra.${region}.key -name cassy-${region} -out ${region}.p12 

keytool -importkeystore -deststorepass omitted -destkeystore cassy-${region}.jks -srckeystore ${region}.p12 -srcstoretype PKCS12 

keytool -importcert -keystore cassy-${region}.jks -alias rootCa -file ca.crt -noprompt -keypass omitted -storepass omitted

回想起来，我不记得为什么我们使用keytool生成一个keypair/keystore，然后删除并导入。我认为这是因为keytool importkeystore命令拒绝在keystore不存在的情况下运行。
ca.crt和pem文件
这个 ca.crt 文件包含根证书和用于签署csr的中间证书。pem文件包含返回给我们的已签名csr、中间证书和根ca（按顺序）。
openssl验证ca.crt和pem

openssl verify -CAfile ca.crt us-west-2.pem
signed_certs/us-west-2.pem: OK

启用加密后的命令输出 nodetool status （输出被截断）

Datacenter: us-east                                                                                                
===================                                      
Status=Up/Down                                           
|/ State=Normal/Leaving/Joining/Moving                   
--  Address         Load       Tokens       Owns (effective)  Host ID                               Rack
?N  52.44.11.221    ?          256          25.4%             null                                  1c             
...
?N  52.204.232.195  ?          256          23.2%             null                                  1d             
Datacenter: us-west-2                                                                                              
=====================
Status=Up/Down                                           
|/ State=Normal/Leaving/Joining/Moving                   
--  Address         Load       Tokens       Owns (effective)  Host ID                               Rack           
?N  34.209.2.144    ?          256          26.5%             null                                  2c             
UN  52.40.32.177    105.99 GiB  256          23.7%             null                                  2c            
?N  34.210.109.203  ?          256          24.7%             null                                  2a   
...

联机节点是设置了加密的节点。 cqlsh 到本地主机

cassy-node6:~$ cqlsh
Connection error: ('Unable to connect to any servers', {'127.0.0.1': error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error: Connection refused")})
``` `cqlsh` 到远程节点远程节点是启用了加密的节点

cassy-node6:~$ cqlsh 10.0.2.7
Connection error: ('Unable to connect to any servers', {'10.0.2.7': error(111, "Tried connecting to [('10.0.2.7', 9042)]. Last error: Connection refused")})

我们期望的行为
我们期望节点报告其他区域全部关闭，因为它们需要通过加密处理。因此，这是预期的工作；然而，cqlsh和内部数据中心对等点被报告为不可访问是意外的。
具体地说，我们希望节点仍然显示同一数据中心内的对等节点，无论是否存在证书问题/错误。我们也期待 `cqlsh` 继续工作。
最后，我们还试图找出是否存在jks证书问题。

cassandra节点到节点加密抛出无法与对等方闲聊异常

暂无答案！

相关问题

热门标签

最新问答