译文:iOS IPV6审核指导

这个帖子讨论我们在App审核中遇到的一些常见的网络问题

并不是所有的审核被拒都和IPV6有关

App审核被拒你通常收到下面的提示

·你的App失败了,可能是登陆失败或者其他请求失败

·他是在IPV6-Only(纯IPV6环境)下测试

这个并不代表了你的应用审核失败和网络有着特殊的联系。有很多原因会导致在你的工作环境是正常的但是在App审核的时候表现的不正常。在苹果的文档QA1724How to reproduce bugs reported against App Store submissions描述了如何一步步的解决这个问题。

App在纯IPV6环境下审核

App在纯的IPV6网络环境下审核,但是这个网络是支持NAT64/DNS64的。你可以测试你的App在一个相近的网络环境下,比如一个基于NAT64/DNS64的网络共享环境。FAQ#1 Supporting IPv6-only Networks张贴了如何设置的指导。你必须在进行下一步之前先测试你的网络。

你所测试的网络并不和App审核时所用的网络一致。后面的章节会讨论到一些潜在的问题。

检查所有服务

当你升级完你的App支持IPV6以后,非常重要的一点就是考虑所有服务是不是都是可以访问的。这个可能不太好评估。一些App可能由于不同的功能实现获取了很多不同的服务(比如核心功能,次级功能,广告,分析等等)。此外,这可能不是很容易找到所有服务,比如:

服务的名字可能被隐藏在库代码中

服务的名字可能通过其他的网络请求反馈给你的App

对于HTTP和HTTPS,你的App可能开启一个对话服务,该服务被重定向到另一个服务。

DNS CNAME records 意味着可能服务有很多别名

一个非常简单方法就可以知道你App所用到所有服务,请看CFNetwork diagnostic log

确保打开你的网络诊断日志

在正常的情况下运行你的App

获取并过滤你的日志,来得到一个服务列表

重要:如果你的App运用的是高级网络API(任何基于CFSocketStream,包括了NSURLSession和NSURLConnection),这样是非常有效的方式。如果你使用的是低级的网络API(如BSD Sockets),他可能不会显示任何网络的行为,你必须手动的去检查这些代码。

IPV6连接性

这篇文章 Networking Overview中说道:

请注意,不像你的服务供应商的部署的DAT64/DNS64网络,网络共享的测试环境,总是会生成一个同步的IPV6地址,它并不能访问外部的纯IPv6服务器。

App审核的网络,和那些提供IPV6到IPV6访问的供应商部署的是一样。因此,如果你的服务器支持IPV6访问的话,那你的App就可以直接可以建立对话,不需要进行NAT64的转换。

总的来说,这是一件好事,但是如果你的服务器声称支持IPV6,但是IPV6又不可用,可能是下面几种情况导致

DNS名字是错误的

DNS是正确的,但是并没有监听IPV6

开启了监听IPV6的服务,但是通过IPV6的请求失败

接下来的章节我们会依次讨论这些点

IPV6的DNS问题

检查IPV6连接性第一步要做检查你的DNS是不是对你的域名做出正确的解析。你可以使用dig命令行,下面是IPV6正常连接的一种情形

注意:dig是访问DNS域名服务器一个比较方便的工具。它并不是访问系统的DNS解析,而是直接访问DNS服务器。在这些例子中我使用了+nocmd和+nostats 参数来最小化文本输出,参数AAAA是来询问IPV6地址记录

正如你所看到的。服务器返回了一个NOERROR的状态(第三行)而且,Answer Section包含了一个IPV6的地址。这样表示服务器支持IPV6。

相反,如果没有显示当AAAA记录不存在的时候,会显示下面的内容


注意,状态还是NOERROR,但是却没有Answer Section。这表示服务器仅支持IPV4。如果是这种情况,你可以跳过下面的一些章节(直接跳到常见DNS问题章节),因为你的所有连接总是会通过NAT64转化。

但是如果你出现了这种情况



这种情况状态是SERVFAIL,这表示你的DNS服务器是有问题的而不是缺少AAAA这条记录。如果你的DNS服务器返回这条错误状态,可能是由于DNS64/NAT64网络导致的。

注意:在DNS64文中的Section 5.1.2 of RFC 6147,提到一个NAT64/DNS64网关,对待SERVFAIL需要和当你请求AAAA记录返回NOERROR是同等对待,但是苹果审核的网关目前没有执行这个要求。

另外一种情况


同样,关键的信息在第三行,NXDOMAIN的状态表示并没有这个名字的任何形式的记录。照理来说你应该是看不到这种情况的,因为服务器必须含有一个IPV4的地址记录。一些DNS服务器尽管有一个有效的A的记录,但是被询问到是否有AAAA记录的时候就会返回这个错误。这是个Bug就好像你的DNS服务器会导致IPV6的客户端产生问题,是因为DNS64/NAT64的网关需要在DNS服务器的存在相应的关键字:在查询AAAA返回一个NXDOMAIN的结果,意味着也没有A这样的记录,因此服务器名是无效的。

IPV6监听

如果你的服务器表面能支持IPV6,那么确保监听从DNS服务器上返回的IPV6地址。如果他是HTTP或者HTTPS的Web服务器,那么有很多基于Web的工具去测试它(比如: ipv6-test.com)。如果是一些其他类型的服务,那么你需要在一个原生的IPV6网络中去测试。

注意:当你测试一个Web服务器的时候,你必须确保你知道你的服务器可以通过HTTP/HTTPS访问,并且遵循正确的协议。

IPv6服务错误

这可能尽管你的服务器正确的用IPV6正确搭建了,但是通过IPV6访问却是失败的。如果你能获取到服务器的log信息,你就可以一步步去调试这些错误。如果你获取不到这些信息,那你必须在原生的IPV6网络中去测试。

常见的DNS问题

要想DNS64/NAT64正常工作,你的DNS服务器必须正确的搭建。一些很小的DNS服务器配置错误,就会导致在App的审核网络中,某些情况下出现错误,但是在其他的一些网络中不出现,比如你自己搭建的网络共享的测试环境。

这里有一些基于Internetde 用来测试DNS的。很多工具都是基于来自The Internet Foundation In SwedenDNSCheck code。如果你能下载并且运行这些代码最好,当然你可以运用这些在线工具来测试online tool

当你在检查DNS的时候,请注意下面的几点

DNS别名(CNAME记录)

域名和区域

下面的章节会详细的讲述这些点

正如前面提到的,DNS允许CNAME记录多个别名。如果你连接的名字是一个DNS的别名,而且资源和目标名字在不同的区域,你必须单独一个个去检查。你同样可以用dig来找到DNS的别名。举个例子,下面的内容显示了ftp.microsoft.com其实是ftp.microsoft.akadns.net的CNAME,那么他就会依次显示ftp.microsoft.akadns.net. 然后显示134.170.188.232。而另一个www.example.com就会直接显示93.184.216.34。

在ftp.microsoft.com的例子中,DNS的别名意味着你必须连接microsoft.com.的域名和akadns.net.的域名

域名和区域

一些DNS检查工具不会让你输入任意一个域名,相反的,他们会让你输入一个域名的顶部区域。比如:你不能检查www.example.com,但是你可以检查example.com。你可以通过SOA的方式,发现这个这个域名的头部。如果你没有发现这个域名的SOA记录,那么会从域名最前的一个标签,然后继续查找,直到找到为止。下面的内容展示了如果使用dig命令:


如果你知道该域名的头部,那么你可以使用任意的DNS检查工具。下面的例子,是我在我Mac电脑上运行DNSCheck open source,使用dnscheck命令行跑的检查DNS


注意,跑这个dnscheck并不是很简单,如果你只要测试少量的域名,你可以用这个更简单工具IIS’s online tool

著名的前缀

一些开发者尝试在IPV4地址上加一些比较知名的前缀合成一个IPV6的地址,这在很多情况下是不行的。你需要使用getaddrinfo或者一些更高级的API去获取这些地址,具体你可以参考Use System APIs to Synthesize IPv6 Addresses。如果你想知道更多,请关注Supporting IPv6-only NetworksFAQ #4里面的内容。

谢谢!

推荐阅读更多精彩内容