Browsed by
Tag: ipv6

两起投诉

两起投诉

今天一大早就进行了两起投诉,响应很快,结果很满意。

投诉1:深圳电信光纤改造

在以前的一篇文章中吐槽了深圳电信的网络,后来恰逢深圳电信年末大优惠,再加上比较了其他两家运营商的宽带网络,最后还是选择了电信的光纤改造(费用理所当然地也上升了)。改造后的网络确实快了很多,而且一根光纤搞定上网、IPTV 和电话,实际上整个布线都比以前清爽了,这个还是可以给电信点个赞的!

然而发现了一个不太好的地方。光猫默认居然是一个内网地址!内网地址,能相信吗? 感觉深圳电信默认将光纤网用户划入一个大局域网。平时如果仅仅是上网就没有任何影响,但是像我这样需要和外部客户互相通信的情况,就会受影响,客户无法访问我的网络资源。以前ADSL没有这个问题,都是默认外网地址。

我个人感觉是因为电信的IPv4地址池可能比较紧张,因此采用了局域网方式组网。可以理解这是不得不为的困窘措施,未来如果广泛部署IPv6,就不会有地址问题。考虑到ADSL能给公网地址,难道我要退回去吗?实在太让人纠结了。 思考再三,于是拨打 10000 号电话进行投诉,说明了目前的情况以及需要外网地址的原因。

客服小妹的服务态度非常之好,转到相关技术处理人员后,非常干脆地就修改了配置,重启光猫之后获得了外网地址。给深圳电信的客服人员点赞!

投诉2: outlook系列服务器拒接邮件

这实际上是老问题了,有我们本身配置的问题,也有SPF设置方面的问题。修改了这些配置后,公司服务器向Gmail、Yahoo等邮箱发送email都没有遇到问题,唯独向outlook系列(包括hotmail等)服务器发邮件时,总是被拒接,原因也很简单,直接将我们的IP地址屏蔽了,信息如下:

Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [xxx.xxx.xxx.xxx] weren't sent. Please contact your Internet service provider since part of their network is on our block list (AS3140).

我们是良民,没干什么坏事啊,怎么就拉黑了呢? 一怒之下,找到以下地址递交资料进行投诉:
https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&ccsid=636554612673022658

很快收到了回复,outlook确认了相关信息,并承诺48小时之内将我们从名单中删除。

今天天气晴朗,阳光明媚!

网站启用IPv6应注意的事项

网站启用IPv6应注意的事项

网站支持IPv6的步骤比较简单,基本上目前常用的软件,例如Apache、Postfix、dovecot等,都已经支持IPv4和IPv6双栈,只要服务商的设备提供IPv4和IPv6连接,这些软件本身无需为IPv6做特别配置。

需要注意的是服务商处的DNS配置。如果DNS配置不全面,某些服务器在鉴权时会拒绝接受来自IPv6地址的消息。例如gmail服务器在收到 email 消息时,会鉴定DNS和IPv6地址是否匹配,如果不匹配,则视为垃圾邮件直接拒绝,可以看到如下错误警示:

Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication.

下面以Linode中的配置做简单介绍(对DO而言也基本如此)。假设IPv4地址是“1.2.3.4”,IPv6地址是“1:2:3:4::5:6”,域名是“demo.com”。

Reverse DNS

Linode 为每个节点分配的DNS名默认是类似的成员名,例如“1234.members.linode.com”。在 Linux 系统 ping 域名”demo.com”时,首先显示的是”1234.members.linode.com”,然后才是跳转到”demo.com”。某些服务应用会认为是PTR错误。在linode中需要设置“ reverse DNS”记录,将节点的DNS名直接指定为“demo.com”。

具体措施请参考linode的在线文档

如果同时支持IPv4和IPv6,上述文档里指导的操作需要单独操作两次,分别指定IPv4地址和IPv6地址。

MX 记录

另外一个需要注意的是 MX 记录,即邮件服务器记录。如果我们将 MX 记录设置为“mail.demo.com”,那么在DNS的A和AAAA记录中,要分别对“mail.demo.com”设置IPv4和IPv6地址,例如以下DNS记录结果:

mail.demo.com. 300 IN AAAA 1:2:3:4::5:6
mail.demo.com. 300 IN A 1.2.3.4

仅仅指定一个地址,对端有可能以域名和地址不匹配为由拒绝消息请求。

TTL

Linode 默认的TTL是3600秒,建议修改为300秒。TTL 太长太短都不好,要根据自己的实际情况调整,以方便自己网络部署、同时又不增加太多网络负担为准则。

Pi打开IPv6

Pi打开IPv6

默认已经安装了IPv6协议栈,但是没有打开IPv6功能,这点比较奇怪。不过打开IPv6功能也不复杂,一行命令即可:

sudo modprobe ipv6
6to4 tunnel

6to4 tunnel

今天无意中发现,居然不用翻墙就能打开google和gmail,这简直太不科学了,我朝气象从此焕然一新?

本着“怀着最大的恶意揣测他人”的精神,我对此充满疑虑。于是拉出wireshark仔细dig了一下,发现了IPv6数据包,竟然是通过IPv6访问google和gmail!墙没有封锁IPv6,这实在是个惊奇的发现。

难道电信已经开始部署IPv6网络了吗?对此同样充满疑虑。但是有一点是肯定的:最近买的路由器是支持IPv6的。进入路由器管理界面,发现电信仍然是分配IPv4地址,但是在路由器IPv6设置项中,配置了“自动检测IPv6类型”,检测结果是“6to4 tunnel”,而且配置了IPv6地址。

看起来电信的确升级了网络,但是仍然没有真正部署IPv6,还在半遮半掩中,并且猥琐地限速了。有“6to4 tunnel”也还好,至少能访问外部IPv6的服务器地址。google和gmail等都部署了IPv6,因此可以通过IPv6来访问这些服务。而对于没有部署IPv6的服务,例如twitter之流等,依然还是无法访问。

不管怎样,这已经是向前迈进了一步。真心希望步子能迈得更大些!

2016-03-10 更新:好吧,我承认我还是图样了。

嵌入式HTTP服务器设计

嵌入式HTTP服务器设计

定义

所谓“嵌入式HTTP服务器”包含这么几个意思:

(1)TA首先是微型的,不能太庞大。往往成为其他应用程序的一个组成部分,提供HTTP接口(包括RESTful接口)或者HTTP服务(例如WWW服务)。

(2)功能有欠缺,不是全功能服务器。比如,肯定不能像Apache、Nginx这样提供全面的HTTP支持。只能提供一个最小化的、需要定制化的功能集。

现状

在miniSIPServer中,我们以前采用mongoose这个轻量级http服务器来提供web接口。mongoose基本符合要求,但也很难让人感觉满意。主要存在以下一些问题:

(1)代码凌乱。是的,这个问题比较严重。实际上我们花了不少时间来清理TA的代码,但是效果不太好。TA的实现方式有不少问题,各逻辑层次之间解耦不充分,因此在编写应用层代码(尤其是ajax接口代码)时,不得不大量重复使用一些要求的宏定义,造成代码繁杂紊乱。

(2)定位不清晰。如果单纯定位为嵌入式服务器,可能mongoose的发展会好很多。但是我们看到,ta的代码之所以凌乱,有一个重要原因就在于:试图成为一个全功能集的http服务器。大量功能集堆积在一起,又没有处理好模块关系,结果就和意大利面一样绞成一团。

(3)原维护者似乎已经放弃这个产品。从代码库看,更新不是很频繁,缺乏关注。后续一些问题看不到解决的希望。在具体实现时,不得不小心翼翼地规避一些问题。

(4)IPv6支持不足,尤其不能适应IPv4和IPv6混合组网的情况。

新版的miniSIPServer设计中彻底抛开mongoose代码,重新实现自己的嵌入式HTTP服务。从效果看很不错:不考虑服务器自身的代码,仅仅看应用层的代码,就从原来近7K行,直接砍到了3K行。

新设计

当然,设计一个Apache或者Nginx是很复杂而且艰难的事,但设计一个嵌入式HTTP服务器的确很容易。简单来讲只有以下几个步骤而已:(1)打开TCP端口;(2)接受客户端连接;(3)收客户端的HTTP请求;(4)返回HTTP响应消息;(5)关闭TCP连接。

TCP网络编程是通用的,windows平台可以用IOCP,linux平台可以用epoll等。MSS作为SIP服务器,早就封装好了底层的通信库,因此仅仅需要关注步骤(3)和(4),读一读HTTP协议,根据HTTP的要求进行相应处理即可。

HTTP协议

最新的HTTP协议已经定义到HTTP/2.0,但现网大部分都还是HTTP/1.1,另外考虑到2.0主要是在SPDY以及加密等方面的修改,而这些对嵌入式HTTP设计而言不是很必要的,因此支持HTTP/1.1就好。

原HTTP协议定义在RFC2616,目前已经修改为多个RFC文档共同定义:RFC7230~RFC7235。实际上我们只需要关注前三个RFC文档:

  • RFC7230 “Message Syntax and Routing”。这是最基础的协议。定义了HTTP的基本交互模式,基本消息结构等。
  • RFC7231 “Semantics and Content”,定义了HTTP消息语法,包括RequestLine以及各Header等定义。SIP的语法就是基于这类定义。
  • RFC7232 “Conditional Requests”。主要是考虑一些有条件的请求及响应。最普遍的就是重复请求网页时,可以判断是否需要每次都返回内容,也可以要求客户端直接使用cache内容,节省网络流量,节约处理能力。

HTTP请求

与SIP的startLine是完全一致的,由method、requestTarget以及HTTP协议号三部分组成。method有多种,例如GET、POST、PUT、DELETE等。我们仅仅支持GET即可。

在请求消息的各项Header(头域)中,我们仅关心以下两个Header:

  • “Cookie”头域。用来传递Cookie参数。在web管理系统中,我们需要设置cookie确保用户登录系统后能继续使用各项管理界面。而没有cookie或者设置不正确的用户,将被视为非法用户。
  • “If-Modified-Since”头域。这是个非常有必要的域。一旦服务器发现客户端请求的内容没有变更,可以直接返回304响应,要求客户端直接用以前的结果就好。

HTTP响应

响应消息和SIP一样,也是定义1xx~6xx。实际设计中我们仅需要关心1xx、2xx、3xx以及4xx即可。响应消息没什么好说的,无非就是各种ContentType等,读取文件,通过TCP连接发给客户端即可。

与SIP比较而言,HTTP最大的特点是无状态。一个“请求-响应”即构成了一个完整的HTTP动作过程。因此HTTP可以利用LVS、HAProxy等技术支持大规模并发。而SIP受限于对话状态,多个“请求-响应”之间是可以关联的(例如INVITE和reINVITE),只能通过ALG、Proxy等呼叫分发来支持大规模的应用。

HTTP路由

具体内部实现时,采用action模式,根据HTTP请求的URL进行索引,用URL对应action即可。服务器本身可以设置一些过滤接口,也可以向应用层提供action接口,由应用层决定各URL对应的处理过程。这点在处理AJAX请求或者提供RESTful接口时尤其有用。

其他

我们的设计目前只支持HTTP。对于HTTPS,理论上而言也不是很困难,无非就是加载CA文件,在TCP建立时进行TLS/SSL鉴权,后续处理与HTTP没有差别。

另外就是安全防护问题,例如防DDOS攻击等,我们没有考虑这方面。虽然应用层可以利用过滤接口或者action接口进行一定程度的防护,但主要的保护依赖于边界网关,毕竟嵌入式HTTP服务器只是用来方便设备管理和配置,不是提供通用HTTP服务的。