.png)
几乎没有用于 IPv6 安全的工具，因此我想推出自己的解决方案，稍后我将开源该解决方案。 SO：我需要一个正则表达式来筛选远程 IPv6 连接的日志，以分析和处理它们，以防止在具有大量日志的非常繁忙的服务器上发生潜在的阻塞。因此我真的只对匹配的正则表达式感兴趣真实的（实际）IPv6 全球单播地址（“瓜阿")。由于阻止无效地址没有任何价值，因此验证 IPv6 地址构造很好，但不是必需的。
为什么这（有点）具有挑战性：
由于 IPv6 地址的压缩方式（前导零被压缩），地址可以用单个冒号和单个分号分隔和一组双分号。并且双对分号可以出现在不同的位置，具体取决于地址压缩的方式！最后，由冒号分隔的地址字符的数量也是可变的。
因此，我正在寻找的正则表达式的目标可能类似于以下几个示例之一：
2001:db8:800:400::130
2001:db8:800:400::2:135
2001:db8:d::55:1
2001:db8:1ff:8c0:151:164:108:23
我认为上面的内容确实说明了构建正则表达式来匹配这种混乱的难度。
正则表达式的预期输出：
- 精确的： 火柴仅有的有效的 GUA 地址；日志中不是部分 GUA 或本地 GUA。
grep仅限单身人士: 没有grep管道grep穿过grep...- 表现出色：正则表达式可能会占用 CPU 资源。一个答案（现已删除）运行了近 3 个小时仍未完成，直到我不得不杀死它。
- 已测试：测试很简单，因此请在发布之前确保您的正则表达式正确匹配。听起来很明显，但是...
例子：
grep "your RegEx Goes Here" /var/log/messages | sort -u
应该提供一个可爱的 GUA 地址列表，运行快速、正确且高性能。
选修的：
正则表达式至少应识别在 中找到的真实、完整的 GUA IPv6 地址/var/log/messages。 然而：如果您的正则表达式可以验证任何输入以确定地址构造是否有效，那就更好了！
请发帖帕斯特宾与您的测试结果，以便所有人都可以查看和比较结果。我将运行同一服务器上发布的所有正则表达式来比较它们的结果和性能。最好的、性能最好、最准确的正则表达式将用于开源解决方案，并对天才给予应有的赞扬。
答案1
更新：
后@ilkkachu发现我之前的正则表达式缺少范围后，我回到了绘图板并从头开始完全重写它并对其进行了测试，审核了 4300 多个结果的样本。包含新结果的粘贴箱也会更新以供您审阅。看起来很正义，但最好让干净独立的眼睛来判断。
笔记：
3000:0000::/4下面的正则表达式已经过测试，发现可以正确处理 GUA 寻址指定的 IANA 全局地址单播分配，但、3ffe::/16和除外5f00::/8。后 2 个范围用于 6 个骨骼，现已弃用，这些范围已返回，并且是3000:0000::/4保留的，在野外未找到，并且可能永远不会使用。因此，我在选择正则表达式时已经解决了这些问题。如果反对票附有发现错误的反馈，欢迎投反对票。事实上，我在这里发帖是为了让我的想法得到严格的审查；没有橡皮图章;-)
解决方案：
我在 IPv6 RegEx 的各个 Stack 站点上发现的所有其他问题都覆盖了太广的范围，与 IPv6 寻址的厨房水槽相匹配。如果要使用grepIP 黑名单的输出（我的最终目标），那么，缺乏精确度可能是一个大问题。令人惊讶的是，谷歌搜索也没有任何结果。
因此：为了避免其他人浪费时间来解决同样的问题，以下是我提出的仅匹配 IPv6 GUA 地址的方法：
time grep -Eo "2[0-9a-fA-F]{3}:(([0-9a-fA-F]{1,4}[:]{1,2}){1,6}[0-9a-fA-F]{1,4})" /var/log/messages | sort -u >> /root/GUA-RegEx-Results.txt
测试：
正则表达式 - 来自我在 * 上的测试非常繁忙的 DNS 服务器 - 似乎有效匹配IANA 的全球地址单播分配。在测试时，我专门寻找与以下相关的错误：
- 部分GUA地址
检测结果：
没有观察到此类错误，可以审查我的结果这里 （请注意:不应从该 Pastebin 列表中的任何地址推断滥用情况）。
用于验证结果的工具：
只需复制并过去地址，看看您是否在上述链接中发现了叮当声
表现：
为了筛选 1.5GB /var/log/messages 文件，观察到以下性能：
找到有效的唯一 IPv6 地址：
- 4345
速度：
- 真实0米56.346秒
- 用户 0m28.916s
- 系统0m0.328s
如果你有更紧致、更优雅的东西（极客喜欢有趣的正则表达式挑战，让我们面对它），无论如何，请在答案中贡献它。