文章“【Azure Container App】Debug Console的调试工具指南”中，介绍了12种Azure Contianer App Debug Console模式下预装的调试工具。
文章“【Azure Container App】Debug Console的调试工具试验（一）-- iputils / net-tools / procps” 和 “【Azure Container App】Debug Console的调试工具试验（二）-- lsof/ util-linux / netcat / wget” 中，进一步通过试验的方式介绍了前七种工具。
本文继续前文的试验，开始试验 openssl / traceroute / ca-certificates / bind-utils / tcpping 这五种工具 。
8. openssl - SSL/TLS 证书诊断大师
openssl 是加密和 SSL/TLS 领域的标准工具，在容器环境中主要用于诊断 HTTPS 连接问题、查看服务器证书信息、测试 TLS 握手、验证证书链等。
当应用报告 SSL 相关错误时，openssl 是定位问题的不二之选。
openssl s_client 是最常用的子命令，它可以建立一个 SSL/TLS 连接并显示详细的握手信息。
通过分析这些信息，你可以了解服务器支持的 TLS 版本、使用的加密套件、证书链的完整性等关键细节。这对于排查 "SSL handshake failed"、"certificate verify failed"、"unknown CA" 等常见错误非常有帮助。
证书问题是 HTTPS 连接失败的主要原因之一。
常见的证书问题包括：
- 证书过期（可通过
-dates选项查看有效期） - 域名不匹配（证书中的 CN 或 SAN 与访问的域名不一致）
- 证书链不完整（服务器没有发送中间证书）
- 根 CA 不受信任（容器中缺少必要的 CA 证书）。
openssl 可以帮助你逐一排查这些问题。
在某些场景下，你可能需要测试特定的 TLS 版本或加密套件。例如，某些旧系统可能只支持 TLS 1.0，而现代安全标准要求至少使用 TLS 1.2。
通过 openssl s_client -tls1_2 可以强制使用特定的 TLS 版本进行测试，帮助你了解服务器的兼容性配置。
试验指令：
# 连接服务器并显示证书信息
openssl s_client -connect portal.azure.cn:443 -servername portal.azure.cn
# 查看证书有效期
openssl s_client -connect portal.azure.cn:443 </dev/null 2>/dev/null | openssl x509 -noout -dates
# 查看证书详细信息
openssl s_client -connect portal.azure.cn:443 </dev/null 2>/dev/null | openssl x509 -noout -text
# 显示完整的证书链
openssl s_client -connect portal.azure.cn:443 -showcerts
# 测试特定 TLS 版本
openssl s_client -connect portal.azure.cn:443 -tls1_2
# 验证本地证书文件
openssl x509 -in certificate.crt -text -noout
# 检查证书链验证结果
openssl s_client -connect portal.azure.cn:443 -verify_return_error
效果截图：
典型场景：
当应用报告 "certificate verify failed" 或 "unable to get local issuer certificate" 时，使用 openssl s_client -connect target:443 -showcerts 连接目标服务器，查看返回的证书链。
如果 "Verify return code" 不是 0，说明证书验证失败，具体原因会在输出中显示。常见的错误代码包括：18（自签名证书）、19（证书链中自签名证书）、20（无法获取本地颁发者证书）、21（无法验证第一个证书）。
9. traceroute - 网络路径追踪器
traceroute 是一个用于追踪网络数据包路径的诊断工具。它通过发送不同 TTL（Time To Live，生存时间）值的数据包，逐跳记录数据包经过的路由器，从而显示从源到目的地的完整网络路径。这对于排查网络延迟、路由问题、网络不可达等问题非常有价值。
traceroute 的工作原理是利用 IP 协议的 TTL 字段。
- 当数据包的 TTL 减为 0 时，路由器会丢弃该数据包并返回一个 ICMP "Time Exceeded" 消息。
- traceroute 首先发送 TTL=1 的数据包，第一跳路由器返回超时消息，traceroute 记录该路由器的地址和响应时间；
- 然后发送 TTL=2 的数据包，第二跳路由器返回超时消息；
- 以此类推，直到数据包到达目的地或达到最大跳数。
在复杂的云网络环境中，traceroute 帮助你理解流量的实际路径。
这对于排查"为什么访问某个服务特别慢"、"流量是否经过了预期的路由"等问题非常有帮助。
然而，需要注意的是，很多网络设备会阻止或限制 ICMP 协议，导致某些跳显示 * * *（超时）。
此时可以尝试使用 TCP 模式（-T 参数）进行追踪。
traceroute 的输出包含每一跳的 IP 地址（如果可以解析，还会显示主机名）和三次探测的响应时间。
通过分析响应时间的变化，可以定位延迟突增的节点。如果某一跳开始出现持续超时，说明问题可能在该节点或其后的网络。
试验指令：
# 基本路由追踪
traceroute portal.azure.cn
# 使用 TCP 模式（可绕过 ICMP 防火墙）
traceroute -T -p 443 portal.azure.cn
# 使用 UDP 模式
traceroute -U portal.azure.cn
# 不解析域名（加快速度）
traceroute -n portal.azure.cn
# 设置最大跳数
traceroute -m 20 portal.azure.cn
# 设置等待超时时间
traceroute -w 2 portal.azure.cn
效果截图：
典型场景：
当容器访问外部服务延迟很高时，使用 traceroute 可以看到延迟在哪一跳突然增加。如果延迟在前几跳就很高，问题可能在本地网络或容器网络配置；
如果延迟在某一跳突然增加，问题可能在该节点或该段网络。如果某一跳显示 * * *，不一定表示网络不通，可能只是该节点不响应探测包。
此时应该尝试 -T 参数使用 TCP 模式，或者结合 tcpping 进行进一步测试。
10. ca-certificates - CA 证书管理
ca-certificates 不是一个命令行工具，而是一个包含受信任 CA（证书颁发机构）根证书的软件包。
它为系统提供验证 HTTPS 连接所需的根证书信任链。当应用报告 SSL 证书验证失败时，往往需要检查或更新 CA 证书配置。
需要特别注意的是，Azure Container Apps 的 Debug Console 基于 Fedora/Mariner 系统，使用 ca-trust 机制管理证书，而非 Debian/Ubuntu 系统中常见的 update-ca-certificates 命令。
这是很多工程师容易踩的坑：在 Debug Console 中执行 update-ca-certificates 会报 "command not found" 错误。
在 Fedora/Mariner 系统中，CA 证书的管理结构如下：
/etc/pki/ca-trust/是 CA 信任管理的根目录；/etc/pki/ca-trust/source/anchors/是添加自定义 CA 证书的位置；/etc/pki/ca-trust/extracted/存放系统提取的证书文件；- 常见的
/etc/ssl/certs/目录实际上只包含指向/etc/pki/的符号链接。
当需要添加企业内部的私有 CA 证书时，正确的步骤是：
- 将证书复制到
/etc/pki/ca-trust/source/anchors/目录，然后执行update-ca-trust命令更新证书存储。
注意，Debug Console 中的更改是临时的，容器重启后会丢失。如需永久添加自定义 CA，应该在构建容器镜像时将证书添加进去。
试验指令：
# 查看证书存储位置（注意这里只有符号链接）
ls -la /etc/ssl/certs/
# 查看实际的 CA 证书 bundle
ls -la /etc/pki/ca-trust/extracted/pem/
# 查看 CA bundle 中包含的证书数量
awk '/BEGIN CERTIFICATE/{ count++ } END { print count }' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
# 添加自定义 CA 证书（正确方法）
cp custom-ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust
# 验证证书是否已添加
trust list | grep -i "your-ca-name"
效果截图：
典型场景：
当应用报告 "unable to get local issuer certificate" 或 "certificate verify failed" 时，通常是因为服务器证书的根 CA 不在容器的信任列表中。这在访问企业内部服务（使用私有 CA 签发的证书）时很常见。
解决方案是将企业的根 CA 证书添加到 /etc/pki/ca-trust/source/anchors/ 并运行 update-ca-trust。
- 如果问题只在调试时出现，可以通过这种方式临时解决；
- 如果是生产环境的问题，需要在容器镜像中预置必要的 CA 证书。
11. bind-utils - DNS 诊断专家
bind-utils 提供了一组强大的 DNS 查询和诊断工具，包括 dig、nslookup、host 等。
在容器环境中，DNS 解析问题是最常见的故障类型之一。这些工具帮助你验证 DNS 配置、排查解析失败、分析 DNS 响应，是网络故障排查的必备工具。
dig（Domain Information Groper）是功能最强大的 DNS 查询工具，它可以查询各种类型的 DNS 记录，并显示详细的查询过程和响应信息。
dig 的输出包含多个部分：
- QUESTION SECTION 显示查询内容
- ANSWER SECTION 显示查询结果
- AUTHORITY SECTION 显示权威 DNS 服务器
- ADDITIONAL SECTION 显示附加信息
通过分析这些信息，可以全面了解 DNS 解析的情况。
dig +trace 是一个非常有用的选项，它会从根 DNS 服务器开始，逐级追踪域名解析的完整过程。这对于排查 "NXDOMAIN"、"SERVFAIL" 等 DNS 错误非常有帮助，可以准确定位是哪一级 DNS 服务器出了问题。
nslookup 和 host 是两个更简单的 DNS 查询工具。nslookup 提供交互式和非交互式两种模式，输出格式较为传统；host 的输出最为简洁，适合快速查询。三个工具各有特点，可以根据需要选择使用。
试验指令：
# 查询 A 记录
dig portal.azure.cn A
# 简洁输出（只显示 IP 地址）
dig +short portal.azure.cn
# 指定 DNS 服务器查询
dig @8.8.8.8 portal.azure.cn
# 追踪完整解析过程
dig +trace portal.azure.cn
# 查询所有记录类型
dig portal.azure.cn ANY
# 反向 DNS 查询（IP 到域名）
dig -x 10.0.0.1
# 使用 nslookup
nslookup portal.azure.cn
# 使用 host（最简洁）
host portal.azure.cn
效果截图：
典型场景：
当应用报告 "Name or service not known" 或 "DNS resolution failed" 时，首先使用 dig target-host 查看是否能正常解析。如果解析失败，需要判断是本地 DNS 配置问题还是域名本身的问题。方法是使用公共 DNS 服务器进行对比测试：dig @8.8.8.8 target-host（Google DNS）或 dig @1.1.1.1 target-host（Cloudflare DNS）。如果公共 DNS 能解析但本地不行，问题在本地 DNS 配置；如果都不能解析，问题在域名本身。dig +trace 可以追踪完整的解析链，帮助你定位具体是哪一级出了问题。
12. tcpping - TCP 端口连通性测试
tcpping 是一个专门用于测试 TCP 端口连通性和延迟的工具。
与传统 ping 使用 ICMP 协议不同，tcpping 使用 TCP 连接进行测试，能够更准确地反映应用层的实际网络连通性。
在很多云环境和企业网络中，ICMP 协议被防火墙阻止，此时 tcpping 就成为测试网络连通性的最佳选择。
tcpping 的工作原理是向目标主机的指定端口发起 TCP 连接（三次握手），测量连接建立的时间，然后立即关闭连接。
这个过程与应用程序建立 TCP 连接的过程完全一致，因此 tcpping 显示的延迟更能反映应用的真实网络体验。
与 nc -zv 相比，tcpping 的优势在于可以持续进行多次测试，并显示每次测试的延迟和统计信息（最小、最大、平均延迟）。
这对于监控网络质量、发现间歇性网络问题非常有帮助。例如，你可以使用 tcpping -c 100 target 443 进行 100 次测试，观察延迟的波动情况。
tcpping 是容器网络故障排查的利器。当 ping 不通但你确信服务是运行的，tcpping 往往能够成功连接，证明 TCP 层面网络是通的，只是 ICMP 被阻止了。
这种情况在云环境中非常常见，了解这一点可以避免走很多弯路。
试验指令：
# 测试 TCP 端口连通性
tcpping portal.azure.cn 443
# 测试数据库端口
tcpping database-server 3306
# 测试 Redis 端口
tcpping redis-server 6379
# 测试 SSH 端口
tcpping jump-server 22
效果截图：
典型场景：
当 ping 显示目标不可达，但你确信服务是运行的，使用 tcpping target 80 可能会发现 TCP 端口其实是通的。这说明网络本身没有问题，只是 ICMP 被阻止了。
tcpping 还可以用于监控服务可用性：通过定期执行 tcpping -c 10 并观察成功率和延迟，可以发现网络质量问题或服务不稳定的情况。
如果发现延迟偶尔突然增大或偶尔连接失败，可能存在网络抖动或服务负载问题。
<第三部分完，Container App Dubeg Console中预装的十二种工具介绍完毕。谢谢>
文章回顾：
【Azure Container App】Debug Console的调试工具指南
【Azure Container App】Debug Console的调试工具试验（一）-- iputils / net-tools / procps
【Azure Container App】Debug Console的调试工具试验（二）-- lsof/ util-linux / netcat / wget
参考资料
Connect to a container debug console in Azure Container Apps : https://learn.microsoft.com/en-us/azure/container-apps/container-debug-console?tabs=bash#built-in-tools-in-the-debug-console
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
