使用 hping 时报错的处理

Linux中使用Nmap , hping, ping 提示以下错误时

PHP: [main]	can't	open	raw	socket

Bash: Couldn’t open a raw socket. Error: Permission denied (13)

非root进程调用带有网络原始套接字(raw socket) 的相关命令时,会报错,需要使用getcap 设置 capabilities

(具体参考:https://cloud.tencent.com/developer/article/1539041)

# 以 ping 为例,先 which 查看命令地址
which ping

# 如无返回就是没有设置cap
getcap /usr/bin/ping

# 设置cap
sudo setcap cap_net_raw+ep /usr/bin/ping

# 再次getcap 已有设置值
getcap /usr/bin/ping
#/usr/bin/ping cap_net_raw=ep

setcap 之后问题就解决了。

Linux下date的默认输出格式

在两个debian主机下 使用date命令,显示的格式不一样,分为两种(A/B):

  • A:Sat Sep 14 10:15:03 PM CST 2024
  • B:Sat Sep 14 22:15:15 CST 2024

以晚上十点一刻为例,A 的10:15是12小时制,带有PM, B的22:15是24小时制,没有PM。

所以问题是, 如何设置12小时制 为 24小时制? 继续尝试几种涉及时间设置的命令。

使用 timedatectl查看 : (题外话:该命令在wsl,windows子系统中无效

timedatectl status
 timedatectl status
Local time: Sat 2024-09-14 21:56:01 CST
Universal time: Sat 2024-09-14 13:56:01 UTC
RTC time: Sat 2024-09-14 13:55:53
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
timedatectl status
Local time: Sat 2024-09-14 21:56:07 CST
Universal time: Sat 2024-09-14 13:56:07 UTC
RTC time: n/a
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

“Local time” , “Universal time”, “Time zone” 时间都是正确,并一致的。时钟同步,NTP服务也都并未使用。RTC time一个有时间,一个为空,应该是虚拟化不同的问题。看来timedatectl的信息并不显示时间是否12/24制式。

locale 查看本地设置:

locale -a
C
C.utf8
en_US.utf8
POSIX
C
C.utf8
POSIX
en_US.utf8

都是 “en_US.utf8″,只是 POSIX顺序不用,也无关。

使用 dpkg-reconfigure tzdata 重新设置时区:

dpkg-reconfigure tzdata

之后再看date,结果证明也与时间12/24制式无关。

使用 date –debug,会显示输出格式:

date --debug
date --debug
date: output format: ‘%a %b %e %r %Z %Y’
Sat Sep 14 10:15:03 PM CST 2024
date --debug
date: output format: '%a %b %e %H:%M:%S %Z %Y'
Sat Sep 14 22:14:50 CST 2024

看到不同了把? date 输出不同时间进制,与设置时间的命令无关。只有输出个格式的不同。那么这个格式是什么决定的?在哪里定义的?

之后看到这篇文章:https://linuxopsys.com/change-default-date-format-in-linux

原来 date 命令的默认日期格式。是根据 locale 中的 LC_TIME 参数,根据参数名,使用关联的设置文件。

例如,运行 locale 命令并查找 LC_TIME 变量。

locale

如图,看到 LC_TIME = “en_US.UTF-8“,这是美国常用的日期格式。

第 2 步:找到与 Locale 关联的文件
locale 文件通常位于 /usr/share/i18n/locales/ 中。您将找到一个名称与您的 LC_TIME locale 设置相对应的文件,如果 LC_TIME 区域设置是 en_US, 对应文件为/usr/share/i18n/locales/en_US


查看 Locale 文件,可以看到其中的 date_fmt 之后的定义 与 date –debug 显示的输出格式一样,

//12小时
"%a %b %e %r %Z %Y"

//24小时
"%a %b %e %H:%M:%S %Z %Y"
~ # date +"%a %b %e %r %Z %Y"
Sun Sep 15 12:16:14 AM CST 2024

~ # date +"%a %b %e %H:%M:%S %Z %Y"
Sun Sep 15 00:17:31 CST 2024

使用 date + “输出格式” 测试, 由此我们发现了问题根源。但是什么,两个“LC_TIME ” 都是 “en_US”,格式会不同呢?答案在 en_US 文件的注释中:

% Appropriate date and time representation for date(1). This is
% different from d_t_fmt for historical reasons and has been different
% since 2000 when date_fmt was added as a GNU extension. At the end
% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.

也就是说,一个系统是2018年前安装,或设置生成的 Locale 文件,一个是在2018年之后

结尾

如此,明白了问题根源,就可以通过修改 locale 文件的date_fmt 或 重新设置 LC_TIME 环境变量,重新生成区域设置文件以应用更改。

locale-gen
update-locale

或者 用更简单的方法:

export LC_TIME=POSIX

直接设置 LC_TIME=POSIX,可以快速统一多台,不同本地语言设置的时间格式。

【END】

到底是谁的 CIDR?

原文:Whose CIDR Is It Anyway?

https://labs.ripe.net/author/jschauma/whose-cidr-is-it-anyway

【以下由 微软Bing 机翻】

IP 地址空间并没有被平均分配,经过多年的重新分配和重新分配,我想到的问题是:谁拥有它的哪些部分?在有关互联网集中化的系列文章的最新一篇中,Jan Schaumann 深入研究了数据,试图获得更清晰的视图。


今年是 2035 年,是桌面版 Linux 的一年(祈祷,这将是它!),IPv6 的广泛采用迫在眉睫,而 Amazon 刚刚购买了它没有拥有的最后一个 /8:。255.0.0.0/8

我们是怎么走到这一步的?

首先,我认为我们比 2035 年更接近这种情况,因为 Amazon 已经在内部使用 E 类地址,为什么不呢:

$ traceroute www.amazon.com
traceroute to e15316.dsca.akamaiedge.net (23.209.110.82), 64 hops max, 40 byte packets
 1  244.5.5.97 (244.5.5.97)  8.543 ms
    244.5.5.81 (244.5.5.81)  3.580 ms
    244.5.5.97 (244.5.5.97)  6.846 ms
 2  240.0.56.98 (240.0.56.98)  0.388 ms
    240.0.56.65 (240.0.56.65)  0.367 ms
    240.4.112.65 (240.4.112.65)  0.352 ms
 3  242.0.227.213 (242.0.227.213)  1.687 ms
    242.0.227.81 (242.0.227.81)  1.448 ms
    242.0.227.83 (242.0.227.83)  1.055 ms
 4  240.3.180.14 (240.3.180.14)  1.319 ms
    240.3.180.12 (240.3.180.12)  1.320 ms
    240.3.180.15 (240.3.180.15)  1.991 ms
[...]

当该网络块最终由 IANA 分配时,这将很有趣(例如,本草案中提议的1)和 Amazon 基本上会说“对不起,我们有 dibs。你不能指望我们重新编号所有 EC2,所以你还不如把整个 /4 给我们,kthanxbye。

(旁注:当然,它们的 IPv6 地址会做其他人做的事情,并将 IPv4 地址编码在其 v6 地址的底部字节中:

$ traceroute6 www.amazon.com
traceroute6: `www-amazon-com.customer.fastly.net' has multiple addresses; using `2606:2cc0::374'
traceroute6 to www-amazon-com.customer.fastly.net (2606:2cc0::374) from 2600:1f18:400c:b800:bdf1:6584:1971:4efe, 64 hops max, 12 byte packets
 1  2620:107:4000:2210:8000:0:f405:667  58.911 ms  # 244.5.102.7
    2620:107:4000:2210:8000:0:3ec:3e71  0.831 ms
    2620:107:4000:2210:8000:0:3ec:3e73  0.808 ms
 2  2620:107:4000:a792::f000:3841  0.419 ms        # 240.0.56.65
    2620:107:4000:a792::f000:3843  0.473 ms
    2620:107:4000:a792::f000:3842  0.4 ms
 3  2620:107:4000:cfff::f20c:2b01  17.258 ms       # 242.12.43.1
    2620:107:4000:cfff::f20c:2b81  12.562 ms
    2620:107:4000:cfff::f200:e353  2.026 ms
 4  2620:107:4000:c5c0::f3fd:1  1429.46 ms  1299.83 ms
    2620:107:4000:c5c0::f3fd:3  1368.37 ms
 5  2620:107:4000:cfff::f202:d4c3  2.15 ms
    2620:107:4000:cfff::f202:d545  1.931 ms
    2620:107:4000:cfff::f202:d445  1.358 ms
 6  2620:107:4000:8001::24  2.469 ms
    2620:107:4000:8001::44  10.271 ms
    2620:107:4000:8001::24  1.16 ms
[...]
$

这种做法对于戴着各种帽子的信息安全书来说非常有用,因为巨大的 IPv6 地址空间变得更加易于管理,通过这种方式,您可以收集有关目标的其他信息,所以谢谢你 – 但我跑题了。

总之,我想你明白我要说的是什么了:我们被告知,IANA 将 IP 空间分配给地区注册管理机构,他们进一步管理分配的网络块。一些早期采用者从 Jon Postel(最初的 IANA)那里得到了一份特别的礼物:他们自己的 /8。

在区域注册表级别,可用的 IP 空间没有均匀分配。如果我们去掉保留的 IP 空间(总共 35 /8,包括 E 类、组播和选定的其他网络块),只查看分配给不同区域互联网注册机构 (RIR) 的实际可用 IP 地址,那么我们会发现 ARIN 管理着超过 50% 的 IPv4 IP 空间,而 AFRINIC 只管理着 2.7%。相比之下,IPv6 地址空间的分配要均匀得多:

当然,当我们用完 IP 地址时,网络块被重新分配和重新分配,在区域注册表之间转移,公司开始交易网络块,如果你有一个备用的 /9 左右,这被证明是一个非常好的快速赚钱方式。

这样的例子有很多,例如谷歌在 2017 年从 Merit Networks 购买了 35.192.0.0/12,但让我们以亚马逊为例:

哦,在 2023 年,AWS 开始对公有 IPv4 地址的使用收费:0.005 USD/小时

但我开始这项研究基本上是因为我碰巧正在查看 AWS 发布的 ip-ranges 文件,我心想:“嗯,光是一家公司就有这么多 IP 地址。这甚至不是 Amazon 的全部,只是 AWS:

$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[].ip_prefix' | wc -l
    9180
$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
    jq -r '.prefixes[].ip_prefix' | \
    awk -F/ '{ sum += 2^(32-$2) } END { printf("%'"'"'d\n", sum) }'
144,578,747
$

顺便说一句,如果你应用 Amazon 的逻辑,对每个 IP 地址每小时收取半美分的费用,那么那里的 CIDR 每年为 Amazon 提供 63 亿美元的净价值。不算太寒酸。

但是,看着 Amazon 在这里拥有的巨大股份,以及各种其他 netblock 交易、重新分配和重新分配,我在想:我们甚至知道谁拥有 IP 空间的哪些部分吗?我的意思是,当然,我们有点“知道”,因为这些信息是必须可用的……地方。但是我们如何看待这些数据呢?

现在,如果您自己恰好不是 RIR,您该如何查找这些信息呢?我们知道 CIDR 块分配在 中,虽然它非常简单,而且当你是人类时,输出真的很容易阅读,但试图大规模地使用数据做任何事情都会一团糟whoiswhoiswhois

“有些人在遇到问题时会想’我知道,我会用 whois。’现在他们遇到了非结构化的文本问题。

幸运的是,RIR 自己发布了统计数据,以有据可查的格式显示了他们在此处联合进行的 ASN、IPv4 和 IPv6 分配(或按 RIR 为 AFRINIC、ARIN、APNIC、RIPE NCC 和 LACNIC)。这些数据如下所示:

$ curl -s https://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats | \
    grep "|ipv4|"
[...]
iana|ZZ|ipv4|0.0.0.0|16777216|19810901|reserved|ietf|iana
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED|e-stats
apnic|CN|ipv4|1.0.1.0|256|20110414|assigned|A92E1062|e-stats
apnic|CN|ipv4|1.0.2.0|512|20110414|assigned|A92E1062|e-stats
apnic|AU|ipv4|1.0.4.0|1024|20110412|assigned|A9192210|e-stats
apnic|CN|ipv4|1.0.8.0|2048|20110412|assigned|A92319D5|e-stats
apnic|JP|ipv4|1.0.16.0|4096|20110412|assigned|A92D9378|e-stats
apnic|CN|ipv4|1.0.32.0|8192|20110412|assigned|A92319D5|e-stats
apnic|JP|ipv4|1.0.64.0|16384|20110412|assigned|A9252414|e-stats
apnic|TH|ipv4|1.0.128.0|32768|20110408|assigned|A91CF4FE|e-stats
[...]
$

这非常有用,但请注意,我们没有得到实际的 CIDR 分配 — 我们得到的是起始地址和 IP 地址计数。我们确实得到了国家/地区代码信息(是的!),但没有 AS 信息,也没有所有权数据。所以不完全是我们正在寻找的。

但是,嘿 – 我们记得因为 whois 很愚蠢,互联网已经同意使用 RDAP 来代替了?那会很整洁!RDAP 是 RESTful 的!这是 JSON!它在 RFC 中指定(这么多很多很多很多 RFC),甚至还有真正有用的文档

$ curl -s -L https://rdap.db.ripe.net/ip/2.19.4.0
{
  "handle" : "2.19.0.0 - 2.19.15.255",
  "startAddress" : "2.19.0.0",
  "endAddress" : "2.19.15.255",
  "ipVersion" : "v4",
  "name" : "AKAMAI-PA",
  "type" : "ASSIGNED PA",
  "country" : "EU",
  "parentHandle" : "2.16.0.0 - 2.23.255.255",
  "cidr0_cidrs" : [ {
    "v4prefix" : "2.19.0.0",
    "length" : 20
  } ],
  "status" : [ "active" ],
  "entities" : [ {
    "handle" : "AKAM1-RIPE-MNT",
[...]

这看起来非常有用,但当然,最后我使用了所有这些交叉事实来源的组合:我只是从 开始,查找 RDAP 信息,提取 ,确定紧随其后的地址,然后重复 RDAP 查找,以这种方式迭代整个 IPv4 空间。0.0.0.0endAddress2然后,我对 Team Cymru 的 IP 到 ASN 服务执行了 DNS 查找,并使用通常的 Perl、 和 shell 胶水大杂烩,将所有这些数据与已发布的 RIR 统计数据进行交叉引用。awk(1)

现在,使用多个事实来源的问题是 — 正如任何曾经尝试过创建、使用或与之交互的人(例如资产清单)所告诉您的那样 — 您充其量只能获得所有不同来源的交叉视图。还有 bug。

“whois 很愚蠢*,请使用 RDAP。那会很棒!…他们说

使用标准化协议从互联网上的不同来源收集大量数据的有趣之处在于,它如何破坏您对标准化协议的信念,同时让您对遇到的所有边缘情况感到困惑。

RDAP 有很多优点,但该服务由五个以上的主要方(RIR 加上各种区域 NIC)运行,我发现了许多错误和问题:

  • 带和不带负载正文的 HTTP 重定向
  • 在 RIR 之间重定向循环3
  • RDAP IP 查询结果不包括 AS 编号(有时包含)whois
  • AFRINIC 有 API 限制,但不会告诉您它们是什么
  • 超过未知 API 限制时,AFRINIC 返回 429 状态代码 (yay),但没有 Retry-After 标头 (boo)
  • https://rdap.registro.br/会告诉你他们的 API 限制是每 20 秒 1 个请求;如果你超过它,那就是 403 Forbidden – 再见!(是时候轮换源地址了…
  • AFRINIC 有时会返回 -1 的网络掩码(例如196.28.253.0/22)
  • endAddressCIDR0_CIDRS4
  • ARIN 和 LACNIC 在 RDAP 中不包含国家/地区代码信息
  • JPNIC 不包含分配类型,实际上是将其设置为null

所以是的……

RDAP:与 “” 相同 GIGO,但至少它是 JSON。

whois

按国家/地区代码划分的 IPv4 分配

在收集并关联所有数据后,我最终得到了大约 300K 的信息5近 240 个国家/地区的 CIDR 分配。6CIDR 分配计数排名前 10 的国家/地区7是:

  1. 🇷🇺 俄罗斯(> 17K 分配)
  2. 🇩🇪 德国 (12.5K)
  3. 🇧🇷 巴西 (12.1K)
  4. 🇬🇧 英国 (11.8K)
  5. 🇮🇳 印度 (9.4K)
  6. 🇨🇳 中国 (9.3K)
  7. 🇦🇺 澳大利亚 (7.2K)
  8. 🇳🇱 荷兰 (7.2K)
  9. 🇯🇵 日本 (7.1K)
  10. 🇺🇸 美国 (6.5K)

但并非所有 CIDR 都是相等的 – 分配了数百个 /24 并不能弥补分配一个 /8。也许计算 IP 地址可能会更好?我们可以轻松地将这些数字相加,然后将它们与 IPv4 地址空间的总量进行比较:

  1. 🇺🇸 美国(1.61B 个 IP,占所有 IPv4 的 43.8%)
  2. 🇨🇳 中国 (343.17M, 9.3%)
  3. 🇯🇵 日本 (189.81M, 5.1%)
  4. 🇬🇧 英国 (127.41M, 3.5%)
  5. 🇩🇪 德国 (124.21M, 3.4%)
  6. 🇰🇷 韩国 (112.5M, 3.1%)
  7. 🇧🇷 巴西 (87.14M, 2.4%)
  8. 🇫🇷 法国 (82.18M, 2.2%)
  9. 🇨🇦 加拿大 (68.52M, 1.9%)
  10. 🇮🇹 意大利 (54.03M, 1.5%)

这里突出的当然是分配给美国的大量 IP 地址,以及美国和中国合计占 50% 以上的事实,是整个 IPv4 地址空间 75% 以上的前十个国家。

按国家/地区代码划分的 IPv6 分配

对于 IPv6 分配,我的数据仅基于 RIR 统计数据。总的来说,那里的信息没那么有趣,仅仅是因为 IP 空间如此之大,以至于集中化真的不是问题。为了完整起见,我在此处列出了 IPv6 的发现:

有趣的是,显然,中非共和国、厄立特里亚和朝鲜(以及南极洲、福克兰群岛、法属南部和南极地区、科索沃、斯瓦尔巴群岛和扬马延岛以及西撒哈拉)都没有 IPv6 分配。

按 RIR 分配的 IPv4

非洲人

如果我们从区域注册管理机构的角度来看,我们会注意到 AFRINIC 覆盖的不仅仅是非洲,尽管 AFRINIC 的前十名分配(占其所有分配的 80% 以上)都位于非洲大陆。嗯,除了香港:

这里需要注意的一点是,RIR 统计数据仅确定了 AFRINIC 向其分配 IP 块的 54 个国家/地区,但从 RDAP 收集的数据暗示了更广泛的传播。这表明这里正在进行相当活跃的 CIDR 区块交易。

另一个惊喜(至少对我来说)是向毛里求斯这个相对较小的国家进行了大量拨款。通常,我预计分配与人口大致成正比,尽管一个国家的经济权重在这里起着更大的作用:至少在 2014 年,毛里求斯在非洲排名第三。但话又说回来,AFRINIC 的总部设在毛里求斯……啊啊。

APNIC 的

毫不奇怪,APNIC 将中国列为拥有 IP 地址最多的国家/地区,其次是日本和韩国,前十名中的其他国家至少都在亚洲,尽管它们再次高度集中:中国、日本和韩国几乎占 APNIC 分配的所有 IP 地址的 75%:

阿林

ARIN 在此处分配的 IP 地址的地理分布仅来自 RIR 统计数据,因为 ARIN 提供的 RDAP 数据不包括国家/地区代码。与其他 RIR 一样,我们看到的分配远远超出了其假定的地理区域,当然,不出所料,主要的异常值是美国,占 ARIN 所有分配的 95% 以上:

  1. 🇺🇸 美国(1.59B 个IP,95.4% 的 ARIN,~37% 的所有 IP)
  2. 🇨🇦 加拿大 (68.2M, 4.1%)
  3. 🇵🇷 波多黎各 (757K)
  4. 🇨🇿 捷克共和国 (395K)
  5. 🇯🇲 牙买加 (222K)
  6. 🇧🇧 巴巴多斯 (168K)
  7. 🇧🇸 巴哈马 (138K)
  8. 🇬🇧 英国 (136K)
  9. 🇻🇮 美属维京群岛 (118K)
  10. 🇧🇲 百慕大 (108K)

LACNIC

与 ARIN 一样,LACNIC 的 RDAP 服务不提供国家/地区代码(尽管提供),因此此处的统计数据同样仅基于 RIR 统计数据:nic.br

  1. 🇧🇷 巴西(87.14M 个 IP,占 LACNIC 的 45.8%)
  2. 🇲🇽 墨西哥 (29.02M, 15.3%)
  3. 🇦🇷 阿根廷 (19.46M, 10.2%)
  4. 🇨🇴 哥伦比亚 (17.37M, 9.1%)
  5. 🇨🇱 智利 (10.03M, 5.3%)
  6. 🇻🇪 委内瑞拉 (6.71M, 3.5%)
  7. 🇵🇪 秘鲁 (3.24M, 1.7%)
  8. 🇪🇨 厄瓜多尔 (2.71M, 1.4%)
  9. 🇺🇾 乌拉圭 (2.44M, 1.3%)
  10. 🇨🇷 哥斯达黎加 (2.34M, 1.2%)

请注意,LACNIC 似乎是受区域限制最严格的注册机构,如果您愿意的话,它几乎保持在指定的边界内。也就是说,其他 RIR 向 LACNIC 进行的 IP 区块交易似乎较少。

成熟的 NCC

现在,我们冗余的欧洲 IP 网络协调中心是具有最广泛全球影响力的 RIR,负责全球 164 个国家/地区的分配:

  1. 🇩🇪 德国(130.75M IP,占 RIPE NCC 的 15.2%)
  2. 🇬🇧 英国 (130.48M, 15.2%)
  3. 🇫🇷 法国 (87.03M, 10.1%)
  4. 🇮🇹 意大利 (56.69M, 6.6%)
  5. 🇳🇱 荷兰 (48.7M, 5.7%)
  6. 🇷🇺 俄罗斯 (47.29M, 5.5%)
  7. 🇪🇸 西班牙 (33.9M, 3.9%)
  8. 🇸🇪 瑞典 (28.93M, 3.4%)
  9. 🇨🇭 瑞士 (25.2M, 2.9%)
  10. 🇵🇱 波兰 (20.35M, 2.4%)

按分配类型划分的分配

我查看的另一件事是不同 RIR 分配了哪些类型的网络块。此信息可在 RDAP 响应中找到,请记住,RDAP 很棒,因为它定义明确!例如,RFC9083 告诉我们:

type – 一个字符串,其中包含根据该 RIR 的注册模型对网络进行的特定 RIR 分类

哦,天哪,一根绳子。井。是的。因此,不同的 RIR 选择定义不同的字符串也就不足为奇了:

例如,请参阅 APNIC 对不同分配类型的解释;通常,“PA”代表“提供商可聚合”,而“PI”代表“独立于提供商”。

按类型划分的所有 22 个不同分配的完整分布如下所示:

这些数据有一个警告:JPNIC 的 RDAP 结果始终将“Allocation Type”字段设置为 。但是,让我们按 RIR 比较这些分配。null

为了帮助我们回答谁拥有 CIDR 的问题,将本地注册管理机构的分配与最终用户的分配分开可能是有意义的。遗憾的是,不同的 RIR 对这些 RIR 使用不同的类型(在上面的每张图片中以红色圈出),但实际上这是一个很难区分的地区。

例如,ARIN 的“DIRECT ALLOCATION”应该用于本地注册管理机构和 ISP/电信公司,但尚不清楚例如,可能为其 ATM 网络重新分配净块的银行是否被视为本地注册管理机构;就我们在这里的目的而言,他们是同一个所有者。哦,当然,RIPE NCC 的“传统”分配可能是也可能不是最终用户分配。谁知道呢。

分配大小

接下来,我查看了分配的 net blocks 有多大。我发现了 25 种不同的 CIDR 大小,其中 ~5K 分配为 /n < /16,~7.2K 分配为 /n > /24。大多数是 /24s、/22s 和 /23s,但当然还有 23 个 /8s、11 个 /9s,以及光谱两端不可忽略的异常值:

数据科学书告诉我,饼图很糟糕,所以下面是相同数据的帕累托图:

让我有点惊讶的是 /32 分配的显著数量 (1,387),但除此之外,/24 分配是迄今为止最常见的分配,这也反映在所有 RIR 的分配中——除了 LACNIC,它似乎更偏爱 /22。(您可以在此处查看每个 RIR 的帕累托图: AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC

为了方便起见,我还检查了 IPv6 分配大小(70 种不同的分配大小;22 个 CIDR /n < /32(252K 个分配),18 个 CIDR /n > /48(572 个分配),9 个 CIDR /n > /100(22 个分配)),其中 /24 也是最受欢迎的一个。当然,在 IPv6 中,/24 大约是 2 个十分 IP 地址,而不是 256 个,但没关系。

按网络名称划分

但我仍在寻找网络区块的实际所有者名称。RDAP(很像 )使用“网络名”标识子网,因此我们可以按分配频率以及分配给给定网络名的 IP 地址总数来计算这些子网。whois

每个 “网络名称” 可能与大量不同的自治系统 (AS) 编号相关联,而 “网络名称” 当然不一定具有很强的描述性或揭示性:要尝试将这些名称映射到实际的组织名称,您需要相当多的人为关联。

此外,有时您需要知道(或推断)不同的实体实际上是同一个实体:“Amazon Technologies Inc.”和“Amazon.com Inc.”显然是相关的,但被确定为“Level 3 Parent LLC”和“Century Link Communications”拥有的网络具有相同的父所有者(在本例中为 Lumen Technologies, Inc.)这一事实远非明显。8

按 AS 编号划分的分配

尝试通过将 IP 地址与 AS 编号相关联来映射数据(如上所述,主要通过 Team Cymru 的 IP 到 ASN 服务),我发现了大约 63K 个不同的 AS 编号:

(是的,这张图中突出显示的“斯塔克工业”是布赖恩·克雷布斯最近在不同的上下文中讨论的那个。我之所以提到它,只是因为它让我觉得这是一个非常科技兄弟的名字。

但观察到的 AS 频率是一个因素。如果我们统计给定 CIDR 的 IP 地址并按 AS 映射这些地址,则会出现不同的视图:

换句话说,我们发现自己是触摸大象的盲人之一——我们从不同的侧面得到不同的观点,却没有真正得到完整的视角。尝试将 AS 编号和网络名称组合在一起并手动将它们与实体相关联,我得出了拥有最多 IP 地址的顶级组织的粗略分布,这些地址占所有 IP 空间的很大一部分,并且至少在一定程度上回答了我们最初的问题。前十名(无论如何,按这个计数计算)是:

  1. 美国国防部(352M 个 IP 地址,占所有 IPv4 地址的 8.19%)
  2. 亚马逊(181M,4.21%)
  3. 中国电信 (112M, 2.61%)
  4. AT&T (111M, 2.59%)
  5. Verizon (101M,2.35%)
  6. 康卡斯特 (71M, 1.64%)
  7. Lumen Technologies (65M, 1.52%)
  8. Microsoft(59M,1.37%)
  9. 软银 (48M, 1.1%)
  10. 韩国电信 (46M, 1.08%)

这里需要指出的一点(除了 DoD 是一个明显的异类)是只有两家公司不是电信提供商:Amazon 和 Microsoft。所有其他公司实际上是 ISP 和 Telco。

总结

嗯,这是很多数据,都呈现出略有不同的观点。这些数据是否回答了我们关于谁拥有哪些 CIDR 的主要问题?只是在某种程度上,真的。整个练习有点令人沮丧,但以下是一些结论性发现:

首先,区分 “最终用户” 和 LIR 真的很难。Amazon 是否是 LIR,因为不同的客户通过 AWS 使用他们的 IP 空间?

我们还发现不同的 RIR 定义存在很多不一致之处,这使得数据难以关联,并且 RDAP 中的一些数据在单个 RIR 内不一致、有缺陷或不完整。我已经向不同的 RIR 报告了一些发现;一些发现已经得到解决,但总的来说,我认为这是一个有很大改进空间的领域。

另一件让我有点惊讶的事情是,区域互联网注册管理机构似乎比您想象的要少得多,因为区块被交易、转让或分配给其所在地区以外的实体。

但总的来说,根据我所看到的,看起来大约 30% 的 IP 地址只由少数组织管理,当然,国防部仍然拥有其中的大部分9

我们已经看到,除了 ISP/电信公司或 LIR(对他们来说拥有大部分 IP 空间似乎是合理的)之外,前十名中只有两家大型互联网公司。这两家公司也恰好控制着互联网或行业和市场的其他方面,这再次暗示了中心化的趋势。

最后,对 IPv6 进行相同的练习就没那么有趣了。它太多了,以至于交易 netblocks 等的考虑因素并不那么相关。IPv6 很无聊。这是一件好事。我真的很喜欢无聊 – 我们应该做更多这样的事。甚至可能在 2035 年之前。

Apt update : failed to fetch expkeysig abf5bd827bd9bf62 nginx signing key signing-key@nginx.com

apt update ,更新 nginx 时报错。 提示 Nginx 签名无效, 无法获取.

failed to fetch https://nginx.org/packages/mainline/debian/dists/bookworm/inrelease the following signatures were invalid: expkeysig abf5bd827bd9bf62 nginx signing key <signing-key@nginx.com>
解决处理:
  1. 导入 Nginx.org GPG 密钥
curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null

2. 验证密钥是否成功导入

gpg --dry-run --quiet --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

3. 导入 Nginx.org APT 存储库

bash 下执行以下 echo 命令 :

Mainline 存储库 、稳定存储库 二选一!

要导入 Nginx Mainline 存储库,请使用:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

或者,对于 Nginx 稳定存储库:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

ICANN终止OpenTLD(Freenom)认证 – 域名转移到Gandi

”人人都熟悉的名字“ — Freenom.com

已经使用了近十年,很好的一家,良心域名注册商,还是被遭到了毒打。Freenom以极低的价格提供域名注册,费用号称成本价,比如.NL 、.EU,还提供TK、CF、GA、GQ、ML 域名的免费注册。最早就是从免费的.TK 域名知道它的。

大约从2023年初开始,已经很久不能注册新域名了。之前看到说是,被Facebook母公司Meta , 在美国加利福尼亚州法院起诉 。被起诉后 Freenom 就由于技术原因新注册申请暂停,当前正在研究解决方案,希望尽快恢复运营。

2024年1月15日我还曾在Freenom续费域名,到2月初,发现域名已经无法续费了。2024/2/12收到了Gandi.net 的支持邮件,告知ICANN终止了OpenTLD(Freenom)的认证- 域名转移到Gandi:

Gandi Support: OpenTLD (Freenom) ICANN accreditation termination – Transfer to Gandi – Recover your domain

Dear registrant,
We are reaching out to you as the owner of the domain name as32.net which was registered with the registrar OpenTLD B․V․, trading as Freenom.
Following the termination of OpenTLD accreditation, ICANN has selected Gandi as the gaining registrar for the gTLD domain names previously managed by OpenTLD. You can find more information about this transfer on the following ICANN page:
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-en.
If you have not already recovered the management of this domain name at Gandi, please follow the link below. You will be able to import the domain name into your Gandi account if you already have one, or create a Gandi account to be able to manage your domain name.
Import your domain name
We kindly request your attention to the following points:
– Gandi does not provide proxy and privacy services. Consequently, your contact information has been sent to the registry. However in the Whois public database, personal data remain hidden in accordance with ICANN rules. Only the organisation name for legal persons, the state (if available) and the country of the owner contact are published. Email addresses of domain name contacts are anonymized.
– The expiration date of the domain name remains unchanged. You can verify the expiration date via your Gandi account and proceed with renewal if necessary.
Should you have any question, our support team will be delighted to help you:
https://helpdesk.gandi.net.
Thank you for your attention to this matter.
____________________________________________________________

about this transfer on the following ICANN page:
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-en.

请注意:下表列出了因注册服务机构的认证被 ICANN 终止后所致的批量转移事件。此外,批量转移日期将在终止日期之后。

Terminated RegistrarGaining RegistrarTermination Date
OpenTLD B.V. (IANA #1666)Gandi SAS (IANA #81)25 November 2023
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-zh

https://www.rayks.com/article/freenom-pending.html

2024 年 2 月 12 日,知名域名注册服务提供商 Freenom 通过其官方网站发布公告,表示 Freenom 及其相关公司已决定退出域名业务,包括注册机构的运营。


Freenom 公司已于 2023 年 3 月 9 日全面停止了新域名的注册业务,但未回收已注册域名且域名到期续费功能也保持开放状态,直到近期宣布“退出域名业务”决定后开始大量收回已注册域名。
Freenom 公司官方宣布内容译文及原文如下:
新闻声明
阿姆斯特丹,2024 年 2 月 12 日。Freenom 今天宣布已解决 Meta Platforms, Inc. Freenom 承认 Meta 在实施其知识产权和保护其用户免受欺诈和滥用方面的合法权益。
Freenom 及其相关公司也已独立决定退出域名业务,包括注册机构的运营。在 Freenom 结束其域名业务的同时,Freenom 将把 Meta 旗下公司视为可信赖的通知方,并将实施阻止列表,以应对未来的网络钓鱼、DNS 滥用和抢注行为。
如需进一步咨询,请联系:
Karin Versteeg
kversteeg@freenom.com
—————————————————原文如下—————————————————
Press Statement
Amsterdam, 12th of February 2024. Freenom today announced it has resolved the lawsuit brought by Meta Platforms, Inc. on confidential monetary and business Terms. Freenom recognizes Meta’s legitimate interest in enforcing its intellectual property rights and protecting its users from fraud and abuse.
Freenom and its related companies have also independently decided to exit the domain name business, including the operation of registries. While Freenom winds down its domain name business, Freenom will treat the Meta family of companies as a trusted notifier and will also implement a block list to address future phishing, DNS abuse, and cybersquatting.
For further inquiries, please contact:
Karin Versteeg
kversteeg@freenom.com
域名注册商 Freenom 宣布退出域名业务 大规模回收免费域名

https://www.rayks.com/article/freenom-pending.html

相关消息:

https://domainnamewire.com/2023/11/10/icann-terminates-opentld-famous-for-its-connection-to-tk-domains/

https://domainnamewire.com/2023/09/21/icann-sends-breach-notice-to-freenoms-accredited-domain-registrar/

https://www.icann.org/uploads/compliance_notice/attachment/1211/hedlund-to-zuurbier-20sep23.pdf

https://zhuanlan.zhihu.com/p/682465154

https://zhuanlan.zhihu.com/p/627211282

https://www.zhihu.com/question/591955285

https://www.zhihu.com/question/644205158

使用 update-alternatives 命令切换软件版本

update-alternatives 的功能,类似于在桌面系统上设置默认打开程序。

# update-alternatives --help
用法:update-alternatives [<选项> ...] <命令>

命令:
  --install <链接> <名称> <路径> <优先级>
    [--slave <链接> <名称> <路径>] ...
                           在系统中加入一组候选项。
  --remove <名称> <路径>   从 <名称> 替换组中去除 <路径> 项。
  --remove-all <名称>      从替换系统中删除 <名称> 替换组。
  --auto <名称>            将 <名称> 的主链接切换到自动模式。
  --display <名称>         显示关于 <名称> 替换组的信息。
  --query <名称>           机器可读版的 --display <名称>.
  --list <名称>            列出 <名称> 替换组中所有的可用候选项。
  --get-selections         列出主要候选项名称以及它们的状态。
  --set-selections         从标准输入中读入候选项的状态。
  --config <名称>          列出 <名称> 替换组中的可选项,并就使用其中
                           哪一个,征询用户的意见。
  --set <名称> <路径>      将 <路径> 设置为 <名称> 的候选项。
  --all                    对所有可选项一一调用 --config 命令。

<链接> 是指向 /etc/alternatives/<名称> 的符号链接。
    (如 /usr/bin/pager)
<名称> 是该链接替换组的主控名。
    (如 pager)
<路径> 是候选项目标文件的位置。
    (如 /usr/bin/less)
<优先级> 是一个整数,在自动模式下,这个数字越高的选项,其优先级也就越高。

选项:
  --altdir <目录>          改变候选项目录。
                             (默认是 /etc/alternatives)。
  --admindir <目录>        设置 statoverride 文件的目录。
                             (默认是 /var/lib/dpkg/alternatives)。
  --instdir <目录>         改变安装目录。
  --root <目录>            改变文件系统根目录。
  --log <文件>             改变日志文件。
  --force                  允许使用候选项链接替换文件。
  --skip-auto              在自动模式中跳过设置正确候选项的提示
                           (只与 --config 有关)
  --quiet                  安静模式,输出尽可能少的信息。
  --verbose                启用详细输出。
  --debug                  调试输出,信息更多。
  --help                   显示本帮助信息。
  --version                显示版本信息。

注册软件: update-alternatives –install

以jdk为例,安装了jdk以后,先要在update-alternatives工具中注册;

# update-alternatives --install /usr/bin/java java /opt/jdk1.8.0_91/bin/java 200
# update-alternatives --install /usr/bin/java java /opt/jdk1.8.0_111/bin/java 300

其中:

  • 第一个参数:--install表示向 update-alternatives 注册服务名。
  • 第二个参数:是注册最终地址,成功后将会把命令在这个固定的目的地址做真实命令的软链,以后管理就是管理这个软链;
  • 第三个参数:服务名,以后管理时以它为关联依据。
  • 第四个参数:被管理的命令绝对路径。
  • 第五个参数:优先级,数字越大优先级越高。

常用示例

显示程序的可替换信息:update-alternatives –display <名称>

 # 显示PHP程序的可替换信息
update-alternatives --display php

php - manual mode
  link best version is /usr/bin/php8.3
  link currently points to /usr/bin/php8.2
  link php is /usr/bin/php
  slave php.1.gz is /usr/share/man/man1/php.1.gz
/usr/bin/php8.2 - priority 82
  slave php.1.gz: /usr/share/man/man1/php8.2.1.gz
/usr/bin/php8.3 - priority 83
  slave php.1.gz: /usr/share/man/man1/php8.3.1.gz

注册添加程序的可替换信息:update-alternatives –install <名称>

# 设置PHP
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp74/bin/php 74
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp81/bin/php 81
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp82/bin/php 82

列出 程序替换组中所有的可用选项:update-alternatives –list <名称>

update-alternatives --list php

/usr/bin/php8.2
/usr/bin/php8.3 

交互式修改:update-alternatives –config <名称> 显示可用选项的列表,选择对应的索引确认。

#设置默认浏览器
update-alternatives --config www-browser 

There is 1 choice for the alternative www-browser (providing /usr/bin/www-browser).

  Selection    Path            Priority   Status
------------------------------------------------------------
* 0            /usr/bin/w3m     25        auto mode
  1            /usr/bin/w3m     25        manual mode

Press <enter> to keep the current choice[*], or type selection number:

#设置默认使用的php版本
update-alternatives --config php

There are 2 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.3   83        auto mode
* 1            /usr/bin/php8.2   82        manual mode
  2            /usr/bin/php8.3   83        manual mode

Press <enter> to keep the current choice[*], or type selection number: 1

删除替代方案

用 remove 去掉编辑器组中的微替代品:

update-alternatives --remove editor /usr/bin/micro

可以直接使用下面的全部清除:

update-alternatives --remove-all java

解决 apt-get update 从 packages.sury.org 更新 apache2 与 php 时签名无效的错误

apt-get update 显示错误,从 packages.sury.org 更新 apache2 与 php 时签名无效,如下显示:

错误:6 https://packages.sury.org/apache2 bookworm InRelease
  下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

错误:7 https://packages.sury.org/php bookworm InRelease
  下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

------------------------------------------------------------------

Err:6 https://packages.sury.org/apache2 bookworm InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

Err:7 https://packages.sury.org/php bookworm InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 校验数字签名时出错。此仓库未被更新,所以仍然使用此前的索引文件。GPG 错误:https://packages.sury.org/apache2 bookworm InRelease: 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 校验数字签名时出错。此仓库未被更新,所以仍然使用此前的索引文件。GPG 错误:https://packages.sury.org/php bookworm InRelease: 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 无法下载 https://packages.sury.org/apache2/dists/bookworm/InRelease 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 无法下载 https://packages.sury.org/php/dists/bookworm/InRelease 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 部分索引文件下载失败。如果忽略它们,那将转而使用旧的索引文件。

————————————————————————————————–

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/apache2 bookworm InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php bookworm InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Failed to fetch https://packages.sury.org/apache2/dists/bookworm/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Failed to fetch https://packages.sury.org/php/dists/bookworm/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Some index files failed to download. They have been ignored, or old ones used instead.

解决办法:

参考 packages.sury.org 站点 README.txt 文件的脚本。

apache2 https://packages.sury.org/apache2/README.txt
php https://packages.sury.org/php/README.txt

apache2

apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-apache2.gpg] https://packages.sury.org/apache2/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/apache2.list'
apt-get update

php

apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
apt-get update

【END】

使用 HttpRepl 浏览、测试 Web API

The HTTP Read-Eval-Print Loop (REPL) 

  • 一种轻量级跨平台命令行工具,在所有支持的 .NET Core 的位置都可得到支持。
  • 用于发出 HTTP 请求以测试 ASP.NET Core Web API(和非 ASP.NET Core web API)并查看其结果。
  • 可以在任何环境下测试托管的 web API,包括 localhost 和 Azure 应用服务。

安装:dotnet tool install -g Microsoft.dotnet-httprepl

(视频)使用 HttpRepl 浏览 Web API:

https://learn.microsoft.com/zh-cn/shows/beginners-series-to-web-apis/exploring-web-apis-with-the-httprepl-16-of-18–beginners-series-to-web-apis

使用 HttpRepl 测试 Web API

https://learn.microsoft.com/zh-cn/aspnet/core/web-api/http-repl/?view=aspnetcore-8.0&tabs=windows

HttpRepl:用于与 RESTful HTTP 服务交互的命令行工具

https://devblogs.microsoft.com/dotnet/httprepl-a-command-line-tool-for-interacting-with-restful-http-services/#configure-visual-studio-for-windows-to-launch-httprepl-on-f5

HttpRepl GitHub 存储库https://github.com/dotnet/HttpRepl

中国网络出口、海陆光缆相关汇总

中国运营商海陆光缆的布局、挑战与破局

https://www.eet-china.com/mp/a204489.html

海底光缆(下称“海缆”)和陆地光缆(下称“陆缆”),是当今全球网络通信的重要基础设施。

它们不仅代表一个国家的通信发展水平,还影响着科教能力、经济发展和民生福祉,甚至安全层面

既然海陆缆于一国而言具有如此重要的意义,那么,中国运营商在海外有哪些布局?当前面临着什么挑战?如何破局?


本期,笔者将带着这些问题,为您做一个分享。

█ 海陆缆简介

关于海陆缆的特点,笔者之前在《海缆通信 VS 陆缆通信》一文中作过详细介绍,总结起来,有以下四个方面。

● 带宽容量:一般而言,海缆的容量比陆缆更大。

● 网络时延:海缆与陆缆的时延各有千秋,取决于具体的物理路由。

● 运行稳定性:海缆要么正常,要么中断,修复起来慢;陆缆中断的情况较少,但抖动(倒换)可能较多。

● 市场价格:对于中长距离的国际传输,一般情况下陆缆的价格要高于海缆。

█ 我国海陆缆的特点

我国国际海陆缆发展的特点是:起步较晚,发展较快,瓶颈较多。

1、起步较晚

世界上第一条光缆,是 1988 年美国与英国、法国之间铺设的大西洋海底光缆(TAT-8),全长 6700 公里。

这条光缆含有 3 对光纤,每对的传输速率为 280 Mbps,中继站距离为 67 公里。大西洋海底光缆的建成,标志着海底光缆时代的到来。

我国直至 1993 年底,才开通第一条海底光缆——中日海底光缆。中日海底光缆从上海南汇至日本九州宫崎,全长 1252 公里,通信总容量达 7560 条通话电路。中日海底光缆的开通,使得当时中国国际通信能力增长 80% 以上,标志着中国从此向互联网进军。

中日海底光缆成功登陆,引用自互联网公开信息

2、发展较快

在国际海缆方面,根据中国信通院发布的信息,经过多年的建设,目前在中国大陆登陆的国际海缆共有 9 条,中国运营商在登陆海缆上现有带宽超过 40 Tbps 的带宽,并且这一数字还在不断增长,具体如下。

在中国大陆登陆的海缆(引用自中国信通院发布的《中国国际光缆互联互通白皮书》)

在跨境陆缆方面,中国更是取得了长足的进步。通过跨境陆缆,中国已经建成了连接周边国家、通达欧洲的陆地光缆网络架构,系统带宽超过 70 Tbps,具体如下。

中国跨境陆缆统计表(引用自中国信通院发布的《中国国际光缆互联互通白皮书》)

3、瓶颈较多

然而,尽管近年来中国运营商在国际海陆缆建设方面发展较快,但相比一些发达国家,仍然存在较大差距和诸多不足,具体有以下几个方面。

● “马六甲困境”

目前几乎所有从中国去往中东、欧洲或非洲地区的海缆,均需要途经马六甲海峡,由于某些因素,万一马六甲海峡局势有变化,这必然会影响中国与世界的通信,进而波及中国“一带一路”发展战略的推进。

图:中国海缆通信的“马六甲困境”

● 美国无法上岸

目前,中国运营商投资建设了一些在美国登陆的海缆,并拥有一定的带宽权益,例如 TPE、FASTER 和 NCP 等。而随着中国电信、中国联通的 “214 牌照”于 2021 年和 2022 年相继被美国吊销,导致中国运营商的海缆资源将无法在美国上岸,而面临被动局面。

注:“214 牌照”,是指根据美国通信法(1934 年版及 1996 年修订版)第 214 条规定,取得的 FCC 颁发的国际电信业务授权——在美国与外国之间提供国际公共运营商通信服务。

● 非洲存量为零

非洲作为中国“一带一路”战略的重要区域,聚集了大量的中资企业。这些企业背靠强大的祖国,在非洲投资、建设与生产,不少已经扎根非洲。然而,非洲相对落后的通信基础设施,将日益成为中资企业进一步发展的瓶颈。

据了解,当前非洲国家之间主要依靠海缆进行通信(陆缆资源发展落后),而可选的只有 SAT-3/WASC、EASSy 和 ACE 等寥寥数条由欧洲运营商主导建设的海缆,且价格昂贵。这客观上制约了中国运营商在当地的网络服务能力。

█ 未来动向

可喜的是,面对上述发展的困境,中国运营商背靠强大的祖国,在海陆缆发展方面进行了前瞻性的战略布局,并取得了重要积极的进展。

1.打通中巴陆缆——冲破“马六甲困境”

首先是中国电信于 2018 年率先开通中国-巴基斯坦首条跨境陆地光缆系统(下称“中巴光缆系统”),这标志着中巴两国通信网络基础设施互联互通建设取得重大进展。

中巴光缆系统,引用自《中国电信建成开通中国-巴基斯坦首条跨境陆地光缆》

中巴光缆系统只是一个开始,随着中巴两国战略合作的进一步深入,相信在不久的将来,中巴光缆将有望从伊斯兰堡延伸至港口城市卡拉奇,并与卡拉奇海缆对接。如此一来,海缆通信的“马六甲困境”将迎刃而解,对中国的战略意义不言而喻。

中巴光缆系统(图中橙色实线),及其延伸段(图中橙色虚线)

2.投资建设 2Africa 海缆——强化非洲网络覆盖能力

非洲人口众多,市场广阔,发展潜力巨大,是中国“一带一路”发展战略的重要阵地,然而,通信基础设施落后也是许多非洲国家在经济发展中绕不开的问题。

为了更好地助力中资企业出海,增强中国在非洲乃至全球的影响力,中国移动于 2020 年,投资建设 2Africa 海缆系统。

2Africa 海缆(含中东 PEARLS 分支)全长45000 公里,预计于 2023 年末建成投产,届时将是世界上人最长的海底光缆系统,覆盖超过全球超过三分之一的人口。

2Africa 海缆,引用自《2Africa to become world’s longest subsea cable post Arabian, Asian expansion》

3.积极拓展中越、中泰、中缅和中老等方向的对接

中国人西南邻国众多,与中国的经济、政治和文化联系紧密。在“睦邻友好、和平发展”方针下,近年来中国运营商正积极与越南、泰国、缅甸和老挝等国进行陆网方面的合作。

根据公开资料显示,目前中国电信已建成中老泰陆缆系统,中国移动也已打通中越、中泰等方向的陆缆通信信道。

向西南方向的陆缆拓展,一方面加强了中国与东南亚国家的联系,另一方面也是为信息出海方向提供更多的选择性。

中国电信中老泰陆缆,引用自《中国电信成功开通中老泰陆缆》

信息化是智能制造的前提,而海陆缆则是信息化的重要基础设施。伴随着中国“一带一路”发展战略的推进,接下来我们将在全球海陆缆建设中看到更多的中国身影和中国元素。

https://www.submarinenetworks.com/zh/zx/hll/20220512

中国移动国际、中国联通国际等携手华海通信 共同宣布建设SEA-H2X国际海缆 使能亚洲互联新时代

2022年5月12日,【天津,中国】—— 中国移动国际有限公司(CMI)、中国联通国际有限公司(CUG)、Converge Information and Communications Technology Solutions, Inc.(Converge)以及PPTEL SEA H2X Sdn. Bhd(PPTEL SEA H2X)近日宣布计划合作铺设SEA-H2X国际海缆系统,为亚洲及全球数字化转型扩容提速。SEA-H2X将连接中国海南、中国香港、菲律宾、泰国、马来西亚及新加坡等地,进一步可延伸至越南、柬埔寨以及印度尼西亚,建成后将极大提升亚洲区域内的网络连接性。SEA-H2X由国际海缆联盟成员共同运营,由华海通信技术有限公司(HMN Tech)承建。

SEA-H2X国际海缆全长将超过5,000公里,采用高规格光纤布线,其设计容量高达160 Tbps,新加坡和中国香港两地间线路将采用至少8对光纤部署。SEA-H2X海缆计划于2024年投入使用,届时将有效满足亚洲地区对网络带宽和高速连接日益增长的需求,助力共建5G演进的网络新生态,为全球数字经济蓬勃发展提供更大助推力。

SEA-H2X海缆系统由华海通信提供海缆系统的端到端解决方案,包含海缆系统及水上水下设备的设计、生产、建设和施工。该系统应用了先进的 Open Cable技术,使其可灵活地选择最优的海底线路终端设备(SLTE),达到传输能力最大化。此外,该项目还应用了全球领先的海底线路分支器(BU)和海底线路动态光分插复用器(ROADM)将为SEA-H2X海缆系统提供超高的可靠性和光电线路的高灵活性。

路由图:

https://www.submarinenetworks.com/zh/zx/hll/peace-20180829

https://www.submarinenetworks.com/zh/zx/hll/20211020

https://www.submarinenetworks.com/zh/zx/hll/2018102201

PEACE国际海缆网络系统有限公司(亨通集团子公司)和华为海洋网络有限公司今日联合宣布,PEACE海缆项目进入海缆和设备生产环节。该海缆项目全程12,000公里,将连接亚洲、非洲和欧洲,并计划在2020年第一季度提供商用服务。


https://www.submarinenetworks.com/en/stations/asia/china

China

现在有以下海底电缆登陆中国大陆:

通往美国的电缆:

  • China-US CN (retired)
  • TPE
  • NCP

连接亚洲的电缆:

  • APCN-2
  • APG
  • EAC-C2C
  • SJC
  • SJC2 (2021)
  • TSE-1
  • Xiamen-Jinmen
  • Hainan to Hong Kong Express (H2HE)

通往非洲和欧洲的电缆:

  • FLAG Europe-Asia
  • SMW3

这些电缆降落在中国的 9 个海底电缆登陆站。

中国电信拥有三个光缆登陆站,包括

中国联通拥有四个电缆登陆站,包括:

中国移动拥有两个电缆登陆站:

  • Lingang Cable Landing Station for NCP and SJC2;
  • Wenchang Cable Landing Station for Hainan to Hong Kong Express (H2HE)

使用Certbot生成Let’s Encrypt证书,为OpenLiteSpeed 配置 SSL

使用 Let’s Encrypt 快速安装 SSL

手动certbot ,单独注册证书,最快获取Let’s Encrypt SSL证书的方式。。。

设置,先安装certbot

sudo apt-get update
sudo apt-get install certbot -y

以非交互式申请证书:

如要申请证书:example.com

certbot certonly --non-interactive --agree-tos -m demo@gmail.com --webroot -w /var/www/html -d example.com

要同时申请证书,并且:example.comwww.example.com

certbot certonly --non-interactive --agree-tos -m demo@gmail.com --webroot -w /var/www/html -d example.com -d www.example.com

OpenLiteSpeed 下的 SSL设置

  • 1. 如果我们只有一个证书,我们可以在侦听器级别设置它。

导航到 OpenLiteSpeed > Web 控制台> 侦听器> SSL > SSL 私钥和证书
设置以下值:

  • 私钥文件/etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem
  • 证书文件/etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem

单击“保存”,然后执行“平滑重启”。

  • 2. 配置多个 SSL

虚拟主机中的SSL证书将覆盖侦听器,因此我们只需将证书添加到每个域的虚拟主机即可。

导航到 OpenLiteSpeed > Web 控制台>虚拟主机>您的虚拟主机> SSL > SSL 私钥和证书
设置以下值:

  • 私钥文件/etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem
  • 证书文件/etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem

单击“保存”,然后执行平滑重启”。