前些天，同事问我DBLINK传输能不能加密，我当时可能是在喝酒，张嘴就回了说不行。后来想想，其实可以通过SQLnet的传输加密来做。比较简单。

本次测试为对比测试，加密前后各抓一个包，用wireshark打开看数据是否被加密。

源库和目标库信息如下：

DBNAME	IP ADDR	VERSION
remotepdb1	10.10.133.64	19.3
ora19pdb1	10.10.133.63	19.3

ora19pdb1通过DBLINK连到remotepdb1的HR用户：

在remotepdb1所在主机10.10.133.64上用root打开tcpdump抓取10.10.133.63和10.10.133.64交互的包。

在ora19pdb1上执行一个简单的查询，这个查询使用dblink连接到remotepdb1：

然后把生成的no_encryption.pcap文件用wireshark打开，本次查询一共抓到12帧。

10.10.133.63发给10.10.133.64的帧中能看到转义之后SQL明文。同样64给63的回包的TCP segment data也是明文，但是不是直接回表的数据，而是先告知客户端要查的表有哪些列，然后客户端根据这些列重新生成了一个SQL发给64来执行。这个过程以前未曾观测到过。

server端向client端回传查询到的数据的明文，一直没想到SQLNET默认是明文的方式传输的。比较不安全。此外。在所有数据都返回了之后，还隐藏了一个ORA-01403：no data found给客户端，但是实际上客户端是看不到这个错误的，猜测这是告知客户端数据已回传完毕，客户端可以以“xx rows selected”了。

现在开始在server对sqlnet.ora进行配置，来加密sqlnet的传输帧。

sqlnet的加密在Oracle的Database Advanced Security文档中，在此不详细叙述各个参数的意义了。除了传输加密，我还打开了一致性校验。为了更好的看到加密过程，除了抓包之外，我还打开了sqlnet的trace。最终在sqlnet.ora中的参数如下：

然后在server端开启tcpdump，重新开启一个客户端到服务器端的会话，执行类似的查询，获得抓包的文件和sqlnet的trace。

在trace中：

随后，打开tcpdump的包：

证明加密成功。

加密的配置不复杂，下面为客户端和服务器端的参数匹配情况，默认是Accepted，OFF代表未开启加密，ORA-12660代表Encryption or crypto-checksumming parameters incompatible，无法建立链接。

	Rejected	Accepted	Requested	Required
Rejected	OFF	OFF	OFF	ORA-12660
Accepted	OFF	OFF	ON	ON
Requested	OFF	ON	ON	ON
Required	ORA-12660	ON	ON	ON

此外，加密最关心对性能的损耗，对资源的消耗，对查询效率的影响等等。国外同行在10.2下，开启每种加密算法，对DBA_OBJECTS进行100次查询，统计出来的结果如下：

可以看到3DES168对性能影响巨大。而其他加密算法的效率还在可以接受的范围内，最低的有4%。仅供参考。