delphij's Chaos选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……

Networking

共 64 篇文章。

postfix 的 SNI 支持与 gmail 的兼容问题

• Networking

今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时，我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for 
  gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
  (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
  alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
  (prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
  relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
  delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK  XXXXXXXXXX
  XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)
阅读全文… ( 本文约 1916 字，阅读大致需要 4 分钟 )

TCP 协议合订本出了

• Networking

我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议，其主体定义距今已经超过 40 年了（当然如果细究下去的话，第一份正式的文档是 RFC 675，而 RFC 793 本身也是针对一年前的 RFC 761 的修正，不过大部分实现者使用的基础依然是 RFC 793）。

阅读全文… ( 本文约 366 字，阅读大致需要 1 分钟 )

重建了 IPv6 隧道

• Networking

之前 提到我换了一家ISP。这家ISP目前尚未提供IPv6服务，因此想要用IPv6的话就需要自己动手。此前也有一些其他朋友问过我关于为什么一定要有 IPv6，毕竟 狼来了 的故事已经讲了这么多年，而且 十几年前 IPv4 的中央地址池其实就已经用完了，只是在工业界抱残守缺^H^H^H^H食古不化^H^H^H^H我也不知道该管这种行为叫什么，总之苟延残喘了十几年依然没有把服务迁移到 IPv6 上去，所以目前用 IPv6 往往也只是满足一下一些技术宅的恶趣味，例如看 kame.net 那只能动的海龟之类。

当然，我自己用 IPv6 有一些更加现实的动力，比如我的一些服务是只在 IPv6 上提供的，这样做可以把那些做的不好的客户端直接排除在外，有点类似于在当年我把网站的 TLSv1.2 和更早版本的 TLS/SSL 支持全都砍掉一样。

话说回来，由于新的 ISP 出于一些我不理解的原因死活不愿意支持 ping （唯一可能的解释是，这样做会导致扫描起来容易不少，毕竟扫描 IPv4 地址段比扫描 IPv6 地址段要容易太多了，但安全不能建立在别人不知道的基础上，anyway，打电话、开票之后未能解决该问题），而大河的隧道服务又要求必须可以 ping 到终点，于是陷入了死循环。

阅读全文… ( 本文约 3169 字，阅读大致需要 7 分钟 )

启用 SPDY

• Networking

之前 Frank 同学提到了这个问题，所以今天花了些时间来配置。 nginx 对 SPDY 的支持是一项比较新的特性，只有在 1.3.x 版本以上才支持。FreeBSD 的 nginx-devel 默认并不启用 SPDY，需要在 make config 的阶段启用。

阅读全文… ( 本文约 131 字，阅读大致需要 1 分钟 )

SMB协议 vs TCP的延迟ACK特性

• Networking

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

  • 客户端 (SMB Redirector) 如果启用了 security signature，则必须等待命令处理完成才会发出下一条SMB；
  • 服务器端如果启用了延迟ACK，则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

参与评论

世界IPv6日

• Networking

2011年6月8日是 Internet Society 倡导的世界 IPv6 日，许多著名的互联网公司都将在这一天测试全面开放 IPv6 访问；中国地区的 IPv6 日网站可以在 这里 找到。

WORLD IPV6 DAY is 8 June 2011 - The Future is Forever

阅读全文… ( 本文约 122 字，阅读大致需要 1 分钟 )

IPv4终于快用完了

• Networking

在很久很久以前就有人提出IPv4将要用完的事情，然而当时IPv4地址空间还很充裕，而且NAT还没有非常广泛地使用。于是这事说着说着就变成了一个狼来了的故事，不停地有人嚷嚷IPv4地址要用完了，而这个用完的日期则在600天、400天和300天附近的时候反复来回地拉锯了很久。

和狼来了那个故事稍微不太一样的是，喊狼来了的那些人，例如大的IPv6 ISP和运营商已经早早做好了准备，而那些把这故事当做狼来了而毫无警惕的人则只好手忙脚乱地应付了。

阿宅的一大恶趣味是喜欢仅仅因为"Because we can"而去做一些事情，我也是。我自己的网站的第一个DNS AAAA记录是2007年7月31日创建的，而FreeBSDChina.org于2007年8月4日也已经开始在IPv6上提供服务。由于当时条件所限，在当时我能够使用的唯一的测试手段是登录到一台位于北美的有双栈支持的测试服务器来进行测试。到了北美以后，因为这里的住户 IP 地址是很少发生变化的，我开始在家搭建 IPv6 路由，到后来在北美地区托管了一台服务器，基本上一直都是以双栈的方式接入Internet了。目前，我拥有两个/48的IPv6地址段和两个/64的IPv6地址段。

时间过得很快。今年年初的时候我看到了一个报道说 IPv4 地址大约还剩不到1年了，于是开始关注相关的报道。根据 Hurricane Electric 的估算，今天距离 IPv4 中央地址池的地址耗尽还有大约 47 天。中央地址池的耗尽对最终用户并不会产生立即而直接的影响（总有各种各样的办法来减少IP地址的占用，大企业或者ISP可以用NAT，双层甚至三层NAT等技术来减少实际使用的IP，等等），但是无论如何，我们之前所熟悉的那个互联网的日子已经所剩不多了。

阅读全文… ( 本文约 1547 字，阅读大致需要 4 分钟 )

用 OpenVPN 提供 IPv6 服务

• Networking

有时，会有需要接入远程的 IPv6 网络。例如，办公或网吧等环境可能不提供 IPv6 接入的条件，或者需要接入更高安全级别的网络等等。

使用 OpenVPN 提供 IPv6 服务需要的条件包括：

阅读全文… ( 本文约 557 字，阅读大致需要 2 分钟 )
搜索文章… (按 ESC 退出)