众所周知,Nat机器由于大量用户公用一个ipv4,很容因很容易被照顾,因此通常需要借助使用cloudflare使用。但是很多新手对如何套cloudflare一头雾水,即使是老手对于一些新的cloudflare特性也不是非常了解。还有一些朋友发现,其nat服务商的ipv6给的是Hurricane Electric的网络地址,早年cloudflare为了避免滥用“cf-he”接入方式完全禁止了HE的ipv6网段,因此失去了下面要讲的第一种方法的可能性,但这种情况下仍然可以成功利用cloudflare的,只是很多人不清楚,因此这里关于“套cloudflare”进行一下总结。
套cloudflare其实是一个很土的说法,其实就是利用cloudflare作为CDN,当发起一个http(s)请求的时候,先由cloudflare接受,然后转发到nat服务器。考虑到cloudflare作为网络基础设施,其被照顾的影响过于复杂因此很难直接照顾。
为什么nat机器不好套cloudflare呢,是很多人习惯了直接用vps的公网ipv4接入cloudflare,但是nat是没有ipv4的,无法直接接入。还有一些服务商提供了ipv6 only的服务器,直接没有ipv4地址,更需要特殊对待。针对不同的情况,有几种变通策略。
使用ipv6接入
最常见的,很多人第一反应就是使用ipv6接入,也就是添加AAAA解析。
常见的nat商家(比如gullo/webhorizon/natvps.uk等)都是提供nat v4 + 独立ipv6地址的,因此虽然无法直接使用共享ipv4的80/443端口进行接入,但是可以使用独立ipv6接入,毕竟ipv6是独享的所有端口皆可以使用。如下图所示就是接好了。
这种接入方法是最容易想到,也是非常稳定的方案。但是有几种情况不能使用这种方法:
如果商家的ipv6网络是Hurricane Electric,cf禁止接入。比如gullo的部分地区(纽约等)
商家不提供ipv6地址,比如最近很火的khanwebhost
使用Origin Rules
众所周知,nat服务器之所以被称为nat服务器,是因为ipv4地址共享,每个人只能使用部分端口。那么我们能不能使用这些端口进行接入呢。在半年前,也许答案是否定的,因为Cloudflare支持使用的非标端口很少,并且都是低位端口号,nat服务商的端口号一般都在10000以上,因此不好使用cf支持的非标端口。但是今年cloudflare免费开放了他们的Origin Rules,这允许我们使用任何端口接入到cf网络。配置如下:
注意,vps本地的http服务器(如nginx)需要监听对应的非标端口。
使用服务商域名forwarding + cloudflare接入
一般而言,nat机器服务商,都提供一种服务,就是域名forwarding,简单而言就是其宿主机器监听公网80/443端口,然判断收到请求的域名(host/sni)后forward到对应的nat vps实例的内网地址。
这种想法很好,但问题是很多他们用来监听80/443端口的公网地址阵亡了。虽然如此,这并不影响我们使用80/443端口接入cloudflare,我们仍然可以使用cloudflare添加A记录到这些宿主机器的ipv4地址,然后在服务商面板上添加域名forward规则。
注意,vps本地的http服务器(如nginx)需要监听对应的内网地址。
使用Cloudflare允许的非标准端口接入
cloudflare官方支持一系列非标准web端口进行接入,如果你的ipv4被照顾了,但是仍然想要接入,除了上面提到的两种方法,还可以使用Cloudflare允许的非标准端口。具体可以用的端口如下:
那么你可能会问了,这些端口我的nat机器服务商都没有对我开放,怎么办。
nat服务商除了提供域名映射以外,还提供端口映射,你可以把上面提到的cf支持的非标端口转发到内网ip,然后使用cf添加A记录解析,最后使用非标端口访问你的域名达到目的。只不过这种方法显得比较鸡肋,作为一种后备方案好了。
使用cloudflare argo接入
最后的最后,有些情况下服务商并没有提供公网ipv4/ipv6,比如pikapods的容器服务,可以使用cloudflare argo接入。限于篇幅,感兴趣的可以搜索相关教程,有时间可能会单独开一帖子介绍相关有趣玩法。
讲了这么多,我们论坛里面的小鸡应该使用那种方式接入呢,其没有独立ipv6,但是有很多直连端口,可以使用Cloudflare Origin Rules 接入
此文章未被授权转发,请删除
https://www.nodeseek.com/post-44-1
大佬,文章下面有来源网址,注明了来源的。如果还不行,那我就删了。