Windows network connectivity check domains

[kabegoe]

Fix for #1386. As far as I investigated, there are no references that support putting the domains into private list.

Ref: https://learn.microsoft.com/en-US/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network

[rootmelo92118]

Thanks for your contribution!

[IceCodeNew]

我觉得合得太着急了。可以先 git blame 看看当初引入这个域名的人怎么想。

@database64128 #247 这个 pr 里你引入了其中一个域名。想请你看看这次把这个域名从 private 里移出去是否合理。

[IceCodeNew]

@Loyalsoldier #610
Loyalsoldier/v2ray-rules-dat#136

[rootmelo92118]

我觉得合得太着急了。可以先 git blame 看看当初引入这个域名的人怎么想。

@database64128 #247 这个 pr 里你引入了其中一个域名。想请你看看这次把这个域名从 private 里移出去是否合理。

依據這篇文章的描述，我認為應該回滾這個PR
https://cloud.tencent.com/developer/article/2055016
兩個域名的作用在於測試本地互聯網是否可用，轉發到代理服務器上進行測試似乎沒有意義。

[kabegoe]

兩個域名的作用在於測試本地互聯網是否可用，轉發到代理服務器上進行測試似乎沒有意義。

您说的对。确实是我欠考虑，我这个PR有些问题。如果在实际运用中把microsoft设为需要被代理的话，那就成测试代理服务器的连接性了。

不过，这两个域名是需要被拿到internet上解析的。并且，发往这两个域名的流量需要被发送到internet上。（甚至，这些域名对应的接入点都在国外。）这两个域名和一些不对应（或不该发往）internet上服务器的域名在同一个叫private的list里，是否有些奇怪？或者我们是否可以考虑把private再细分一下？现在private这个list包含着一种direct的感觉...不知道我的意思是否有传达到位。

[rootmelo92118]

兩個域名的作用在於測試本地互聯網是否可用，轉發到代理服務器上進行測試似乎沒有意義。

您说的对。确实是我欠考虑，我这个PR有些问题。如果在实际运用中把microsoft设为需要被代理的话，那就成测试代理服务器的连接性了。

不过，这两个域名是需要被拿到internet上解析的。并且，发往这两个域名的流量需要被发送到internet上。（甚至，这些域名对应的接入点都在国外。）这两个域名和一些不对应（或不该发往）internet上服务器的域名在同一个叫private的list里，是否有些奇怪？或者我们是否可以考虑把private再细分一下？现在private这个list包含着一种direct的感觉...不知道我的意思是否有传达到位。

private的作用的確是用於direct，不過這不妨礙這兩個域名在正常情況下的連線，畢竟他們並不在中國大陸境內被屏蔽，private的作用是讓不應該被發向公網的域名能在不走代理通道的情況下直接出站，並用於局域網。巧合的是，這兩個域名雖然應該發向公網，但是是測試局域網與互聯網的聯通性，所以需要在不走代理的情況下直接出站。我認為嚴格意義上來說它們不符合private的定義，但目前放在這裡是做合適的。

[kabegoe]

private的作用的確是用於direct，不過這不妨礙這兩個域名在正常情況下的連線，畢竟他們並不在中國大陸境內被屏蔽

在国内绝大多数的时候是这样的。在一些特殊情况（例如错误地分流DNS）下，www.msftconnecttest.com的A记录会被解析成13.107.4.52(Ref)，且13.107.4.52的确是微软服务器的ip地址并不是被污染的结果。但是，从国内貌似无法直连这个服务器(Ref)。

还有一个就是更特殊的情况了。可能大多数用private是在客户端用于指向direct，但在服务器端，会不会有人把private（不仅是geoip还有geosite）指向block用于保护服务器的内部网络？至少我是这么应用的。虽然我不了解机场的事情，但我猜测或许也有这么设定的机场主。在这种情况下，客户端在全局代理时虽然可以正常访问互联网但Windows会显示没有互联网访问。

当然，我以上提及的两个情况可以说是比较罕见的问题。甚至也可以说是没有100%正确配置客户端和服务端情况下才会导致的问题。现在放在private里确实无伤大雅，但或许仍有改进的空间？比如说把这两个域名放入microsoft再加上@cn（但貌似又涉及#28, #256 这两个历史遗留问题了...）？

[IceCodeNew]

在一些特殊情况（例如错误地分流DNS）下，www.msftconnecttest.com的A记录会被解析成13.107.4.52(Ref)，且13.107.4.52的确是微软服务器的ip地址并不是被污染的结果。但是，从国内貌似无法直连这个服务器(Ref)。

这个项目不是万金油，众口难调，不能为这种边际场景特别考虑。如果用户不能解决 dns 问题，可以考虑自己写的路由规则绕过。

还有一个就是更特殊的情况了。可能大多数用private是在客户端用于指向direct，但在服务器端，会不会有人把private（不仅是geoip还有geosite）指向block用于保护服务器的内部网络？至少我是这么应用的。虽然我不了解机场的事情，但我猜测或许也有这么设定的机场主。在这种情况下，客户端在全局代理时虽然可以正常访问互联网但Windows会显示没有互联网访问。

同样的，因为开启全局代理导致的问题应该由客户自己解决。没有办法用一个项目同时支持好用户分流的需要同时又针对全局代理的场景避开所有问题。

---

private 分类是历史遗留问题，我的立场是除非必要，否则不改变之前大家已经习惯的分类规则。

[kabegoe]

在一些特殊情况（例如错误地分流DNS）下，www.msftconnecttest.com的A记录会被解析成13.107.4.52(Ref)，且13.107.4.52的确是微软服务器的ip地址并不是被污染的结果。但是，从国内貌似无法直连这个服务器(Ref)。

这个项目不是万金油，众口难调，不能为这种边际场景特别考虑。如果用户不能解决 dns 问题，可以考虑自己写的路由规则绕过。

还有一个就是更特殊的情况了。可能大多数用private是在客户端用于指向direct，但在服务器端，会不会有人把private（不仅是geoip还有geosite）指向block用于保护服务器的内部网络？至少我是这么应用的。虽然我不了解机场的事情，但我猜测或许也有这么设定的机场主。在这种情况下，客户端在全局代理时虽然可以正常访问互联网但Windows会显示没有互联网访问。

同样的，因为开启全局代理导致的问题应该由客户自己解决。没有办法用一个项目同时支持好用户分流的需要同时又针对全局代理的场景避开所有问题。

private 分类是历史遗留问题，我的立场是除非必要，否则不改变之前大家已经习惯的分类规则。

连着提了两个边际场景的issue实在不好意思...如您所说的，实际运用中确实太复杂一个项目没法照顾到所有情况。
确实我目前也拿不出一个解决private分类问题的完美方案，那就保持现状吧～

但我还是有一个疑问：微软的检查网络状态的域名要放在private里的话，那按照这个逻辑的话其他软件/系统的检查网络状态的域名[1]岂不是都应该放在private里了嘛？
例如在Android中被用于检测网络状态的connectivitycheck.gstatic.com[2]，在国外DNS解析的142.250.207.3[3]从国内无法访问[4]，在国内DNS解析的203.208.43.98[5]就可以从国内访问[6]。可以说是行为和www.msftconnecttest.com非常相似了。那我们是否也需要把connectivitycheck.gstatic.com放进priavte里呢？

再次感谢辛勤维护这个项目的各位。

[1] https://www.cnblogs.com/gnz48/p/16433786.html
[2] 没找到官方文档，但根据谷歌以及百度搜索会发现是被用于检测网络状态的。例如：https://help.harmanpro.com/what-is-connectivitycheck-gstatic-com
[3] https://dns.google/query?name=connectivitycheck.gstatic.com
[4] https://tcp.ping.pe/142.250.207.3:80
[5] https://tool.chinaz.com/dns/?type=1&host=connectivitycheck.gstatic.com&ip=
[6] https://tcp.ping.pe/203.208.43.98:80

[IceCodeNew]

连着提了两个边际场景的issue实在不好意思...如您所说的，实际运用中确实太复杂一个项目没法照顾到所有情况。 确实我目前也拿不出一个解决private分类问题的完美方案，那就保持现状吧～

但我还是有一个疑问：微软的检查网络状态的域名要放在private里的话，那按照这个逻辑的话其他软件/系统的检查网络状态的域名[1]岂不是都应该放在private里了嘛？ 例如在Android中被用于检测网络状态的connectivitycheck.gstatic.com[2]，在国外DNS解析的142.250.207.3[3]从国内无法访问[4]，从国内DNS解析的203.208.43.98[5]就可以[6]。可以说是行为和www.msftconnecttest.com非常相似了。那我们是否也需要把connectivitycheck.gstatic.com放进priavte里呢？

再次感谢辛勤维护这个项目的各位。

[1] cnblogs.com/gnz48/p/16433786.html [2] 没找到官方文档，但根据谷歌以及百度搜索会发现是被用于检测网络状态的。例如：help.harmanpro.com/what-is-connectivitycheck-gstatic-com [3] dns.google/query?name=connectivitycheck.gstatic.com [4] tcp.ping.pe/142.250.207.3:80 [5] tool.chinaz.com/dns/?type=1&host=connectivitycheck.gstatic.com&ip= [6] tcp.ping.pe/203.208.43.98:80

这个问题很好。
对我来说理想的情况是 #390 得到实现，这样我可以把 private 里所有分类不合理的域名复制到适合的分类（比如 microsoft ）里，用 @noproxy 之类的属性标记。
之后要求此前通过 private 规则来做白名单的用户调整自己的路由规则。等过一段时间以后从 private 里删掉这些不合理的域名。

但是因为这个事情一直没有实现，为了不影响下游客户，这些用于检测网络状态的域名就只好根据实际使用时的方便进行分类。

你说的安卓平台的域名也只是没有人提出问题而已，否则也可能会在讨论过后被移到 private 里。

[kabegoe]

谢谢您的解答，确实不是这两个域名放哪个list这种小问题。可能是实际运用中出现问题的概率很小（用private的人很少），那确实不用着急做修改。像我这种特殊情况还是在自己的配置文件里加一个规则更为合适。
感谢各位维护者～辛苦了～

[database64128]

Keeping these domains in the private category provides a better out-of-box experience for users connecting to public WiFis that use Captive Portal for authentication. Windows detects the captive portal when the request to msftconnecttest.com is redirected to another site, and opens the web page automatically. That was also my original intention of adding this domain.

[mazzz1y]

@database64128 @IceCodeNew

This is a very ambiguous rule. I spent some time to find out why my windows machine can't connect to internet when I blocked private domains.

I think that better to add new connectivity-check group with these domains along with google, apple, etc. It is strange when public domains with public ips located in private group

[database64128]

@mazzz1y Did you mean you blocked private domains on your proxy server? If so, your issue can easily be fixed by adding a rule on your client to use direct connection for private domains.

[mazzz1y]

Yes, it is not a problem, I fixed it immediately when I found the problem.

I just wanted to say my opinion about separating these domains to another group. I think it is more elegant solution

[database64128]

More elegant? Maybe. But it would be quite a breaking change. At least for me, I would have to add the new list to my automation, and then each time the updated lists arrive on one of my deployment targets, the configuration would have to be updated manually to include the new list. And I would also have to inform some of my friends about the change and ask them to update.

[mazzz1y]

up to you :)

[rootmelo92118]

@database64128 @IceCodeNew

This is a very ambiguous rule. I spent some time to find out why my windows machine can't connect to internet when I blocked private domains.

I think that better to add new connectivity-check group with these domains along with google, apple, etc. It is strange when public domains with public ips located in private group

I suggest you using geoip:private.

[mazzz1y]

I suggest you using geoip:private

Different goals. I want to forbid clients to check how internal domains are resolving in server's network.

Any way I don't have any problem now, it is just my opinion

[IceCodeNew]

I suggest you using geoip:private

Different goals. I want to forbid clients to check how internal domains are resolving in server's network.

Any way I don't have any problem now, it is just my opinion

Thanks for sharing it. I think that shows how we were not prudent enough when maintaining this category before.
So my recent concerns do make sense. And I will try harder to keep a reasonable standard for further contributions.