Help talk:如何访问维基百科/存档2

维基百科,自由的百科全书
跳到导航 跳到搜索

Opera浏览器也可用于访问维基百科

具体步骤请参见:[1]。如果可以的话,请将此方法写进正文中。-- Welcome to take Wuhan Metro Painjet Line! 2018年6月20日 (三) 13:57 (UTC)回复[回复]

請您注意:該網頁内容已遭到刪除。-渦輪增壓 2021年1月10日 (日) 12:41 (UTC)回复[回复]

opera自带fq 武局南段大红枣留言) 2021年2月7日 (日) 02:12 (UTC)回复[回复]

198.35.26.96疑似被封IP

请求已拒绝 CreampieGolden State Finals Champion 2018年6月23日 (六) 17:59 (UTC)回复[回复]

20180620起,英文版维基百科及其它的维基百科目前在中国大陆的ipv4环境下无论http还是https均无法访问(已测试北京联通/北京教育网v4路由)

疑似ip解析正常,但骨干网丢掉了前往198.35.26.96的数据包

--2001:DA8:201:2676:5D7B:617F:9F58:8449留言) 2018年6月20日 (三) 17:38 (UTC)回复[回复]

似乎已经好了? --砜中嘌呤的白磷萃取 打谱 2018年6月21日 (四) 06:47 (UTC)回复[回复]

存在意义???

既然看到这个页面,就说明成功访问维基百科了,教怎么访问没有意义Skywalker is gone 2018年7月31日 (二) 14:02 (UTC)回复[回复]

  • 有镜像网站,看得到的也可以参照这个帮助看不到的人。怎么就没意义了? --🐕🎈(实用主义大于天) 2018年8月6日 (一) 02:46 (UTC)回复[回复]

//个人认为还是有必要的,来自一个不太会编辑主要以查证为主的用户。梯子费用比较高昂,不是所有时候都能以这种方式访问,大部分时候还是在里面的。如果能利用短暂的上网时长掌握方法,就可以授人以渔。2019年10月11日 (一) 00:16 (UTC+8)

DNS over HTTPS

DNS over HTTPS 也是一种避免 DNS 污染的可行方法,能否加入该条目?--石𫁶留言통일렬차 달린다 2018年8月11日 (六) 05:44 (UTC)回复[回复]

H:VISIT

有何存在意义?Help_talk:如何访问维基百科在此Skywalker is gone 2018年8月2日 (四) 05:40 (UTC)回复[回复]

  • 你住在中华人民共和国,但是现在在国外留学,然后你放假了要回国,这个页面就教你怎么在国内也能登录维基百科。大概是这样吧,我扯不下去了。--Tazkeung(CommentHERE) 2018年8月2日 (四) 05:55 (UTC)回复[回复]
  • 既然进去了说明能上维基百科,看怎么上没意义,进不去说明上不了,上不了也不可能进去,看不到Skywalker is gone 2018年8月2日 (四) 05:56 (UTC)回复[回复]
解决直连或者申请在代理上豁免的需要。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月2日 (四) 12:50 (UTC)回复[回复]
  • 便于转载。便于勉强查看(缓慢代理、特定网络等)时了解有关方法。便于记录有关与最新信息。--YFdyh000留言) 2018年8月2日 (四) 17:52 (UTC)回复[回复]
  • 可以从能访问的维百镜像上的这个页面找到访问方法,当时198.35被墙的时候就是这样做的Face-smile.svg--BR 2018年8月3日 (五) 11:53 (UTC)回复[回复]
  • 哈哈哈哈哈哈哈我早就想到这个了……“我上不去维基怎么办?”“看看Help:如何访问维基百科啊”……哈哈哈哈容我再笑会儿……718smiley.svg--正在学习友谊就是魔法CuSO4 2018年8月3日 (五) 13:15 (UTC)回复[回复]
    • 笑笑无妨。--希望自己谦逊的HB 2018年8月5日 (日) 12:35 (UTC)回复[回复]
  • 怎么了?有镜像啊,能直接访问的人也可以参照那个给不能访问的人帮助。哪里可笑? --🐕🎈(实用主义大于天) 2018年8月6日 (一) 02:46 (UTC)回复[回复]

中文维基百科疑似解封?

多个地区移动网络下已经可以正常访问。--Aoke1989留言) 2018年8月23日 (四) 01:59 (UTC)回复[回复]

电信和移动查114,表示你幻觉了。不过电信查114的v6地址是干净的,估计是最近开始推v6的附带产物?——路过围观的Sakamotosan | 避免做作,免敬 2018年8月23日 (四) 02:36 (UTC)回复[回复]
移动默认的DNS,v4污染,v6正常。如果开始下发v6地址的话,v6理论上可以用。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月23日 (四) 02:38 (UTC)回复[回复]
[2],似乎部分地区的确解封了(但最近GFW似乎行事有些乖张,需要观察一段时间)--百無一用是書生 () 2018年8月23日 (四) 03:14 (UTC)回复[回复]
感觉大部分都正常操作中,甚至见到出现v6正常地址,可能最近针对v6铺开的调整,不小心动了城墙的v4客户端配置(笑)。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月23日 (四) 08:50 (UTC)回复[回复]
@Aoke1989:,试一下IP登录,然后看看我的贡献显示的IP是v4还是v6。v4的话,可能是城墙客户端配置改坏了,v6的话,v6的暂时正常情况吧,以后还要看v6的城墙还能走多远。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月23日 (四) 08:50 (UTC)回复[回复]
看起来是因为V6地址的原因。--Aoke1989留言) 2018年8月23日 (四) 14:38 (UTC)回复[回复]
現時訪問有間歇性不能出現。——約克客留言) 2018年8月24日 (五) 10:49 (UTC)回复[回复]
好像v4出现抢答TCPReset了。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月24日 (五) 12:19 (UTC)回复[回复]
@Cwek:我这边过去数个小时连hosts都“被毙了”,逼我开了一阵SS。--Liuxinyu970226留言) 2018年8月24日 (五) 14:44 (UTC)回复[回复]
我这里也要开VPN了……难道墙找到新方法了?--№.N留言) 2018年8月24日 (五) 14:59 (UTC)回复[回复]
应该是吧,反正目前Telegram以及QQ群里,已经有人在问这个了... --Keep Calm And Carry On, Please. 2018年8月24日 (五) 16:25 (UTC)回复[回复]
  • 移动4G、宽带hosts法均已失效。地理位置广东。—YouTable 2018年8月25日 (六) 04:04 (UTC)回复[回复]
  • 时断时续,断了以后需要从其他语言版本重新点入--苞米() 2018年8月25日 (六) 04:06 (UTC)回复[回复]
  • 我从今天开始直接按浏览器的收藏(书签)进入中文维基百科有时会失败,但是通过选择语言的界面进入倒是没问题。--FishPlusWolf 2018年8月25日 (六) 13:40 (UTC)回复[回复]
  • 这个“解封”应该是启用了IPv6的缘故吧,然而IPv4下反而封得更紧了,改了Hosts都能“连接被重置”,一首凉凉送给大家。--侧耳倾听 2018年8月25日 (六) 16:58 (UTC)回复[回复]
  • Hosts已经不管用了=-=,现在必须X墙 MasaneMiyaPA留言) 2018年8月26日 (日) 08:44 (UTC)回复[回复]
  • 烦请墙内Wikipedians(特别是汇报hosts被封)查看一下是否可以浏览其它语种的维基百科。如果可以的话,那将是第一次目睹墙SNI封杀。(因为维基百科所有子域都使用*同样的*证书,所以墙是不可能通过证书来进行有选择性封杀的)69.42.179.19留言) 2018年8月28日 (二) 14:38 (UTC)回复[回复]
  • 又。。。这两天的事--Qa003qa003留言) 2018年8月30日 (四) 01:40 (UTC)回复[回复]
  • 大約兩個月前,我會內地還能用日文維基與英文維基,大約一個月前,日文維基就被封禁了,而中文維基一直維持在封禁狀態(包括粵語版)Pigppp留言) 2018年9月1日 (六) 16:37 (UTC)回复[回复]

Hosts失效

目前hosts修改所用ip似乎已经失效。请帮助确认。十分感谢。----煤桶骑士留言) 2018年8月24日 (五) 16:19 (UTC)回复[回复]

山西太原的表示hosts已经挂了...--Keep Calm And Carry On, Please. 2018年8月24日 (五) 16:25 (UTC)回复[回复]
这里列出的几个IP都被送进黑洞路由里了?还是SSL报头里带的明文zh.wikipedia.org被当成关键词深度包检测了?--菲菇维基食用菌协会 2018年8月24日 (五) 16:53 (UTC)回复[回复]
应该是SNI明文导致的,先访问en再访问zh使用相同IP依然可以。—思域无疆大道 事体 机器 2018年8月24日 (五) 17:02 (UTC)回复[回复]
看了下twitter和微博的少量反馈,似乎真的是sni rst了,据说是北京时间昨天大量部署的……--№.N留言) 2018年8月24日 (五) 17:40 (UTC)回复[回复]
是的,不仅是维基百科,还有Steam社区、美国之音等一众网站也被SNI RST了,在此之前,只有GoogleFacebookTwitter等巨头网站才有这样的待遇,看来自今年8月10日TLS 1.3规范正式发布后,国家防火墙的工作人员已经开始狗急跳墙了。--Yumenghan留言) 2018年8月24日 (五) 19:05 (UTC)回复[回复]
唉:-(大家快去P区安利基金会换上TLS 1.3吧。退TLS 1.2保平安。--1=0欢迎加入WP:維基百科維護專題 2018年8月25日 (六) 01:31 (UTC)回复[回复]
我在twitter上所看到的其中一个关于墙大面积部署https关键字过滤的反馈就提到就算是TLS 1.3也无法绕过……传送门在这。具体我不了解,我不能保证那个反馈是否准确,望在这方面熟悉的人能够提供解释。--№.N留言) 2018年8月25日 (六) 01:45 (UTC)回复[回复]
我印象中TLS 1.3的SNI不是明文的啊……--1=0欢迎加入WP:維基百科維護專題 2018年8月25日 (六) 02:01 (UTC)回复[回复]
(~)補充:我去群里了解了一下,目前的SNI确实不行,需要ESNI出来了才可以。但那个现在还是草案 囧rz...--1=0欢迎加入WP:維基百科維護專題 2018年8月25日 (六) 02:28 (UTC)回复[回复]
感慨,这次的封锁让我认识到什么是SNI,我才知道原来我访问什么网站墙是看得到的,他们只是看不到内容。希望“特仑苏”1.3还有ESNI能够完成吧……这次被墙抢先一步了……--№.N留言) 2018年8月25日 (六) 07:54 (UTC)回复[回复]
问题是tls1.3能不能强制降级,其次是sni加密,如果能降级,还是老套路。FGT三巨头一早是主要服务入口直接黑洞,早凉透了。CDN估计难搞或者只能向CDN供应商发难。我们算照顾少了,至少还没有搞路由黑洞。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月25日 (六) 02:04 (UTC)回复[回复]
似乎只要用最新版本,支持TLS 1.3的浏览器就不会被降级,不支持的才会降级。我理解的是这样的。--1=0欢迎加入WP:維基百科維護專題 2018年8月25日 (六) 02:31 (UTC)回复[回复]
突然脑洞,能不能找一堆肉鸡之类骚扰sniReset功能,因为这种检测是七层技术,可能需要耗费检测算力,如果找一大堆各种合规不合规的sni数据去消耗,会不会认为负载过大不划算而不使用这种策略?(笑),因为现在主要是针对UDPDNS抢答和路由黑洞这些高效策略,早期的简单TCPreset现在好像少见?——路过围观的Sakamotosan | 避免做作,免敬 2018年8月25日 (六) 03:37 (UTC)回复[回复]
可那旁路上的是值好多好多钱的超算啊…能处理整个国家骨干网流量的设备还是勿忧性能了吧(不过找漏洞并不是不可能,有多少人记得西厢计划来着?)。—菲菇维基食用菌协会 2018年8月25日 (六) 04:06 (UTC)回复[回复]
西厢计划的思路一直都是可以使用的,旁路以及性能问题总会有难以解决的漏洞Your State is Not Mine: A Closer Look at Evading Stateful Internet Censorship——Macronut wiki留言) 2019年12月3日 (二) 02:22 (UTC)回复[回复]
  • 一个小窍门,先访问英文维基百科en.wikipedia.org,再访问中文维基百科zh.wikipedia.org就可以上了。——星耀晨曦留言) 2018年8月25日 (六) 04:30 (UTC)回复[回复]
  • 部分地區可以用。-- Creampie歡迎來訪 2018年8月25日 (六) 05:18 (UTC)回复[回复]
  • 也许该讨论下放宽申请IPBE的门槛。——笨笨de子墨(讨论) 2018年8月25日 (六) 10:11 (UTC)回复[回复]
    • 有什么浏览器支持域前置(Domain Fronting)吗?由于英文维基不受影响,用 $ curl -s https://en.wikipedia.org/wiki/Wikipedia:VP -H "Host: zh.wikipedia.org" 的方式可以有效的访问中文维基,并且使用的是自己的IP,故不会受到IP封禁的影响。——Arnie97留言) 2018年8月25日 (六) 16:22 (UTC)回复[回复]
      curl 的发出数据包的 sni server_name 不应该默认和 Host 相同吗,我觉得这条指令应该不能绕过 sni 阻断吧--Space Timee留言) 2022年4月20日 (三) 09:40 (UTC)回复[回复]
      即使在英文维基还没有被墙的情况下--Space Timee留言) 2022年4月20日 (三) 09:42 (UTC)回复[回复]
    • IPBE的申请本来就没什么门槛。——星耀晨曦留言) 2018年8月25日 (六) 23:21 (UTC)回复[回复]
  • 我找到一个关于为什么访问其他未被封锁维基百科后还能短暂访问被封语种维基百科的解释(可以的话去互联网档案馆存个档,知识问答里也有用户做出和这类似的解释)。当然,如果维基媒体基金会所有网站全被封或者对应IP被封,这个方法肯定是无效的了。--№.N留言) 2018年8月26日 (日) 00:11 (UTC)回复[回复]
    • 还有就是坐等TLS1.3推广ESNI给网址加密了。--侧耳倾听 2018年8月26日 (日) 06:36 (UTC)回复[回复]
      • 这里我想到几个问题,一是ESNI是否有可行性(也就是能不能够实现),要是胎死腹中一辈子都得用VPN(对我来说VPN最麻烦的地方就在于时不时会掉线……),二是ESNI正式推出后,墙会怎么应对,毕竟这玩意会让Google、Twitter、Facebook等墙的重点照顾对象少去一层封锁手段,少去一层封锁手段可能会令墙推出新的封锁手段:据说墙封锁BBC刚好发生在BBC支持https之后……--№.N留言) 2018年8月26日 (日) 07:46 (UTC)回复[回复]
        • ESNI能不能实现留给草案开发者去处理,不过WP的目标是构建一个知识百科全书,而不单是一个对抗审查的工具。手段只是道高一尺魔高一丈的猫捉老鼠的游戏,最后看谁斗到最后罢了。不过可以推测问题有,WP的审核级别视乎变高了,可能长期使用绕过工具的时间会变长罢了。(GTF是黑洞套餐都没说什么呢,DNS污染算是基本操作了。)——路过围观的Sakamotosan | 避免做作,免敬 2018年8月26日 (日) 08:15 (UTC)回复[回复]
          • 我不过是很在意不能用代理以外的手段访问维基百科罢了,我不太喜欢用代理,因为不稳定的时候经常断线,有时甚至好一段时间都连不上去……--№.N留言) 2018年8月26日 (日) 08:25 (UTC)回复[回复]
            • 说的也是哦,关键的问题是维基百科在GFW里的“地位”提高了,以后墙总会换着花样搞事情,不怕贼偷就怕贼惦记。--侧耳倾听 2018年8月26日 (日) 09:15 (UTC)回复[回复]
              • 至少地位没Google、Facebook等那么高,如果有,估计维基百科那五个IP早就全封掉了,那样的情况下hosts同样帮不了忙。而且不要忘了这次墙的调整是令几乎所有支持https的黑名单网站都SNI RST,例如日亚、Steam社区等等等等……--№.N留言) 2018年8月26日 (日) 09:23 (UTC)回复[回复]
  • 我找了一圈都没找到能够绕过SNI RST的工具,之前看过一个法国的网站(madynes.loria.fr),有个叫escape的firefox插件,但今早我试了下根本装不上……怀疑是老物了……查了下twitter关于ESNI的讨论,也有点不想指望ESNI了,ESNI据说基于DNS,现在只是草案,但假若真要这样,有一定可能改hosts会失去作用……毕竟改hosts是绝大多数中国大陆人不使用代理访问维基的(接近)唯一的方式了(其实DNSCrypt也可以,前一两周还试了下访问BBC都能用)--№.N留言) 2018年8月27日 (一) 05:31 (UTC)回复[回复]
    • 我倒没问题,本身就有内网用的DNS,来源经过安全获得,所以可以不依赖Hosts。至于基于DNS,其实就是用另一条(安全)信道获得一个信任的安全令牌来处理,如果DOT或者DOHS成行的话,DNS的安全性保障了,然后TLS就可以不用完全零信任启动了。至于插件,我认为可能和FF早期可以操作底层网络连接流有关,不过现在最新的不支持旧版插件,即使是次一些版本还是因为这个插件没签名也装不了。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月29日 (三) 02:14 (UTC)回复[回复]
      • 嗯,现在Firefox只支持WebExtension,不支持escape插件那种用XUL做的扩展,更何况现在Firefox和Chrome都无法改SNI了,可以几乎肯定的是暂时只能乖乖用老版Firefox了。关于ESNI,如果用上DNS既令墙觉得反正SNI审查维基等网站的手段不会失效,而我们也只需要考虑如何绕过DNS这一部分,也算是OK,不过twitter上有人说ESNI捆绑DNS会令其像DNSSEC那样难以推广……---№.N留言) 2018年8月29日 (三) 05:11 (UTC)回复[回复]
    • 这份草案来看,DNS非必选机制(but other mechanisms are also possible.),只是文档定义这种机制来发布和获取公钥,然后用公钥来加密"encrypted_server_name"扩展。不过,也得网页浏览器支持其他机制输入才行,或者用特制DNS代理。Split Mode是特定服务器为特定域解密服务器名、作为转发TLS加密包的代理(似乎同SNI代理),Shared Mode是能解密名称和TLS包的服务器。要求至少TLS 1.3。Firefox在跟进。需要服务器软件及运维更新,从稳定性周期来说,还要很久。--YFdyh000留言) 2018年8月29日 (三) 06:36 (UTC)回复[回复]

我做了一个实现,大家可以参考。代码在这里。原理就是每隔40秒在后台向英文维基发一个请求。这样我们的TLS会话缓存就会让我们一直可以用中文维基了。注意要在浏览器一直留一个zhwiki的标签页喔,这样才能自动发请求。实现仅供大家参考。欢迎给我的repo点星星。--1=0欢迎加入WP:維基百科維護專題 2018年8月26日 (日) 09:28 (UTC)回复[回复]

给testwiki吧。这样会影响到enWP的统计数据。--Antigng留言) 2018年8月26日 (日) 12:04 (UTC)回复[回复]
  • 基金会:我们又双叒叕遭到了来自中国的IP地址的DDoS攻击。(/‵Д′)/~ ╧╧
    墙:我不是,我没有,说出来你可能不太相信,是那群维基人先动手的。╮(╯_╰)╭
    --侧耳倾听 2018年8月26日 (日) 17:00 (UTC)回复[回复]
试过了上面提到的绕过办法,但是我这里行不通--百無一用是書生 () 2018年8月27日 (一) 07:45 (UTC)回复[回复]
偶然是可以,不太确定原因:先en,如果先zh过肯定会不行,必须启用h2支持。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月27日 (一) 08:44 (UTC)回复[回复]
教育网也不能访问。--185.185.40.100留言) 2018年8月28日 (二) 01:42 (UTC)回复[回复]
似乎域名前置可以对付这个问题。但首先得服务器支持,其次至少要有插件才可以(我理解没错的话)--百無一用是書生 () 2018年8月28日 (二) 02:33 (UTC)回复[回复]
服务器目前问题不大,证书的可选域名支持很多,也不禁止不匹配,但Chrome/Firefox扩展的API改不了TLS的SNI头。我试了重定向请求再改内部'Host'请求头,能用,但地址栏地址会变成重定向后的假地址,一些脚本会因此异常(判断或存储网页域名那些),体验不好。--YFdyh000留言) 2018年8月28日 (二) 03:13 (UTC)回复[回复]
域前置只能说邪门歪道,只有特定客户端才能这么干,除非打包一个专用浏览器。基金会那边会不会为此支持也有点emmm吧。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月28日 (二) 06:32 (UTC)回复[回复]
我想知道这个是基于什么原理(这个就是搞出escape插件的那个团队写的,没看懂所以来问)。我现在暂时用老版本的firefox加上这个escape插件,能正常访问。--№.N留言) 2018年8月28日 (二) 12:59 (UTC)回复[回复]
类似域前置的方法,插件截取SNI数据后,改成其他域名发出,然后在TLS加密的host头中放上真实的域名(大概是这样?)现在不能用感觉更可能是这种方法已经不被浏览器支持--百無一用是書生 () 2018年8月29日 (三) 02:14 (UTC)回复[回复]

还有一种“古法”:在IE6时代浏览是不发送SNI信息的,这对于维基百科来说是奏效的,因为维基百科的服务器只负责传送维基百科站点,所以证书可以在不预先知道客户端要求什么语种的情况下送出(只需*字符wildcard匹配:*.wikipedia.org就行了。)而客户端可以匹配自己的语种。所以我现在要实验一下,使用Linux开源Firefox源代码进行“SNI拔除”,专门针对维基百科。这样的话当局如果要封禁,除了禁止不发送SNI信息式访问,就只有封维基百科IP了。65.92.206.188留言) 2018年8月28日 (二) 23:17 (UTC)回复[回复]

使用不支持SNI的浏览器(例如Firefox 1等)也不失为一个好办法。不过据说TLS 1.3开始要求带上SNI……这里有提到几个典型的绕过SNI封锁的几个方法……--№.N留言) 2018年8月29日 (三) 05:11 (UTC)回复[回复]
“几个典型的绕过SNI封锁的几个方法”咱们这里基本都讨论到了....--百無一用是書生 () 2018年8月29日 (三) 07:01 (UTC)回复[回复]
囧rz...--№.N留言) 2018年8月29日 (三) 12:43 (UTC)回复[回复]
看例子的话,看来审查各国都有,只是目标不同罢了,手法基本就是那几把板斧。——路过围观的Sakamotosan | 避免做作,免敬 2018年8月29日 (三) 08:48 (UTC)回复[回复]
降级TLS,试了一下似乎不可行[3]?需要服务器端配合?--百無一用是書生 () 2018年8月29日 (三) 09:54 (UTC)回复[回复]
我试了,Firefox 1基本上已经处于用不了的状态了,大部分网页都打不开,拓展也装不了,还不停弹窗警告--Space Timee留言) 2022年4月20日 (三) 12:18 (UTC)回复[回复]
我是原PO主,我今早想到了一种更加巧妙的方法:不要完全拔除SNI,而是重新编程让Firefox只发送DNS域名的头两级,比如说,访问任何语种的维基百科,Firefox的SNI均只发送:wikipedia.org作为SNI host名,再比如说,访问任何谷歌博客,Firefox的SNI均只发送:blogspot.com作为SNI host名。这样做的好处是彻底失去任何墙可以用来封杀的特征(因为现在基本上所有TLS连接都带有SNI,所以不带有SNI的TLS连接反而成了一种特征,可以被墙利用进行封杀)。把"依附的自由"在维基百科上用到淋漓盡緻,逼的墙最后不得不封杀维基百科的IP地址。66.207.125.146留言) 2018年8月29日 (三) 12:45 (UTC)回复[回复]
我找到这个,看了下代码,似乎专门针对维基百科。--№.N留言) 2018年8月29日 (三) 12:55 (UTC)回复[回复]
似乎还带了点附带效果。69.162.113.194这个IP应该是一个SNI Proxy吧。除了维基百科的流量,这个代理应该就直接用这个proxy了吧。我用Windows的python试了试,没成功,返回Errno 10022。我不太懂python。--1=0欢迎加入WP:維基百科維護專題 2018年8月31日 (五) 01:37 (UTC)回复[回复]
我是在这找到的……说要用linux……用到windows可能要移植吧……其实linux什么效果也不能保证。说实话,要解决SNI这问题,要么DIY,做不到只能乖乖VPN……--№.N留言) 2018年8月31日 (五) 07:57 (UTC)回复[回复]
因为这个是给Linux用的,Windows版在这里TCPioneer——Macronut wiki留言) 2019年12月3日 (二) 02:21 (UTC)回复[回复]
有人开发了一个 nosni-proxy 应该可以绕过。另外有人提到攻击,据测试即使将sni分散在乱序的两个包中,墙依然能检测到。有兴趣的人可以考虑类似ip分片攻击的策略。2607:FCD0:100:1926:0:0:C28D:6E0D留言) 2018年9月17日 (一) 17:23 (UTC)回复[回复]
墙有简陋的协议栈会拼装TCP流,IP分片是无效的TCP默认禁用IP分片,而且IP分片无法通过NAT——Macronut wiki留言) 2019年12月3日 (二) 02:21 (UTC)回复[回复]
What a shame!我又不懂程序,hosts没法用了估计就只能X墙了...用英语wiki绕一遍真的不习惯 囧rz...--Huziyijs留言) 2018年9月22日 (六) 09:59 (UTC)huziyijs回复[回复]

一点想法,写在讨论结束之时

上个月月底,GFW升级了审查方法,大量部署SNI RST,不过其实根据SNI提供的明文信息进行审查,早已有先例:英国有电信运营商用这招来封锁提供盗版资源的网站(上面我给的其中一个链接有说到);韩国用这招屏蔽色情网站(我用Google搜的时候找到过有提及这点的相关讨论);而据说土耳其也用过这招(不记得哪里看到过这说法)。所以说我们算幸运的了,至少没这么早享受到这样的待遇,至少还能在中文维基百科被封之后用hosts苟上三年(当然你也可以说墙某些方面算是落后了……),当然我们觉得至少英文维基百科还能用,不过近年来,墙正在不断地扩建,现在墙扩建的趋势不再是只针对中文网站了,据我所知似乎只要是多数中国大陆人不用翻译器就能理解至少一部分内容的境外网站都可以是他们的目标,如果确实如此,那么日文维基百科的封锁便很容易解释了,参考search.yahoo.co.jp以及search.yahoo.com现在的访问状况,我认为,英文维基百科很有可能是他们的下一个目标(顺便说下,存有不少帮助中国大陆网民绕过审查的工具的Github未来也不可能幸免于难),当然最糟糕的情况是维基媒体基金会的所有五个IP全部都会遭到封锁,加上SNI RST,可以认为未来绕过审查将变得更加困难。--№.N留言) 2018年9月7日 (五) 06:21 (UTC)回复[回复]

神预言,英文wikipedia果然被封锁了。。。照这样下去。。。闭关锁国。。。大清还没亡——104.167.97.164留言) 2019年4月25日 (四) 05:20 (UTC)回复[回复]

这篇wiki从头读下来,处处都是神预言--Space Timee留言) 2022年4月20日 (三) 12:26 (UTC)回复[回复]

使用Chrome的插件谷歌访问助手也可以访问中文维基百科

使用Chrome的插件谷歌访问助手也可以访问中文维基百科 安装地址: https://chrome.google.com/webstore/detail/%E8%B0%B7%E6%AD%8C%E8%AE%BF%E9%97%AE%E5%8A%A9%E6%89%8B/gocklaboggjfkolaknpbhddbaopcepfp?hl=zh-CN 除了要求设置为hao123为主页以外并无其他缺点,而且可以使用TamperMonkey的脚本绕开设置首页 及时雨留言) 2018年9月22日 (六) 12:55 (UTC)94rain回复[回复]

备注: 除'谷歌访问助手'外,在谷歌应用商店上搜索:'谷歌访问','VPN'之类的关键词,大多能筛选出来的相应的扩展程序. (第三方代理插件有隐私风险,而且免费插件并不稳定,推荐多备用几个以便其中之一失效后,能够继续访问谷歌应用商店下载新的,可用的插件.)—以上未簽名的留言由183.178.58.209對話)於2019年12月14日 (六) 04:12 (UTC)加入。回复[回复]

使用Nginx本地反代无需代理服务器直连维基百科

  • 使用OpenSSL自签证书,CN填.wikipedia.org,得到rsa.key,cert.csr,cert.crt。
  • 将rsa.key,cert.crt放入Nginx下的conf目录下,打开该目录下的nginx.conf,加入:
  • 将cert.crt导入为系统可信证书,
  • Hosts文件中的关于wikipedia的IP全改成127.0.0.1
  • 启动Niginx,即可直连。
  • 该法适用于任何被SNI阻断但IP可连接的网站。

--207.148.113.20留言) 2018年9月23日 (日) 11:18 (UTC)回复[回复]

嗯......或许应该放到[[4]]?--XL-028留言) 2018年9月24日 (一) 02:38 (UTC)回复[回复]
  • 亲测可用,但(※)注意nginx配置中的空引号被自动隐藏了,应将对应行改为proxy_set_header Accept-Encoding ""; 。--Br2 2018年10月1日 (一) 08:16 (UTC)回复[回复]

* 请注意:原讨论中生成的自签名证书会被最新版本Firefox拒绝,请参见此处的替代配置(但请删除nginx.conf的“server 198.35.26.96:443;”一行)。--GZWDer留言) 2019年12月18日 (三) 19:00 (UTC)回复[回复]

请这位电脑小白不要瞎指捣,众所周知:Firefox自带证书库,不调用系统证书!Firefox用户可以在 选项-高级→证书→查看证书→证书机构→导入 导入自己的自签证书。--185.186.245.44留言) 2020年1月23日 (四) 01:51 (UTC)回复[回复]

DNS的疑问

看到文中写到中科大和清华大学的DNS可以访问被封锁的网站,那么他们的校内网是一种无视墙的存在吗?——104.224.133.18留言) 2018年12月3日 (一) 12:48 (UTC)回复[回复]

他们校园网的DNS服务器做了防污染相关的处理罢了--Space Timee留言) 2022年4月20日 (三) 12:45 (UTC)回复[回复]

此方法现在已经失效了,那两个估计是漏网之鱼.或者学校当时有特殊用途——Raindrops2005留言)2019年4月27日 (六) 11:23 (UTC)回复[回复]

可以在匿名ip的讨论页上举报该ip疑似公用代理服务器吗?

如题,详见User_talk:103.114.161.158,其中本人提供了确凿的证据(提供该公共代理服务器的来源页面(有详细的ip等信息)),不知道这样是否可行?(主要还是为了防止被他人滥用此ip来进行破坏和编辑战) 咸鱼老李留言) 2018年12月9日 (日) 11:15 (UTC)回复[回复]

為甚麼Help:如何访问维基百科m:Help:如何访问维基媒体旗下项目裡提供的網址有問題

為甚麼text-lb.(資料中心名).wikimedia.orgupload-lb.(資料中心名).wikimedia.org會憑證會解析錯誤?-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 00:00 (UTC)回复[回复]

“會憑證會解析錯誤”,每一个字都懂,但是整句话就看不懂了。大陆测试过,4和6的地址都能解析出。“(資料中心名)”指上面五个数据中心的标示名。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 05:26 (UTC)回复[回复]
@Cwek:隨手亂打的,其實是為甚麼無法辨識憑證?-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 06:07 (UTC)回复[回复]
TLS证书吗?没发现问题。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 06:11 (UTC)回复[回复]
ex:https://text-lb.ulsfo.wikimedia.org/會返回

User:Cwek-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 09:07 (UTC)回复[回复]

正常啊,因为这些证书的CN和扩展域名都没有包括wikimedia.org的多级子域名。可以理解为a.com配了b.com的证书,只不过b.com的a记录指向a.com的地址。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 09:22 (UTC)回复[回复]
User:Cwek那要去哪裡根基金會反映?順帶一提,可不可以使用{{ping}}回覆一下?-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 10:45 (UTC)回复[回复]
嗯,说得难听的,我感觉你是技术不太全懂但又瞎操心。没必要,这是设计需要,这些IP配置的域名相当于一种方便自动管理的管理用域名,也就是说,证书的域名配置是无问题的,而这些IP的域名是方便基金会管理这些这些IP而设置,证书上不配置这些域名并无必要。例如国际大型ISP的路由设备的IP地址也配置了域名,但是实际路由并不需要这些域名,更多是企业内部方便管理的作用(例如结合域名识别IP设备的部署位置、管理控制等)。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 12:32 (UTC)回复[回复]
User:Cwek因為現在是Google Chrome擋掉不給過,Internet Explorer也不給過,甚麼都不給過-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 13:01 (UTC)回复[回复]
没发现证书有问题,说一下你在研究什么技术?我是直接用代理附带的端口转发能力,直接通过加密代理出去,然后转发到基金会的地址上。证书一切正常,除了需要用内网DNS修正域名到内网的端口转发地址上。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 13:16 (UTC)回复[回复]
代理或許沒這個問題,但台灣又沒有GFW當然是直連的User:Cwek-- Sunny00217 --維基餐廳開幕了,歡迎參觀。 2018年12月2日 (日) 13:29 (UTC)回复[回复]
如果在台湾的话,折腾这个域名没用的。这个域名主要是给基金会用来管理设备用的,或者给我们大陆找IP的小作弊方法。直接访问这个域名是没用的。——路过围观的Sakamotosan | 避免做作,免敬 2018年12月2日 (日) 13:58 (UTC)回复[回复]
那么就应该说明那个域名是给谁用的啊。看正文看不出来跟大陆有关:)我知道这里有尽量委婉的需求,不过也应该保证尽量让人看懂吧。 --122.211.109.58留言) 2018年12月5日 (三) 02:54 (UTC)回复[回复]
我觉得这种技术性数据,基金会不会主动告诉你是什么,或者怎么用。(我也怀疑最初是有人检查这些IP与域名信息时偶然发现关联?)就像那些国际大型ISP那样,也不会公开解释路由器设置的域名有什么用。(更何况中国电信大部分路由设备或者终端IP连这个域名都不设的)——路过围观的Sakamotosan | 避免做作,免敬 2018年12月5日 (三) 06:02 (UTC)回复[回复]

昨天2620:0:861:ed1a::1和2620:0:863:ed1a::1都被屏蔽了

昨天(2019年1月18日下午)2620:0:861:ed1a::1和2620:0:863:ed1a::1都被屏蔽了,2620:0:862:ed1a::1和2001:df2:e500:ed1a::1还可用。2001:4860:4860::8888也被屏蔽了。其他人可以用以上IP直连吗?--Midleading留言) 2019年1月19日 (六) 01:44 (UTC)回复[回复]

刚刚2620:0:862:ed1a::1也屏蔽了。--Midleading留言) 2019年1月19日 (六) 10:46 (UTC)回复[回复]
晚上,2001:df2:e500:ed1a::1被屏蔽了,这样维基百科将无法通过IPv6访问。--Midleading留言) 2019年1月19日 (六) 14:16 (UTC)回复[回复]
初步测试了,除了新加坡外,其他只要是接入教育网的都不行。暂时发现联通都能ping通。可用性不明。——路过围观的Sakamotosan | 避免做作,免敬 2019年1月24日 (四) 02:53 (UTC)回复[回复]
刚刚测试,目前电信对以上ip均可ping通--Space Timee留言) 2022年4月20日 (三) 13:02 (UTC)回复[回复]

能不能在IIS上搭建反向代理

如题,手头上没有Nginx,也懒得装(懒癌晚期)……忒有钱留言) 2019年2月11日 (一) 14:08 (UTC)回复[回复]

GFW在测试新功能???

我平时通过修改Hosts上中文维基百科,然而这次按照先上英文维基再上中文维基的顺序访问中文维基百科的时候,中文维基百科却打不开了,Firefox显示“连接被重置”或者“连接超时”,同时连带所有维基媒体的项目都上不去了,错误提示和访问中文维基时一样。以上情况并非每次都发生,而是有一定概率的,各位遇到这类情况了吗?难道是GFW在测试新功能?--侧耳倾听 2019年3月23日 (六) 15:44 (UTC)回复[回复]

  • @Whisper of the heart:有同样问题,不过我用的是1.1.1.1的DoH,现在只有科学上网了。。。(一开始我还以为1.1.1.1挂了)-- by  ✉  DW  at 2019年3月23日 (六) 19:09 (UTC)回复[回复]
    • @DW_YoungDLS:我又多试了几次,坚持直连的话也不是不可以,最终总会成功的,不过过程挺折磨人,能科学上网的话体验肯定更好。--侧耳倾听 2019年3月24日 (日) 13:06 (UTC)回复[回复]
  • 会话保存机制有点取巧,你很难保证上完en后还是用回en的TLS链接连接zh,这样还是会遇到SNI RST。——路过围观的Sakamotosan | 避免做作,免敬 2019年3月24日 (日) 02:06 (UTC)回复[回复]
  • 现在是有间歇性中断,所有专案都会卡断。没有有效大型支援的话,根本无法抗衡这些动作。——約克客留言) 2019年3月24日 (日) 04:48 (UTC)回复[回复]
  • 这已经很久了其实,见WP:如何访问维基百科 --------来自一个 温暖的胖子 ,还有,User:胡葡萄 是我的搭档! 2019年3月26日 (二) 16:38 (UTC)回复[回复]
    • @橙子木:这次的情况又不一样了,以前是开一下英文维基百科就可以了,这次是开了中文维基百科后连着英文维基都会被重置,需要等一段时间才能继续。--侧耳倾听 2019年3月31日 (日) 02:16 (UTC)回复[回复]
  • 咋没人来讨论呢,难不成都是用VPN的翻墙党?--侧耳倾听 2019年3月31日 (日) 03:14 (UTC)回复[回复]
    • 不建议利用握手缓存访问zhwp,早在刚刚上SNI的时候我也试过,但是发现提交编辑很难,所以我很早就放弃了。另外,墙也不是不知道有这种操作。现在我电脑用本地反代大法,手机用VPN。--№.N留言) 2019年4月2日 (二) 00:39 (UTC)回复[回复]
  • 我也遇到了。另外现在 GFW 确实有所变化,Google 的 IP 封了不少。--石𫁶留言) 2019年3月31日 (日) 09:36 (UTC)回复[回复]
  • 其实真的想要不挂代理稳定上维基的话,推荐本地反代(可正常登陆编辑)。但是性能波动大,有时比代理快,有时比代理慢,我个人是在代理失效的情况下使用的。(GitHub上有人发布了现成的)--☣甲乙丙丁戊留言) 2019年4月4日 (四) 03:31 (UTC)回复[回复]

英文维基百科疑似被DNS污染

今天(2019年4月23日)访问英文维基百科显示超时,DNS解析显示地址被解析至Facebook等网站。本人在广州教育网内,但是通过ping检测工具发现是全国性问题。目前未见SNI检测。不知是暂时故障还是被安排上了 120.236.174.159留言) 2019年4月23日 (二) 02:42 (UTC)回复[回复]

大概率是安排上了(近些年来几乎没听说过有哪个网站封了一段时间又解封的),而且不止英文维基百科,试了ping下韩文维基百科也是如此。--№.N留言) 2019年4月23日 (二) 02:53 (UTC)回复[回复]
真可惜,英文也GG了——Thyj (通知我) 2019年4月23日 (二) 06:57 (UTC)回复[回复]
这个改动之后目前暂时正常了,不过不排除近期访问情况有再次发生变化的可能。--№.N留言) 2019年4月24日 (三) 02:46 (UTC)回复[回复]
更新:目前墙已经针对这个改动做出及时调整,全部语种维基百科再次无法访问。--№.N留言) 2019年4月24日 (三) 03:33 (UTC)回复[回复]
好像现在不止DNS了,连SNI RST也用上去了。--№.N留言) 2019年4月24日 (三) 13:51 (UTC)回复[回复]
确实,用Google Chrome连接时显示是RESET型的报错,看来确实是安排上了。--User:Yatogamihoza留言) 2019年4月24日 (三) 14:07 (UTC)回复[回复]
似乎从Commons绕过去还行,当然迟早还是得用上本地反代,甚至VPN --120.236.174.170留言) 2019年4月24日 (三) 15:59 (UTC)回复[回复]
好像确实可以,这跟当年的游击战没啥区别了(无奈)--User:Yatogamihoza留言) 2019年4月25日 (四) 14:23 (UTC)回复[回复]

如果还是上不了,以后貌似只能看垃圾百度百科了——Thyj (通知我) 2019年4月25日 (四) 03:22 (UTC)回复[回复]

自从知道了维基,再也没去过垃圾百度百科一次,真实粪堆。--User:Yatogamihoza留言) 2019年4月25日 (四) 14:25 (UTC)回复[回复]
赞同楼上观点,百度现在变成百毒了--User:Raindrops2005留言) 2019年4月27日(六)11:13 (UTC)
我就想知道现在修改HOST还能上吗,现在用的代理很慢——2A00:E60:7000:100:6:0:0:1留言) 2019年5月2日 (四) 10:08 (UTC)回复[回复]
从其他维基媒体上跳转吧,跟以前从其他语言维基百科跳转一个道理。--User:Yatogamihoza留言) 2019年5月7日 (四) 03:39 (UTC)回复[回复]

现在连共享资源、数据库也上不了了 囧rz……——Thyj (通知我) 2019年5月9日 (四) 04:46 (UTC)回复[回复]

现在应该是只是DNS污染,未来不久应该会上SNI RST或者直接IP封锁。如果是后者,那么大陆维基人全体VPN的时代即将到来。--№.N留言) 2019年5月9日 (四) 04:53 (UTC)回复[回复]
看起来是 CNAME 到 www.wikipedia.org 导致的污染扩大。使用国外 DNS 服务器这些域名可以获得正确的结果。 lilydjwg 交流 2019年5月9日 (四) 05:13 (UTC)回复[回复]
phab:T208263这个修改有关,某位程序认为应该将所有域名CNAME到一个特定域名,来优化各域名的缓存时间。起初在wikipedia.org根域做测试,结果先是DNS直接污染,跟着是整个根域被SNI RST了,由于无法判断是不是和这个CNAME修改有关,推测只是偶然相关。现在他测试全部CNAME到www.wikipedia.org,而www.wikipedia.org是被污染的,现在我怕CNAME传染的理论是正确的,所以有必要的请多多去反对,这种优化太吃力不讨好了。——路过围观的Sakamotosan | 避免做作,免敬 2019年5月9日 (四) 06:51 (UTC)回复[回复]
@Cwek:我觉得优化还是有必要的,所以我想可以让他CNAME到没有DNS污染的域名(比如说www.wikimedia.org)。-- FL.YL.BANxS留言) 2019年5月9日 (四) 11:32 (UTC)回复[回复]
姑且我认为有些可以的冒险,可以测试下CNAME会不会导致污染扩散(正如我所说,是几乎全部对外域名),但一旦证实的话,以为如User:Liu116所说的。——路过围观的Sakamotosan | 避免做作,免敬 2019年5月9日 (四) 12:03 (UTC)回复[回复]
最初是CNAME到wikipedia.org,然后*.wikipedia.org被封锁。因此我认为如果封锁会随CNAME扩散,这样做的话封锁应该会扩散到*.www.wikimedia.org而不是所有项目。-- FL.YL.BANxS留言) 2019年5月9日 (四) 12:30 (UTC)回复[回复]
其实我想说的是,与其让未被封锁的域名CNAME到被封锁的域名,不如让未被封锁的域名CNAME到未被封锁的域名。-- FL.YL.BANxS留言) 2019年5月9日 (四) 12:43 (UTC)回复[回复]

提议删去Help:如何访问维基百科中的无效方法

去年8月末中国大陆部署了SNI RST,自那时起就无法单纯透过修改 hosts 访问维基百科。现在Help:如何访问维基百科页面趋于臃肿。

针对该帮助页,2.1节下添加绕过SNI RST的方法,删去2.2节以及所有失效的镜像网站(Help:如何访问维基百科#镜像网站,引用自WP:维基百科拷贝网站)。--YouTable 2019年5月1日 (三) 09:00 (UTC)回复[回复]

我觉得删掉没问题,现在的确实太复杂,一下子搞不明白哪个可以用。H:HOSTS 这个快捷方式可以考虑取消章节重定向,就到这个页面本身。 --砜中嘌呤的白磷萃取 打谱 2019年5月1日 (三) 07:28 (UTC)回复[回复]

其实修正域名解析那一节已经有绕过SNI RST的方法了。DNS那一节还有IPv6 DNS和中科大DNS(目前可用,虽然划掉了)可用。-- FL.YL.BANxS留言) 2019年5月1日 (三) 09:15 (UTC)回复[回复]

(:)回應:那就把 hosts 整节删了(或是移到下面),把下面的本地反代移上来。不然过于混乱,无法让读者直观地知道到底哪些能用哪些不能用。--YouTable 2019年5月1日 (三) 09:38 (UTC)回复[回复]
Hosts比其他方法更加稳定,因为DNS和DoT/DoH的服务器容易被封,所以不能删,而且最稳定的方法应该放到前面。 -- FL.YL.BANxS留言) 2019年5月1日 (三) 09:51 (UTC)回复[回复]
但现在直接改hosts在中国大陆不可用。--YouTable 2019年5月1日 (三) 09:54 (UTC)回复[回复]
怎么不可用?Hosts、DNS、DoT/DoH的作用都是一致的,都用于得到不受污染的DNS结果。然后绕过SNI RST。-- FL.YL.BANxS留言) 2019年5月1日 (三) 09:59 (UTC)回复[回复]
也就是说,改hosts还是用DNS或DoT/DoH的效果是一样的。-- FL.YL.BANxS留言) 2019年5月1日 (三) 10:08 (UTC)回复[回复]
直接改hosts确实不可用,但是修正域名解析这个章节所提供的方法都不能直接使用,都需要绕过SNI RST。但是Hosts不需要经过服务器,所以相对于其他方法来说Hosts更稳定。-- FL.YL.BANxS留言) 2019年5月1日 (三) 13:32 (UTC)回复[回复]
应该直观地提供有效的方法。应该把下文的本地反代移上来,其余的需要另外采取措施绕过SNI RST的放下面去。这个帮助页的目的就是为了解决如何访问维基百科,所以理应把有效的方法放在显要位置。--YouTable 2019年5月1日 (三) 20:35 (UTC)回复[回复]
本地反代可以移上来。同时可以把DoT/DoH移到DNS前面。-- FL.YL.BANxS留言) 2019年5月2日 (四) 01:19 (UTC)回复[回复]
其实修正域名解析+这种脚本就比较方便了。-- FL.YL.BANxS留言) 2019年5月2日 (四) 01:48 (UTC)回复[回复]
虽然这种方法不如本地反代可靠,但是无法搭建本地反代的设备(如未root或越狱的移动设备)可以用。-- FL.YL.BANxS留言) 2019年5月2日 (四) 02:13 (UTC)回复[回复]
其实本地反代有安全性问题,因为nginx连接上游服务器时不验证证书(因为不发送SNI而且证书不能包含IP地址,所以即使没受到攻击证书也会无效,所以只能不验证)。而修正域名解析+绕过SNI RST是直接与服务器建立连接而且带上SNI,从而可以验证服务器证书是否有效。-- FL.YL.BANxS留言) 2019年5月2日 (四) 06:43 (UTC)回复[回复]
说错了,是先访问没被SNI RST的域名得到证书缓存,然后用证书缓存建立连接。-- FL.YL.BANxS留言) 2019年5月2日 (四) 04:01 (UTC)回复[回复]
举个例子:
  • 不安全连接(类似于nginx本地反代的访问方法):curl https://198.35.26.96 -H 'Host: zh.wikipedia.org' -v -k,直接用IP地址发起连接;忽略证书错误。
  • 安全连接:curl https://mediawiki.org -H 'Host: zh.wikipedia.org' -v,用没被SNI RST的域名发起连接;简单的域前置方法,普通的浏览器做不到。 -- FL.YL.BANxS留言) 2019年5月2日 (四) 06:43 (UTC)回复[回复]
纠正一下,本地反代并非只有nginx那个方法,如使用Accesser,默认情况下就会校验证书,以保证安全。-- 几何原本 2019年5月2日 (四) 06:35 (UTC)回复[回复]
那这样就没关系了。-- FL.YL.BANxS留言) 2019年5月2日 (四) 06:43 (UTC)回复[回复]
(&)建議将长期无效的镜像站存档。--及时雨 留言 2019年5月1日 (三) 13:07 (UTC)回复[回复]
可以,既然无效了留着也没什么用。-- FL.YL.BANxS留言) 2019年5月1日 (三) 13:32 (UTC)回复[回复]
无效应该分为被封锁的网站和完全关闭的,仅仅被封锁的网站留在Wikipedia:维基百科拷贝网站(不嵌入Help:如何访问维基百科),完全关闭的网站应该删除。—以上未簽名的留言由2001:da8:201:3512:bce6:d095:55f1:36de對話貢獻)於2019年5月1日 (五) 15:31 (UTC)加入。回复[回复]
存档还不如删去,编辑历史可见。--YouTable 2019年5月3日 (五) 02:36 (UTC)回复[回复]

FL.YL.BANxS已经把本地反代一节移上来了。目前无效镜像的去留还需要讨论。现计划删去所有已经失效的镜像网站。有其他意见者请提出,也请较早前发表过意见的User:FL.YL.BANxSUser:WhitePhosphorus发表意见,谢谢。--YouTable 2019年5月3日 (五) 03:52 (UTC)回复[回复]

我认为可以先把所有的红标网站加上<noinclude>,然后再把真正关闭的网站删除。-- FL.YL.BANxS留言) 2019年5月3日 (五) 11:05 (UTC)回复[回复]
@FL.YL.BANxS:如何查证?--YouTable 2019年5月4日 (六) 02:23 (UTC)回复[回复]
对域名进行DNS查询,然后把NXDOMAIN(域名无解析记录)的删除。剩下的用代理访问,然后把打不开或停止服务的网站删除。-- FL.YL.BANxS留言) 2019年5月4日 (六) 03:25 (UTC)回复[回复]
現在Help:如何访问维基百科#镜像网站已經沒有紅色了(被<noinclude></noinclude>了)-- Sunny00217 - 2019年5月4日 (六) 13:42 (UTC)回复[回复]

修改火狐浏览器关于SNI的部分

以下是火狐浏览器源代码中关于SNI的ClientHello语句生成函数,是一个关键性函数,通过浏览器发送的任何SNI请求都必须经过此函数生成ClientHello。这个函数来自于火狐浏览器源代码文件系统下的security/nss/lib/ssl/sslext3.c文件:

/* Format an SNI extension, using the name from the socket's URL,
 * unless that name is a dotted decimal string.
 * Used by client and server.
 */
PRInt32
ssl3_SendServerNameXtn(sslSocket * ss, PRBool append,
                       PRUint32 maxBytes)
{
    SECStatus rv;
    if (!ss)
        return 0;
    if (!ss->sec.isServer) {
        PRUint32 len;
        PRNetAddr netAddr;

        /* must have a hostname */
        if (!ss->url || !ss->url[0])
            return 0;
        /* must not be an IPv4 or IPv6 address */
        if (PR_SUCCESS == PR_StringToNetAddr(ss->url, &netAddr)) {
            /* is an IP address (v4 or v6) */
            return 0;
        }
        len  = PORT_Strlen(ss->url);
        if (append && maxBytes >= len + 9) {
            /* extension_type */
            rv = ssl3_AppendHandshakeNumber(ss, ssl_server_name_xtn, 2);
            if (rv != SECSuccess) return -1;
            /* length of extension_data */
            rv = ssl3_AppendHandshakeNumber(ss, len + 5, 2);
            if (rv != SECSuccess) return -1;
            /* length of server_name_list */
            rv = ssl3_AppendHandshakeNumber(ss, len + 3, 2);
            if (rv != SECSuccess) return -1;
            /* Name Type (sni_host_name) */
            rv = ssl3_AppendHandshake(ss,       "\0",    1);
            if (rv != SECSuccess) return -1;
            /* HostName (length and value) */
            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)ss->url, len, 2);
            if (rv != SECSuccess) return -1;
            if (!ss->sec.isServer) {
                TLSExtensionData *xtnData = &ss->xtnData;
                xtnData->advertised[xtnData->numAdvertised++] =
                    ssl_server_name_xtn;
            }
        }
        return len + 9;
    }
    /* Server side */
    if (append && maxBytes >= 4) {
        rv = ssl3_AppendHandshakeNumber(ss, ssl_server_name_xtn, 2);
        if (rv != SECSuccess)  return -1;
        /* length of extension_data */
        rv = ssl3_AppendHandshakeNumber(ss, 0, 2);
        if (rv != SECSuccess) return -1;
    }
    return 4;
}

其中关键性的代码为如下两行:

        len  = PORT_Strlen(ss->url);

以及:

            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)ss->url, len, 2);

其中ss->url是目标网站域名,也就是SNI的域名(也就是唯一可以被墙看见的那个域名)。为只读变量,不能修改(而且也不应该被修改,因为后续收到安全证书以后必须要能对上安全证书里的域名列表里的某一个域名,而且再后续进行HTTPS GET操作时就必须要有正确的域名才能取得正确的网页和内容)。

但是(我要说但是了!)我们可以把在以上两行里的ss->url完全替换成【另外】的一个string literal(也就是所谓的“hard-coding SNI”)。比如以下两种修改:

        len  = PORT_Strlen("wikimedia.org\0");

            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)"wikimedia.org\0", len, 2);
        len  = PORT_Strlen("\0");

            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)"\0", len, 2);

都能通过编译器编译,生成火狐浏览器的目标文件(object files)以及可执行二进制文件(binary executable)。我对以上两种情况分别进行了实验,有以下发现:

  • 如果hard-code空字符串\0,那么所有HTTPS连接一律报错,没有例外,也就是说如此编译出来的浏览器是完全废掉了。(这种情况对应于“SNI拔除”,也就是试图把现代火狐浏览器恢复到火狐浏览器1.0时代不发送SNI信息,现在看来这种方法完全行不通了)
  • 如果hard-code维基媒体总站域名,那么在我测试的网站中,除了Cloudflare网站不能正常工作,其它网站都能正常工作。特别有趣的是对谷歌发送维基媒体总站域名SNI也能得到正确的谷歌证书,成功打开google.com,而浏览器不会报错。(这种情况对应于域名前置,当然都是维基媒体的域名,所以应该也无所谓,不存在欺骗性质,和被亚马逊和谷歌禁止的那种域名前置行为有本质上的区别)

甚至可以做出如下修改:

char url[500];
scanf("%s", url);

        len  = PORT_Strlen(url);

            rv = ssl3_AppendHandshakeVariable(ss, (PRUint8 *)url, len, 2);

当然,以上修改后的火狐浏览器需要从xterm终端里启动,否则没法输入字符串。我个人从未做出或者测试过以上修改。但是我相信以上的修改是最最灵活的,因为允许用户在运行火狐浏览器的时候自行键入想要送出的明文SNI域名。

很可惜,我身在墙外,所以完全不知道这些修改能不能规避墙的SNI重置封锁。但是如果墙内朋友证实这些修改是可行的话,那么这将是非常powerful的修改。这些修改将允许墙内网友浏览维基百科直到墙SNI封杀【最后一个】维基媒体域名(现在除了维基百科和维基新闻以外基本上所有其它维基媒体域名都未被墙封杀)。而且墙内网友可以直接打开维基百科,而不需要先打开比如维基文库,然后利用HTTPS信道余热来打开维基百科。

不爱思考得猪留言) 2019年5月17日 (五) 20:44 (UTC)回复[回复]

会编译,看得懂代码的人为什么需要这个...--Fantasticfears留言) 2019年5月17日 (五) 21:34 (UTC)回复[回复]
其实说实话这是一个比较针对维基媒体的特定修改,而且可能也用不了多久了。墙不知道为什么没有对维基媒体进行全面封杀,而是只封杀了维基新闻和维基百科两类域名。以上的修改就是利用剩下的、未被封杀的维基媒体域名进行一种类似域名前置的操作,使得墙内用户在不翻墙的情况下依旧可以使用维基百科。但是说实话我个人是不太看好这个hack的,因为我认为墙应该即将封杀所有维基媒体域名了,甚至可能会对维基媒体的服务器群进行彻底IP封杀。不爱思考得猪留言) 2019年5月17日 (五) 23:20 (UTC)回复[回复]
其实就是,一种是SNI拔除,一种是类似域前置的方法。曾经有讨论过,不过需要定制化的客户端,只能适合硬核玩法。至于域前置的做法,好像有几家CDN不再支持了,为了防止Telegram等利用。——路过围观的Sakamotosan | 避免做作,免敬 2019年5月18日 (六) 00:52 (UTC)回复[回复]

Success!!! This is 不爱思考得猪. I have tunneled back inside the Great Firewall of China using PureVPN's Shanghai server. I have tested and verified that the above changes I have made to Firefox's source code really worked (together with relevant changes to /etc/hosts). Right now I am accessing zh.wikipedia.org with SNI wikimedia.org. I do apologize for posting this exciting update in English as my Firefox testing environment is Ubuntu Linux, so I cannot input Chinese. Look at my signature and you can see that the IP address is located in Shanghai. I am so happy right now! 101.226.196.139留言) 2019年5月19日 (日) 19:58 (UTC)回复[回复]

成功啦!成功啦!昨天我订购了PureVPN服务,PureVPN有服务器在上海,连上去了以后果然就是墙内的环境。我修改的火狐浏览器是在Ubuntu上运行的,所以刚才成功了以后留言记录证明连接成功只能打洋文了。要注意的是我对于火狐浏览器的修改必须要搭配/etc/hosts修改才行。在修改了/etc/hosts以后,运行Ubuntu内置火狐浏览器,就会收到“SNI Reset”错误信息。而运行我修改的火狐浏览器,则可以在未打开wikimedia.org的情况下直接打开zh.wikipedia.org,而且速度良好。今天我真是太高兴啦!这个修改应该可以一直使用到墙封杀维基媒体旗下的最后一个域名。不爱思考得猪留言) 2019年5月19日 (日) 20:27 (UTC)回复[回复]

你很厉害嘛。但你如果不编译出来的话,我们这些小白可是用不了呢。不过Firefox升级后就又不能用了吧。虽然我有其他方法啦。--1=0欢迎加入WP:維基百科維護專題 2019年5月19日 (日) 23:19 (UTC)回复[回复]
多谢Misel兄夸奖!我下来琢磨琢磨如何编译出视窗平台上的火狐目标文件、库文件、可执行文件。不爱思考得猪留言) 2019年5月20日 (一) 13:37 (UTC)回复[回复]
其实说实话我到现在也没有在视窗平台上开发过任何正经程序。习惯了在Linux上码农,Linux的确比视窗对码农更加友好。不爱思考得猪留言) 2019年5月20日 (一) 14:51 (UTC)回复[回复]
我修改的火狐浏览器和Firefox主线升级没有任何关系。主线Firefox升级了以后,我修改的火狐浏览器还是能够正常工作的,只不过就是版本老一些而已。不爱思考得猪留言) 2019年5月20日 (一) 14:53 (UTC)回复[回复]
或者将这个做成一个可以外部配置读取的配置文件,判断域名是否需要SNI修正,不需要的话就照常,需要的话就修正。不过还是那句,硬核玩法。——路过围观的Sakamotosan | 避免做作,免敬 2019年5月20日 (一) 01:20 (UTC)回复[回复]
多谢cwek兄的建议,我试着创造一个外部配置读取的配置文件。同时我再实验几种其它的灵活改变SNI方法看看效果如何。不爱思考得猪留言) 2019年5月20日 (一) 13:37 (UTC)回复[回复]

各位,我已经上了Mozilla-Dev瞄了几眼,在视窗上编译火狐浏览器需要40个G的空间。我现在使用的视窗笔记本电脑💻没有这么多空间(因为是固态硬盘SSD),所以明天我先要去Best Buy买一台新的笔记本电脑💻,以传统旋转磁硬盘(HDD)为主(这样空间足够大),然后再开始安装Visual Studio等视窗编译环境,然后开始修改视窗版火狐浏览器源代码,然后开始编译视窗版火狐浏览器。整个过程最长可能要花上几个礼拜的时间。所以这段讨论基本上可以存档到“如何访问维基百科”里面了,等我以后有更新了再开一个新话题告知修改版视窗火狐浏览器的下载地址。不爱思考得猪留言) 2019年5月20日 (一) 17:23 (UTC)回复[回复]

如何确保分发的二进制文件中仅有相关部分被改变?-Mys_721tx留言) 2019年5月20日 (一) 21:21 (UTC)回复[回复]
哈哈,这位兄台问的问题很好,以下是我的一些想法:
  • 我以人格担保,我修改的火狐浏览器里绝对不夹杂私货!(当然这是最最薄弱的一种说辞)
  • 你可以把我分享的文件与官方发行版火狐浏览器文件做一个二进制diff,你会观察到唯一的不同就是libssl3.so(视窗上应该是libssl3.dll),而且你把不同的那些字节调出来进行反汇编(disassembly)以后会发现反汇编出来的那些指令正是我所添加的C语句的x64汇编语言版本。(当然这么做对于很多人来说是非常有难度的)
  • 最好的方法当然是你自己去下载火狐官方源代码,自己去到ssl3ext.c里做出修改,然后自己为自己编译一个火狐浏览器。这也就是为什么我这么详细的把要具体修改的东西在本客栈里贴出。我的初衷是让所有人自行去修改源代码然后编译,因为我真的不觉得这么做有任何难度(特别是当我已经为你们摸清楚了源代码里究竟是哪个函数在控制着SNI)。
  • 还有就是把这个功能要求Mozilla添加到Nightly里面去。(我不认识Mozilla的人,而且这种修改基本上不可能被Mozilla接受。)
如果其它维基人还能想出什么好的保证机制请自由的往以上列表里添加。不爱思考得猪留言) 2019年5月21日 (二) 01:40 (UTC)回复[回复]


这其实等价于挂个HAProxy反向代理,然后中间人篡改下SNI……写几行配置就成,还不用重新编译。--菲菇维基食用菌协会 2019年5月20日 (一) 23:41 (UTC)回复[回复]

哇!😍😍😍😍😍😍😍😍😍😍😍😍真的吗?!那么还烦请菲菇兄能在本楼贴出使用反向代理篡改SNI的详细具体操作教程,以及兄所说的那几行配置。就像我在本楼里具体精确的指出需要修改火狐浏览器源代码的哪一个文件里的哪一个函数里的哪几行代码,以及怎么修改那几行代码。谢谢!不爱思考得猪留言) 2019年5月21日 (二) 01:46 (UTC)回复[回复]
奇技淫巧,不如肉翻。--菲菇维基食用菌协会 2019年5月21日 (二) 05:54 (UTC)回复[回复]
菲菇兄这话说的在理儿!不爱思考得猪留言) 2019年5月21日 (二) 13:09 (UTC)回复[回复]

半突发新闻

text-lb的旧金山节点地址疑似上名单了,大致时间为12月1日(见Help:如何访问维基百科历史)。请自行按需技术调整。 囧rz...——路过围观的Sakamotosan | 避免做作,免敬 2019年12月1日 (日) 12:14 (UTC)回复[回复]

维基媒体域名被DNS污染了吧,如mediawiki.orgwikidata.org--Zyksnowy留言) 2019年12月1日 (日) 19:12 (UTC)回复[回复]
没有发现污染,只是大部分站点使用了统一缓存CNAME地址,而那个地址对于中国大陆访问最近的是旧金山缓存点。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月2日 (一) 00:43 (UTC)回复[回复]
另外补充,现在海缆中断频发,电信已确定去wmf的路由(也就是zayo的线路)全部绕欧洲。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月2日 (一) 01:02 (UTC)回复[回复]
墙IP只是时间问题,近些年来墙多次干扰维基媒体基金会项目的访问,相信不久的将来维基百科的封锁级别会向Google看齐。--求🔨得🔨 2019年12月2日 (一) 01:16 (UTC)回复[回复]
近期墙动作也是不少,以前用来存档的archive.is只是DNS污染,周末的时候发现也上了SNI了。--求🔨得🔨 2019年12月2日 (一) 01:20 (UTC)回复[回复]
其实SNI和以前的明文HTTP没太大差别。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月2日 (一) 02:13 (UTC)回复[回复]
另外,还是那句:莫猜朕意,猜不透的。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月2日 (一) 02:13 (UTC)回复[回复]
趁IP还存活,推荐大家个工具TCPioneer,和INTANG工作原理相似通过修改发出的TCP包来避免SNI检测,所以没有MITM没有代理,可以访问包括Google在内所有被SNIRST的网站。——Macronut wiki留言) 2019年12月3日 (二) 01:41 (UTC)回复[回复]
记得Google是直接封IP的。--求🔨得🔨 2019年12月5日 (四) 01:32 (UTC)回复[回复]
自从ip被封后我就把ip的最后一个字节左右移几位来ping,想看一下有没有邻近服务器,结果还真有,比如说198.35.26.96的最后一个字节是96,+1就是97:curl https://www.mediawiki.org/ --connect-to ::198.35.26.97: -v4。以此类推,在大部分IPv4的text-lb可用(eqiad不行,IPv6未测试)。看起来应该是基金会的服务器吧,毕竟TLS证书都是有效的。-- FL.YL.BANxS留言) 2019年12月6日 (五) 04:08 (UTC)回复[回复]
看了下反向DNS,是test-lb.ulsfo.wikimedia.org,看起来是测试服务器?-- FL.YL.BANxS留言) 2019年12月6日 (五) 04:27 (UTC)回复[回复]
我3日就测出来了。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月6日 (五) 06:35 (UTC)回复[回复]
欧洲节点也有类似的test入口。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月9日 (一) 01:54 (UTC)回复[回复]
更准确来说,是每个节点都有一个这样的入口。——路过围观的Sakamotosan | 避免做作,免敬 2019年12月9日 (一) 03:02 (UTC)回复[回复]

维基百科全站已经解封?!

中国移动ip实测,不论英文版中文版法语版粤语版,不论网页移动,甚至是某些敏感词条,皆能够正常打开。 由于疫情关系忘记封锁了?!可是,例如维基新闻能打开,维基学院,维基文库,维基教科书等等又不行.. ps..我这是ipv4测试. 使用明文版链接会自动跳转到https正常访问.—以上未簽名的留言由113.20.22.116對話)於2020年4月2日 (四) 10:55 (UTC)加入。回复[回复]

坐标广东也是中国移动ipv4实测百科,新闻已经全站解封,其他的未测试—以上未簽名的留言由23.130.224.40對話)於2020年4月17日 (五) 09:09 (UTC)加入。回复[回复]

5月中又封了。--一片🍁枫叶DC18#3000编辑,冲啊!#热烈庆祝珠机城际通车! 2020年8月20日 (四) 12:42 (UTC)回复[回复]

请问维基百科是何时被封IP的?

印象当中好像很长一段时间是DNS污染,后来升级成了SNI封杀。近期查询“如何访问维基百科”页面,赫然发现所有项目都打叉了。推断维基百科乃至整个维基媒体的服务器都被封杀IP了。所以想来询问一下究竟是什么时候的事情?

另外维基百科有没有意向使用Cloudflare的CDN网络进行托管?

172.97.161.17留言) 2020年3月13日 (五) 23:14 (UTC)回复[回复]

对技术小白而言,你们自然有方法去粗暴解决这些问题,细节了解也没有啥意义。对于非技术小白的话,关注Help_talk:如何访问维基百科能了解一些最新情况,而且我们也很及时地Help:如何访问维基百科的信息,对吧。(微笑)——路过围观的Sakamotosan | 避免做作,免敬 2020年3月14日 (六) 02:56 (UTC)回复[回复]
CDN好像有人讨论过,好像是涉及隐私问题。其实现在多个缓存点就是相当于CDN机制。只是不在国内建立接入点,没特别配置的线路一样烂,就算你挂Cloudflare也一样。Cloudflare在中国和百度合作有接入点,不过同样需要行政审核申请。如果不用中国接入点,移动最近可以去香港的接入点,但电信的只能去美国旧金山,至于去美国的普通线路……嗯,你懂的。——路过围观的Sakamotosan | 避免做作,免敬 2020年3月14日 (六) 02:56 (UTC)回复[回复]
CDN也可以搞keyless嘛。@Cwek:试试trace基金会几个DC的IP,它们都走了CF的路由。--Techyan留言) 2020年3月14日 (六) 18:39 (UTC)回复[回复]
吹牛打定好定稿先好不,或者看下wikitech:Network design再说好不?最多就买了专线来连接DC,但是有走cf的路由的有点浑水摸鱼或者纯粹瞎猜吧。——路过围观的Sakamotosan | 避免做作,免敬 2020年3月15日 (日) 01:51 (UTC)回复[回复]
俺选择tracert了下,部分节点真的走CloudFlare,也就是下面的两跳108.162.214.152。俺记得Twitter上有人号称把基金会DC打趴下过,俺估计是用来防止有人DDoS的。俺把tracert的最终几跳结果放在这里,供各位参考。--痛心疾首留言) 2020年3月16日 (一) 11:20 (UTC)回复[回复]
……
  8     *      163 ms     *     202.97.90.118
  9   154 ms   139 ms   139 ms  218.30.54.214
 10   164 ms   164 ms   164 ms  108.162.214.152
 11     *      162 ms     *     108.162.214.152
 12     *        *        *     请求超时。
 13   291 ms     *      261 ms  text-lb.eqsin.wikimedia.org [103.102.166.224]
有点意思,可能新加坡DC有接入cf而且也买了cf的承载?对于移动来说会开心,因为移动的出口在香港并有接入到香港交换中心,cf在香港交换中心也有接入,非常顺路。对于电信来说,没啥差别,美国本部还是走欧洲zayo,而去新加坡就是环太平洋游。 囧rz...可能需要问基金会确定?——路过围观的Sakamotosan | 避免做作,免敬 2020年3月16日 (一) 12:55 (UTC)回复[回复]
@痛心疾首:顺带一提,好像以前测试过新加坡的路由时,好像是走NTT的,从电信美国POP出来,转入美国NTT,跳回日本后,再跳新加坡。——路过围观的Sakamotosan | 避免做作,免敬 2020年3月16日 (一) 13:03 (UTC)回复[回复]
@痛心疾首:看起来如你所说的,有人想DDOS基金会的服务器,所以数据中心的营运商用了CloudFlare的网络(是定制服务)承载(或者说防DDOS)流量,但最终处理还是基金会的机器,看上去新加坡和欧洲使用了。——路过围观的Sakamotosan | 避免做作,免敬 2020年3月18日 (三) 00:36 (UTC)回复[回复]
就算考虑到keyless的话,如果不使用Cloudflare在中国的接入点,连接质量还是没保证吧。或者去元维基问下,毕竟这里只不过基金会的托管站,这样根本性的部署调整始终绕不开的。——路过围观的Sakamotosan | 避免做作,免敬 2020年3月15日 (日) 02:00 (UTC)回复[回复]
Cloudflare的个人版CDN会插入他们的Cookie,不知道商业版能否关闭。--泡泡小号028留言) 2020年3月15日 (日) 05:34 (UTC)回复[回复]

路由调整

  • 中国电信至新加坡、荷兰、旧金山三个节点不再经Cloudflare的网络承载(如果需要经Cloudflare网络,必须通过中国电信北美的公共POP出去)。也就是按往常路径,各走各路。
    • 新加坡节点会从日本的POP出去,通过NTT承载到新加坡的流量,这样就不用“环太平洋游”了。当然考虑到中国电信经NTT到日本的流量质量嘛……
  • 中国电信与zayo的连接仍然要绕欧洲。

承接“请问维基百科是何时被封IP的?”的讨论。——路过围观的Sakamotosan | 避免做作,免敬 2020年4月7日 (二) 06:27 (UTC)回复[回复]

    • Clouldflare开始做IP transit了?我还以为维基媒体开始吧自己的服务放在Cloudflare的云端上面了呢。--侧耳倾听 2020年4月16日 (四) 06:15 (UTC)回复[回复]
可能是“钱实在是太多了”(前面就提过,基金会的DC被人打,所以订了这款特殊服务。应该是为了让CF来做透明清洗?)——路过围观的Sakamotosan | 避免做作,免敬 2020年4月20日 (一) 02:16 (UTC)回复[回复]

美国旧金山的图片服务器 198.35.26.112 可能被封锁

用Accesser访问时发现无法载入图片,是upload.wikimedia.org无法连接,ping时域名解析正确,但显示连接超时。hosts改成新加坡的图片服务器后可以正常访问。 Whatsok(··) 2020年4月13日 (一) 14:12 (UTC)重庆中国联通回复[回复]

我这里图片显示是正常的,不过我用的二级运营商经常莫名其妙地就连接超时打不开了,估计是网络出口拥堵了,要等一等。--侧耳倾听 2020年4月16日 (四) 06:08 (UTC)回复[回复]
广东和重庆联通trace和tcp没发现问题。广州电信端口通,也没发现加载问题,不过端口的确偶然超时。可能真是出口拥堵。——路过围观的Sakamotosan | 避免做作,免敬 2020年4月16日 (四) 06:25 (UTC)回复[回复]
说的好像就是我这里这种情况。有些网络有时连得上,有时又超时。最明显的就是 fastly 了,cloudflare 也会偶尔超时或者非常慢,upload 这个以前好像还好好的,最近是TCP连接可以建立但是等不到回应了。lilydjwg 交流 2020年4月16日 (四) 09:01 (UTC)回复[回复]

图片服务器已被墙

各位维基百科人大家好:

特此报告,图片服务器(https://upload.wikimedia.org/ )已经被墙。希望可以更新一下Help:如何访问维基百科#IPv4连接报表里面的“图片服务器”一栏的连接勾勾。谢谢。

--162.211.224.40留言) 2020年5月9日 (六) 17:05 (UTC)回复[回复]

请看附属说明。单纯的 https://upload.wikimedia.org/ 是会被301到C区,而C区等没修正地址的确是有问题的。但通过图片访问的还是upload专用的地址,同样地upload 301之前的地址也是upload专用的地址,那个暂无发现问题。——路过围观的Sakamotosan | 避免做作,免敬 2020年5月11日 (一) 01:29 (UTC)回复[回复]
感谢cwek回复。我终于弄明白了。比如这个网址:https://upload.wikimedia.org/wikipedia/commons/3/37/Mud_Cow_Racing_-_Pacu_Jawi_-_West_Sumatra%2C_Indonesia.jpg 没有被墙。但是单单访问https://upload.wikimedia.org/ 是会被301到C区,而C区被墙。 162.211.224.40留言) 2020年5月11日 (一) 14:45 (UTC)回复[回复]

現在hosts和DoT都已失效

GFW可以執行SNI阻斷,只能望Wikipedia提供ESNI功能。 奧田95留言) 2020年6月8日 (一) 10:24 (UTC)回复[回复]

目前ESNI属于草案(即实验性功能),故支持此功能的希望渺茫。您可以通过本地反代非直接连接的方式(如:镜像网站)继续访问维基百科。 --安忆Talk 2020年6月20日 (六) 05:48 (UTC)回复[回复]

新加坡节点被墙

昨天晚上发现无法访问新加坡节点,站长之家ping测试发现中国大陆探测点几乎全部超时。5月20日晚间有一段时间也这样,不过持续时间没有多久又恢复了。--🔨留言) 2020年5月23日 (六) 01:48 (UTC)回复[回复]

先挂节点报废吧。感觉是不是滥用了SNI缓存机制导致被盯上了?——路过围观的Sakamotosan | 避免做作,免敬 2020年5月23日 (六) 02:47 (UTC)回复[回复]
而且两会、国安法加料版、6月活动临近,不可猜透啊。——路过围观的Sakamotosan | 避免做作,免敬 2020年5月23日 (六) 02:48 (UTC)回复[回复]
毕竟新加坡节点相对于其他的节点有距离上的优势。--🔨留言) 2020年5月23日 (六) 04:37 (UTC)回复[回复]
upload-lb也被ko了,103.102.166.240ping了半天ping不通。--Liuxinyu970226留言) 2020年5月23日 (六) 08:37 (UTC)回复[回复]
更准确来说,是新加坡DC的地址段都block(因为连test这个近乎不公开的入口也在骨干没了)。——路过围观的Sakamotosan | 避免做作,免敬 2020年5月23日 (六) 14:01 (UTC)回复[回复]
然后在电信广州节点上跑了一下tcp的traceroute,结果发现:只需要5跳就到了,而且延迟和过了海几乎一样………………如果对中国互联网架构理解的话,请想一下5跳应该去到哪里。——路过围观的Sakamotosan | 避免做作,免敬 2020年5月23日 (六) 14:11 (UTC)回复[回复]
初步探测:3个443入口5跳接通,然后同网段其他地址理论上ping的通,有开端口的也syn的通,而且跳数基本正常。——路过围观的Sakamotosan | 避免做作,免敬 2020年5月23日 (六) 14:19 (UTC)回复[回复]
@Cwek:可为什么tcping新加坡IP却能通呢?Probing 103.102.166.224:80/tcp - Port is open - time=202.008ms --Liuxinyu970226留言) 2020年5月30日 (六) 00:45 (UTC)回复[回复]
用tcp的traceroute检查下跳数,低于一定跳数你想下这会多可怕。port open只代表tcp三次握手成功,但是如果数据传输行为不正常那就是另一回事。希望这只是短暂现象。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年5月30日 (六) 00:48 (UTC)回复[回复]
今天偶然试着用站长之家ping了新加坡节点,发现已经可以ping通。因为好一段时间没去测所以不知道什么时候恢复的,从Help:如何访问维基百科的编辑历史来看可能是5月30日或之前。--🔨留言) 2020年6月5日 (五) 13:32 (UTC)回复[回复]
嗯,我也试了一下新加坡节点又能用了,所以能不能求情把ulsfo的IPv4也给解封?哪怕这会导致所有zh.wiki啥的.org全被SNI墙我也忍了,毕竟访问C区的话新加坡节点速度甚至不如荷兰的那个--Liuxinyu970226留言) 2020年6月6日 (六) 01:11 (UTC)回复[回复]
唉,又不能用了,而且eqiad是不是也挂了?所以现在墙究竟在搞啥啊?故意让我各种ping通又封我hosts?--Liuxinyu970226留言) 2020年6月6日 (六) 03:12 (UTC)回复[回复]
……不想和半吊子讨论这些问题了。简单就是,测一下tcp的traceroute。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月6日 (六) 03:26 (UTC)回复[回复]
@Cwek:你叫我怎么测出“5跳就通”,我这边除了某些超时结果,前12跳全是10.几的内网IP地址。--Liuxinyu970226留言) 2020年6月6日 (六) 04:49 (UTC)回复[回复]
好吧,我测试的环境1跳就能入接入网了,平均在2~4跳进入骨干网。或者应该说“从进入接入网后,2~4跳,也就是5跳开始”,如果很快就遇到目标地址,肯定有问题。到国外地址,从接入网开始,平均在9~10跳及以上。PS.为啥你的测试环境这么多跳内网地址。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月6日 (六) 05:33 (UTC)回复[回复]
回正题,感觉是路由黑洞的延伸。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月6日 (六) 05:41 (UTC)回复[回复]
@Liuxinyu970226 恕我孤陋寡闻,但是好像所有zh.wiki啥的.org已经全被SNI墙了。162.211.224.40留言) 2020年6月9日 (二) 13:59 (UTC)回复[回复]
@162.211.224.40:不不不,只有维基百科和中文维基语录被照顾而已,其他的都是ulsfo的锅。--Liuxinyu970226留言) 2020年6月11日 (四) 01:16 (UTC)回复[回复]
哦,明白了。其它的维基媒体项目只是被DNS污染,并没有被SNI照顾。你所说的“ulsfo的锅”指的是什么?162.211.224.40留言) 2020年6月11日 (四) 12:02 (UTC)回复[回复]
指的是ulsfo的节点(198.35.26.96)被封锁的事情。--🔨留言) 2020年6月12日 (五) 06:23 (UTC)回复[回复]
哦,明白了。多谢说明。162.211.224.40留言) 2020年6月12日 (五) 21:04 (UTC)回复[回复]
最近初测来看,eqiad和eqsin的icmp包路由行为正常(跳数符合预期,包括ping和traceroute),但tcp包的路由行为异常(跳数不符合预期,三次握手看上去没问题,但是发送数据后不会有响应)。如果非要求个心理安慰的话,根据DC命名规则,这两个DC是租赁Equinix的DC的。 囧rz...——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月12日 (五) 07:37 (UTC)回复[回复]
也就是说美国阿什本和新加坡这两个数据中心都是租赁Equinix公司的数据中心,而Equinix公司的数据中心的服务器现在正在被墙TCP重点关照,所以维基媒体设在Equinix公司的数据中心也就被TCP躺枪了?162.211.224.40留言) 2020年6月12日 (五) 21:04 (UTC)回复[回复]
如果出于心理安慰的话,可以这么想。虽然好像记得最开始测定时没发现eqiad有这个问题,而且服务器是租赁的,但是对应的地址段都是基金会自有的(也就是在DC的接入线路上宣告路由),并在同一个AS里面,实际上如果对同一个AS做同样的事,一个都逃不掉。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年6月13日 (六) 02:37 (UTC)回复[回复]
都封到这个份上了,还是不上IP地址封杀。而且维基媒体所有的项目的IP地址就那么几个。墙果然不是逻辑可以理喻的。162.211.224.40留言) 2020年6月13日 (六) 13:02 (UTC)回复[回复]
ESNI一来,保准全部IP都会封掉,当然,也不排除ESNI来之前IP就已全被封的可能性。--🔨留言) 2020年6月13日 (六) 13:15 (UTC)回复[回复]
严重同意!!!!!!!!!!!!!! 66.241.128.130留言) 2020年6月13日 (六) 14:42 (UTC)回复[回复]
@Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 “AS”在这儿指的是Autonomous System自治系统吗?162.211.224.40留言) 2020年6月14日 (日) 13:06 (UTC)回复[回复]
我认为不是被墙了,而是新加坡节点其自身的网络出了问题,因为我手里的香港服务器也会出现连接超时的情况。如讨论中所说,阿里云和其他服务商的不同服务器都出现了连接维基新加坡服务器[2001:df2:e500:ed1a::1]及103.102.166.224超时的情况。这显然是上游的问题。 --安忆Talk 2020年6月26日 (五) 00:25 (UTC)回复[回复]
(~)補充:是直接访问网页的HTTP 504超时(即TCP),不是Ping IP。 --安忆Talk 2020年6月26日 (五) 00:29 (UTC)回复[回复]
我看不懂你在说什么。能收到 HTTP 504自然是TCP没有问题。我刚测试的结果,ICMP 和 TCP 80 都没有问题,TCP 443 握手成功,但当客户端发出Client Hello开始TLS握手的时候开始丢包。另外mtr -T -P 443 103.102.166.224显示,数据包在进入联通骨干网之前就被回复了(没出省级网络)。看上去跟上次GitHub等被中间人的时候挺类似,只是没能等到伪造的回复。194.50.170.206留言) 2020年6月26日 (五) 05:21 (UTC)回复[回复]
我也看不懂你在说什么。你是怎么得出能收到HTTP 504就是TCP没有问题的结论的?你是“用户-维基新加坡节点”直接连接,而我是使用每时每刻都在与维基新加坡节点进行通信的、香港PCCW网络的香港服务器反代维基新加坡节点,连接全程是“用户-香港服务器-维基新加坡节点”,香港难不成也有墙?用户看到的504 Gateway Timeout是由我的服务器发出的,表示的是“香港服务器-维基新加坡节点”这段超时。服务器的错误日志为[error] upstream timed out (110: Connection timed out) while SSL handshaking to upstream, upstream: "https://103.102.166.224:443"。这按照你的逻辑当然是TCP没有问题,毕竟又不是不能用。提醒你一下,“能用”和“用起来稳定”是两个概念。我上一条回复的意思概括起来是“我认为新加坡节点这段时间自身网络有问题,因为在非中国大陆的网络下连接它也会出现连接超时的情况,故无法断言是被墙了。” --安忆Talk 2020年6月26日 (五) 09:15 (UTC)回复[回复]
哦,原来你看到的504 Gateway Timeout不是维基媒体服务器发出的啊……那你说它干嘛呢。你这也是TLS握手出问题啊,跟我观察到的一样。mtr跟一下呗。我连省网都出不去,所以显然我这里在省级就被墙了(或者省级网络故障)。194.50.170.206留言) 2020年6月26日 (五) 11:23 (UTC)回复[回复]
因为我和上游服务器出现了连接超时的情况才会向前端发504啊,又因为用的不是大陆网络,所以我才会说“可能不是被墙了,而是新加坡节点其自身的网络出了问题”,你捋一捋思路……刚刚mtr了一下,数据包从he.net的BGP路由出来后(我有直接的he.net)就到了14907.sgw.equinix.com转而到了text-lb.eqsin.wikimedia.org,我这里的连接不经过国内运营商的骨干网,但还是时不时地请求超时,所以我猜测可能是eqsin自己的问题。不过这也没法解释你在国内也出现了类似省级网络故障的情况…… --安忆Talk 2020年6月26日 (五) 12:33 (UTC)回复[回复]

本地反向代理没有自行签发、导入证书的必要

Help:如何访问维基百科#本地反向代理一节所描述的方法似乎过于繁琐。如果仅仅是想访问本站,普通的反向代理就够了。以httpd为例,如果你想从浏览器透过sslproxy.example.com:8088这个虚假的网址访问中文维基的话,只需将"127.0.0.1 sslproxy.example.com"本身加入hosts文件,然后在httpd的配置文件里添加以下内容:

<VirtualHost *:8088>
    DocumentRoot "${SRVROOT}/htdocs"
    ServerAlias sslproxy.example.com
    RequestHeader set Host zh.wikipedia.org
    SSLProxyCheckPeerName off
    ProxyPreserveHost On
    ProxyPass / h2://test2.wikipedia.org/
    ProxyPassReverse / https://zh.wikipedia.org/
</VirtualHost>

就可以了。test2.wikipedia.org可以替换成任何一个未受SNI阻断影响的姊妹计划的网址。如果你还想编辑的话,再给cookies做点手脚:

<VirtualHost *:8088>
    DocumentRoot "${SRVROOT}/htdocs"
    ServerAlias sslproxy.example.com
    RequestHeader set Host zh.wikipedia.org
    Header edit* Set-Cookie ".wikipedia.org" "sslproxy.example.com"
    Header edit* Set-Cookie "[Ss]ecure" ""
    SSLProxyCheckPeerName off
    ProxyPreserveHost On
    ProxyPass / h2://test2.wikipedia.org/
    ProxyPassReverse / https://zh.wikipedia.org/
</VirtualHost>

之后就可以正常登录、编辑了。--Antigng留言) 2020年7月17日 (五) 20:42 (UTC)回复[回复]

  • 那一节里的方法,主要是为了访问Pixiv而设计的,而Pixiv大部分资源都有来源验证。不过反代Wikipedia的话,自行签发、导入证书也有必要的(当然如果只的单纯地看看的话确实没什么必要),因为域名不对有些功能也是用不了的(如“短链接”等API就有跨域白名单)。这就导致访问服务器的域名需要是正确的,HTTPS也最好支持(HTTP反代HTTPS可能会出现其他问题)。 --安忆Talk 2020年7月18日 (六) 00:07 (UTC)回复[回复]
不过要说需要完善的点也是有的,一是白猫的HOSTS还不是很全,基金会用了许多明面上看不到的子域名;二是配置文件还有改善的空间,现在的也仅是“能看”而已,很多地方处理得都不是很好。 --安忆Talk 2020年7月18日 (六) 00:07 (UTC)回复[回复]
务必提醒一下:Firefox会拒绝自签名证书,在有HSTS的情况下导入了也没用。而Pixiv-Nginx用的证书不是自签名证书。--GZWDer留言) 2020年7月19日 (日) 13:33 (UTC)回复[回复]
Pixiv-Nginx用的不是自签证书吗?是吧,它需要先安装根证书(CA),然后Nginx用的就是这个CA签发的域名证书。因为这个CA在系统里是可信的,所以这时自签的域名证书也是可信的。Firefox只是用了它自己内置的根证书列表而已,也是可以导入其他证书的。至于您说的HSTS,它只验证证书的信任链是否完整,而不是区分是不是自签的,所以只要系统或浏览器里有可信CA就可以了。 --安忆Talk 2020年7月19日 (日) 13:48 (UTC)回复[回复]
但是曾经试验过#使用Nginx本地反代无需代理服务器直连维基百科所述方法生成的证书Firefox不接受。--GZWDer留言) 2020年7月19日 (日) 16:52 (UTC)回复[回复]
因为他只写了自签域名证书,我估计您也只弄了那个。您读读我上面对您回复的,就很容易知道,要想保证信任链的完整可信,就还需要自签CA,然后用自己的CA去签名其他域名证书。 --安忆Talk 2020年7月19日 (日) 23:12 (UTC)回复[回复]

路由信息更新

新加坡节点和阿什本节点text接入点的tcp诡异路由现象消失。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年8月12日 (三) 01:30 (UTC)回复[回复]

刚测了下,的确正常了。--🔨留言) 2020年8月12日 (三) 07:42 (UTC)回复[回复]

火狐浏览器域前置修改更新

各位维基人大家好:

最近有幸能够在Ubuntu 19.10上修改【最新】的火狐浏览器代码。所以更新一下2019年5月我发过的Help_talk:如何访问维基百科#修改火狐浏览器关于SNI的部分。(在Ubuntu 19.10上build火狐浏览器的具体步骤请参考[5]

修改地方一共有两处。第一处就是2019年5月我修改的SNI代码,但是最新的火狐浏览器代码里负责生成ClientHello的源代码文件名换了(或者说是细化了),新的源代码文件名是mozilla-unified/security/nss/lib/ssl/ssl3exthandle.c。具体负责生成ClientHello的函数也换了(或者说是细化了),新函数源代码如下:

/* Format an SNI extension, using the name from the socket's URL,
 * unless that name is a dotted decimal string.
 * Used by client and server.
 */
SECStatus
ssl3_ClientFormatServerNameXtn(const sslSocket *ss, const char *url,
                               TLSExtensionData *xtnData,
                               sslBuffer *buf)
{
    unsigned int len;
    SECStatus rv;

    len = PORT_Strlen(url);
    /* length of server_name_list */
    rv = sslBuffer_AppendNumber(buf, len + 3, 2);
    if (rv != SECSuccess) {
        return SECFailure;
    }
    /* Name Type (sni_host_name) */
    rv = sslBuffer_AppendNumber(buf, 0, 1);
    if (rv != SECSuccess) {
        return SECFailure;
    }
    /* HostName (length and value) */
    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)url, len, 2);
    if (rv != SECSuccess) {
        return SECFailure;
    }

    return SECSuccess;
}

具体修改和2019年5月我公布的修改一样,修改如下两处地方:

    len = PORT_Strlen(url);

修改成

    len = PORT_Strlen("upload.wikimedia.org\0");
    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)url, len, 2);

修改成

    rv = sslBuffer_AppendVariable(buf, (const PRUint8 *)"upload.wikimedia.org\0", len, 2);

注意,如果upload.wikimedia.org被SNI封杀的话,那就要更换成另外一个尚未被SNI封杀的维基基金会的SNI域名。

这一次的修改比起2019年5月的修改,多了一个要修改的源代码文件。我想既然是域前置,那就干脆做全套的域前置,包括DNS部分。所以我顺藤摸瓜的摸到了火狐负责完成DNS查询的源代码。源代码的文件名是mozilla-unified/netwerk/dns/nsHostResolver.cpp。具体负责DNS查询的函数名叫nsHostResolver::ResolveHost,细节如下:

nsresult nsHostResolver::ResolveHost(const nsACString& aHost,
                                     const nsACString& aTrrServer,
                                     uint16_t type,
                                     const OriginAttributes& aOriginAttributes,
                                     uint16_t flags, uint16_t af,
                                     nsResolveHostCallback* aCallback) {
  nsAutoCString host(aHost);
  NS_ENSURE_TRUE(!host.IsEmpty(), NS_ERROR_UNEXPECTED);

  nsAutoCString originSuffix;
  aOriginAttributes.CreateSuffix(originSuffix);
  LOG(("Resolving host [%s]<%s>%s%s type %d. [this=%p]\n", host.get(),
       originSuffix.get(), flags & RES_BYPASS_CACHE ? " - bypassing cache" : "",
       flags & RES_REFRESH_CACHE ? " - refresh cache" : "", type, this));

  // ensure that we are working with a valid hostname before proceeding.  see
  // bug 304904 for details.
  if (!net_IsValidHostName(host)) {
    return NS_ERROR_UNKNOWN_HOST;
  }

  // By-Type requests use only TRR. If TRR is disabled we can return
  // immediately.
  if (IS_OTHER_TYPE(type) && Mode() == MODE_TRROFF) {

...

整个函数的篇幅巨长,所以我就不全部列出了。需要修改的是第一行:

  nsAutoCString host(aHost);

修改成

  nsAutoCString host("upload.wikimedia.org\0");

注意,如果upload.wikimedia.org被DNS污染的话,那就要更换成另外一个尚未被DNS污染的维基基金会的DNS域名。

祝墙内的各位维基人在魔改火狐浏览器以后,免翻墙域前置浏览维基百科快乐!

--不爱思考得猪留言) 2020年9月8日 (二) 02:31 (UTC)回复[回复]

www.jinzhao.wiki疑似被屏蔽

近期"www.jinzhao.wiki"在中国大陆无法正常访问,疑似遭到TCP重置攻击(浏览器提示连接重置) Asanatsa留言) 2020年10月20日 (二) 13:53 (UTC)回复[回复]

我这里可以访问。移动端访问chi.jinzhao.wiki会错误地重定向至zh.m.wikipedia.org(正确的是chi-m.jinzhao.wiki),可能是您觉得无法访问的原因。 --安忆Talk 2020年10月20日 (二) 14:34 (UTC)回复[回复]
镜像站的问题,别再这里问。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年12月8日 (二) 05:47 (UTC)回复[回复]

关于2020年12月IP封锁的新一轮问题分析

  • 首先,5个地址的tcptrace都是没问题的。(没错包括旧金山)
  • SNI阻断似乎可以针对特定地址的,因为根据SNI的原理,突发奇想,在Google随便找了一个https的网站,解析域名对应的服务器IP(whois过,IP也是国外的),然后替换掉测试IP。起初假设会在客户端握手就断掉,但是却收到服务器的响应(只是域名不匹配报错),然后也用upload5个IP测试,除了阿什本,都是能收到服务器响应(tls层连接匹配,但http层对不上)。

结论:猜不透。(笑 ——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年12月8日 (二) 06:05 (UTC)回复[回复]

其实我觉得可以将页面3.2章节去掉…因为现在的情况下,受限于SNI识别(范围应该会逐渐扩大并成为主流),即使IP正常也没什么作用。以下是离题内容:
我认为本地伪造SNI或者不发送SNI也不是什么太好的办法,毕竟要取决于服务端的处理方式,说不定WMF哪天就会将默认证书换成其他的或者干脆拒绝不提供正确信息的连接了。目前看来,最好的办法就是尽量有VPN就用VPN,其次是如果技术够或者爱折腾的话就用本地反代之类的东西(直连IP体验不怎么好,间歇性抽风或者巨慢),再次就是各种MITM式的第三方反代(会有安全和隐私问题),最后就是只读离线数据库。--安忆Talk 2020年12月8日 (二) 06:42 (UTC)回复[回复]
这问题11月就有了,记得那个时候@Liuxinyu970226就在这笔编辑里进行了反馈。--🔨留言) 2020年12月8日 (二) 11:41 (UTC)回复[回复]

2021年1月报告

  • 地点:大陆南方电信
  • DNS投毒:存在(因为有“大神”提到投毒消失,所以加测一下。——怎么可能不投毒呢?
  • 地址情况:
只针对text组
地区 tcptrace-ack tcptrace-syn 带sni握手(species.wikimedia.org) 带sni握手(www.wikipedia.org)
旧金山 TLS握手超时 TLS握手超时
卡罗尔顿 TLS握手RST
阿什本 TLS握手超时 TLS握手超时
阿姆斯特丹 TLS握手RST
新加坡 TLS握手超时 TLS握手超时
结论:没意义。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2021年1月19日 (二) 01:47 (UTC)回复[回复]
@Cwek:然而几分钟前,走天津联通线的我却测出
只针对text组
地区 tcptrace-ack tcptrace-syn 带sni握手(www.wikidata.org) 带sni握手(www.wikipedia.org)
旧金山 TLS_CONNECTION_RESET TLS_CONNECTION_RESET
卡罗尔顿 TLS_CONNECTION_RESET TLS_CONNECTION_RESET
阿什本 TLS_CONNECTION_RESET TLS_CONNECTION_RESET
阿姆斯特丹 TLS_CONNECTION_RESET TLS_CONNECTION_RESET
新加坡 TLS_CONNECTION_RESET TLS_CONNECTION_RESET

中间间断的有几分钟,连百度微博啥的、更甚至有几秒钟 https://localhost/ 都CONNECTION_RESET了(天哪墙娘终于开始试验封硬件了么)。经过我不懈努力不断F5刷新,坚持35分钟后,结果跟dalao一样。--Liuxinyu970226留言) 2021年1月19日 (二) 09:38 (UTC)回复[回复]

最后只想说一句:封我SYN者,虽远必诛!--Liuxinyu970226留言) 2021年1月19日 (二) 09:41 (UTC)回复[回复]
SYN有屁用,一个RST就好了。正常情况没有什么TCP连接是一发RST不能解决的,如果有,那就三发;再不行,黑洞模式on。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2021年1月19日 (二) 09:57 (UTC)回复[回复]
localhost是要怎麼被GFW reset(-- Sunny00217  2021年5月28日 (五) 05:20 (UTC)回复[回复]

互联网信息服务管理办法(修订草案征求意见稿)

前日,国家网信办发布《互联网信息服务管理办法(修订草案征求意见稿)》,向社会公开征求意见,其中提到:

第二十七条 ……国家有关机构依法采取技术措施和其他必要措施,阻断来自于中华人民共和国境外的法律、行政法规禁止发布或者传输的信息。

任何组织和个人不得违反国家规定,为他人获取、传播前款被依法阻断的信息而提供技术支持或者其他帮助。

第四十一条 违反本办法第十五条、第二十七条第四款规定尚不构成犯罪的,由公安机关没收违法所得,处5日以下拘留,可以并处5万元以上50万元以下罚款;情节较重的,处5日以上15日以下拘留,可以并处10万元以上100万元以下罚款。

望各位周知。--曾晋哲反对五个一留言·Q) 2021年1月10日 (日) 19:21 (UTC)回复[回复]

赋予IPBE取权限不知道算不算“提供技术支持或者其他帮助”?--百無一用是書生 () 2021年1月11日 (一) 01:32 (UTC)回复[回复]
征求意见稿不一定过;授予IPBE权限应该不算“提供技术支持或者其他帮助”,毕竟对方连不到站点的话给账号以权限也没有用。--安忆Talk 2021年1月11日 (一) 02:21 (UTC)回复[回复]
我认为在如今的大环境下通过的可能性很高。再说这玩意出来之前,已经出了不少因为“提供技术支持”而被处罚的案例了。--🔨留言) 2021年1月11日 (一) 03:18 (UTC)回复[回复]
我认为类似镜像站之类的东西根据草案存在极高的法律风险。--痛心疾首 2021年1月11日 (一) 09:59 (UTC)回复[回复]
有可能,但我不是法律专家,给不出专业解释。我觉得万维百科之类的镜像的风险低一些。——SolidBlock留言 2021年1月15日 (五) 07:58 (UTC)回复[回复]

我觉得中国大陆维基人应该去表达一下意见,这个规定通过后对需要翻墙的大陆维基人显然没有好处。——BlackShadowG留言维基百科20岁生日快乐! 2021年1月16日 (六) 13:20 (UTC)回复[回复]

可以考虑,前提是事后不会被找上麻烦……--🔨留言) 2021年1月17日 (日) 00:51 (UTC)回复[回复]
问题是,相关内容在中华人民共和国司法领域内法理上是站得住脚的,表达类似意见应该没有风险,但完全无益。--北美奴隶主种族灭绝反人类匪帮,必须被毁灭! 2021年1月18日 (一) 01:19 (UTC)回复[回复]

本地反代属于域前置

我已经在 meta 的相关页面修改。 妖怪兽留言) 2021年4月14日 (三) 03:03 (UTC)回复[回复]

第一个镜像站wikimirror这个站似乎不能用了?

这个网站打开是一个告别信一样的页面,落款时间是2020 年 2 月 28 日,应该算不能用了?--U:FakeGreenHand讨论 2021年6月17日 (四) 05:49 (UTC)回复[回复]

能的。--安忆Talk 2021年6月17日 (四) 08:35 (UTC)回复[回复]
哦,找到进入的方法了。“主站点”是个迷惑性的页面...--U:FakeGreenHand讨论 2021年6月19日 (六) 08:10 (UTC)回复[回复]

邮件列表被墙了?

自打昨天下午邮件列表打不开,然后

C:\Users\Administrator>curl -H "Host:lists.wikimedia.org" --resolve lists.wikimedia.org:443:208.80.154.21 https://lists.wikimedia.org
curl: (7) Failed to connect to lists.wikimedia.org port 443: Timed out

--Liuxinyu970226留言) 2021年7月2日 (五) 10:48 (UTC)回复[回复]

root@ubuntu:~# curl -v --connect-to ::208.80.154.21 --tls-max 1.2 --max-time 10 https://lists.wikimedia.org
* Connecting to hostname: 208.80.154.21
*   Trying 208.80.154.21:443...
* TCP_NODELAY set
* Connected to 208.80.154.21 (208.80.154.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=lists.wikimedia.org
*  start date: May 31 09:00:13 2021 GMT
*  expire date: Aug 29 09:00:13 2021 GMT
*  subjectAltName: host "lists.wikimedia.org" matched cert's "lists.wikimedia.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: lists.wikimedia.org
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
没发现异常。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月5日 (一) 11:03 (UTC)回复[回复]
GreatFire大火网站的Blocky测试,显示一切均正常。174.138.217.112留言) 2021年7月16日 (五) 14:34 (UTC)回复[回复]

近期修改hosts文件后无法稳定的访问维基百科


我于5月初通过h:hosts的帮助修改hosts文件来访问维基百科。我在我自己的js页按照上面的向导加了文字。前两周都能正常稳定的访问维基百科,但是5月末的时候访问只能连接几分钟,然后就断开,重新来一遍才能访问。想知道如何继续通过修改hosts文件来稳定的访问维基百科。 -- 2021年6月4日 (五) 12:40 (UTC)回复[回复]

不稳定是正常的,稳定是不正常的。随着SNI阻断的成熟,本地改个解析(也就是Hosts)就能上的情形必定成为过去式。建议使用VPN或酌情使用WP:MF。--安忆Talk 2021年6月4日 (五) 13:28 (UTC)回复[回复]
好吧。顺便问一下按照教程添加的js是什么意思,有什么作用,我不懂。-- 2021年6月5日 (六) 01:13 (UTC)回复[回复]
试图维持一个可用会话。--安忆Talk 2021年6月5日 (六) 01:24 (UTC)回复[回复]
是不是通过隔一段时间刷新一些网址的缓存来维持会话?里面的数字30000是不是刷新缓存间隔的时间,30秒一次?-- 2021年6月5日 (六) 23:02 (UTC)回复[回复]
1000 + Math.random() * 500毫秒一次,没有固定值,随机的。--安忆Talk 2021年6月6日 (日) 02:49 (UTC)回复[回复]
是不是值越小访问越稳定?-- 2021年6月19日 (六) 02:56 (UTC)回复[回复]
不一定,无数据表明或支持此设想。--安忆Talk 2021年6月22日 (二) 02:30 (UTC)回复[回复]
本地SNIProxy加一条绳子是最好的方案。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年6月5日 (六) 01:53 (UTC)回复[回复]
tcpioneer了解下。--Txkk留言) 2021年6月9日 (三) 11:15 (UTC)回复[回复]
这是来自阿里云北京的编辑。--39.105.213.4留言) 2021年6月17日 (四) 11:53 (UTC)回复[回复]
可以尝试使用本地隐藏SNI域前置防屏蔽工具,这样不需要代理,也可以稳定地上维基,比如https://github.com/URenko/Accesser。不过如果网站被封ip的话就没用了,但至少维基可以用。 Haohaoh4留言) 2021年7月1日 (四) 13:41 (UTC)回复[回复]
但是我尝试使用accesser访问维基百科的时候会显示隐私错误并拒绝访问,但是访问其他维基媒体项目(例如元维基)时却不会有这种错误,如何解决。-- 2021年7月9日 (五) 07:29 (UTC)回复[回复]

Toolforge已经不能在墙内访问

已经使用blocky测试工具测试过了。原网址和redirect以后的目标网址均已被DNS污染。特此汇报。希望对“后台支持性服务”列表做出相应的更新。

--不爱思考得猪留言) 2021年10月18日 (一) 02:39 (UTC)回复[回复]

在广东电信线路测试过(使用: whois-dev.toolforge.org ),没发现问题。可能是地区性问题?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月20日 (三) 05:40 (UTC)回复[回复]
@Cwek:非常感谢这个非常重要的情报。我现在就去Help:如何访问维基百科去改一下Toolforge链接所连接到的目标URL。--不爱思考得猪留言) 2021年10月20日 (三) 12:47 (UTC)回复[回复]
@Cwek:经过测试,你给的网址blocky显示的确运作正常,未被墙。--不爱思考得猪留言) 2021年10月20日 (三) 12:50 (UTC)回复[回复]
我知道为什么了,tools.wmflabs.org被重定向到wikitech.wikimedia.org/wiki/Portal:Toolforge,而wikitech.wikimedia.org已经改用统一CNAME:dyna.wikimedia.org了,这个网址的IP就是对应相应5个接入点地址,其中旧金山那个嘛……都知道什么回事了。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月21日 (四) 00:41 (UTC)回复[回复]
@Cwek:非常感谢坂本兄的详细考证。--不爱思考得猪留言) 2021年10月21日 (四) 01:57 (UTC)回复[回复]
@Cwek:请问wmflabs.org这个域名被整体(包括所有子域名比如tools.wmflabs.org)重定向到了其它域名(wikimedia.org以及toolforge.org)了吗?我似乎找不到任何还继续保留wmflabs.org这个域名的网页。--不爱思考得猪留言) 2021年10月21日 (四) 11:16 (UTC)回复[回复]
自己试呀。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月21日 (四) 11:59 (UTC)回复[回复]
@Cwek:我自己的确试了很多网址,都被重定向了。但是我不确定是否wmflabs.org以及其所有的子域上面的所有网页都是如此,所以问一下你。因为你似乎对于维基媒体的网站结构了解很深。网站么,你也了解,不像自己电脑C盘上的目录结构,可以看到每一个文件。--不爱思考得猪留言) 2021年10月21日 (四) 16:36 (UTC)回复[回复]
不确定,对于wmflabs.org,我试了:xtoolstoollabs:xtools)是配置到自己的工具列表,commonshelpertoollabs:commonshelper)是域名没配置好报错,whoistoollabs:whois)就成了占位页了。感觉wmflabs.org和toolforge.org的子域名内容是维护者自行配置的(可以分开配置),会有差别。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月22日 (五) 01:27 (UTC)回复[回复]
@Cwek:太棒了!果然每次问一下坂本兄就能问出点干货来!我要找的就是commonshelper这样的不自动跳转到其它域名的wmflabs.org子域名(尽管原因是由于域名没配置好报错,但是报错页是由commonshelper.wmflabs.org的apache服务器生成的,所以可以算作是一个commonshelper.wmflabs.org上面的正常的网页)。我已经马上用blocky测试了一下,结果证明commonshelper.wmflabs.org尚未被墙,与我预想的一样。--不爱思考得猪留言) 2021年10月22日 (五) 02:03 (UTC)回复[回复]
@Cwek:另外请教一下坂本兄:黑×和红×有什么区别?谢谢🙇‍🙇‍🙇‍。--不爱思考得猪留言) 2021年10月21日 (四) 19:34 (UTC)回复[回复]
你为什么不问问神奇海螺呢?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月22日 (五) 01:14 (UTC)回复[回复]
@Cwek:哈哈哈,就是因为没有读懂“修正地址后也不可访问(TCP中断类)”这句话的意思,所以专门向兄请教的。--不爱思考得猪留言) 2021年10月22日 (五) 01:58 (UTC)回复[回复]
防火长城三板斧(DNS投毒、TCP RST、路由黑洞)的原理理解透了,就知道对应会发生什么情况了。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月22日 (五) 02:06 (UTC)回复[回复]
@Cwek:三板斧我懂。我不懂的是“修正地址”具体☞指的是什么,是简单的HOST修正还是HOST修正➕SNI修正/域前置?另外TCP中断重置以前是指明文连接里被检测出有敏感字词,现在据我所知SNI封杀用的也是TCP中断重置,那么“TCP中断类”我认为放在当代(2021年)指☞的应该是后者:由于SNI检测出违禁域名而引起的TCP中断重置,不知兄是什么看法?--不爱思考得猪留言) 2021年10月22日 (五) 03:00 (UTC)回复[回复]
对于wikipedia等主要项目有五个接入点,然后基金会DNS按照IP来源地区来分配接入点,现在不同接入点的表现是有差异的,所以才有区分意义。不过toolserver好像只有一个接入点,只有后两个被针对就真没戏了。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年10月22日 (五) 03:50 (UTC)回复[回复]
明白了明白了。--不爱思考得猪留言) 2021年10月22日 (五) 16:55 (UTC)回复[回复]

如何访问维基百科这一页面是否需要更新

通过测试,除中国移动外,中国电信与中国联通这两家运营商并没有对除维基百科外的任何维基媒体项目做屏蔽,且都可以快速直连,在学校校园网络进行测试也是如此,故大陆并不是什么也无法访问,应该对页面进行修改与调整--The world's stars shine✨ 2021年11月11日 (四) 09:48 (UTC)回复[回复]

网络数据安全管理条例(征求意见稿)

已解決
剩下讨论(如技术交流等)已经脱题,就此结束,其他问题另处接续——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年11月24日 (三) 01:04 (UTC)回复[回复]
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

今天网信办发布《网络数据安全管理条例的征求意见稿》,以下是涉及到网络审查的部分(第七十三条是关于整个条例当中出现的专业用语,这里也只收录与审查相关的部分):

第四十一条 国家建立数据跨境安全网关,对来源于中华人民共和国境外、法律和行政法规禁止发布或者传输的信息予以阻断传播。

任何个人和组织不得提供用于穿透、绕过数据跨境安全网关的程序、工具、线路等,不得为穿透、绕过数据跨境安全网关提供互联网接入、服务器托管、技术支持、传播推广、支付结算、应用下载等服务。

境内用户访问境内网络的,其流量不得被路由至境外。

第六十六条 个人和组织违反第四十一条的规定,由有关主管部门责令改正,给予警告、没收违法所得;拒不改正的,处违法所得一倍以上十倍以下的罚款,没有违法所得的,对直接负责的主管人员和其他直接负责人员,处五万元以上五十万元以下罚款;情节严重的,由有关主管部门依照相关法律、行政法规的规定,责令其暂停相关业务、停业整顿、吊销相关业务许可证或者吊销营业执照;构成犯罪的,依照相关法律、行政法规的规定处罚。

第七十三条 本条例下列用语的含义:

(十一)数据跨境安全网关是指阻断访问境外反动网站和有害信息、防止来自境外的网络攻击、管控跨境网络数据传输、防范侦查打击跨境网络犯罪的重要安全基础设施。

今年一月网信办发了个存在类似条款的《互联网信息服务管理办法》的征求意见稿,然而过了这么多个月,《互联网信息服务管理办法》的修订似乎没看到任何下文了,不知道是怎么回事(反正我没看到任何后续的消息的……)。不过一切都很难说……--🔨留言) 2021年11月14日 (日) 10:14 (UTC)回复[回复]

意思是明确规定“翻越数据跨境安全网关”访问或编辑维基百科是所谓非法行为?如果确实立法了,大概中文维基应对中国大陆用户做一个法律风险提示和免责声明了。桐生君[讨论] 2021年11月14日 (日) 17:30 (UTC)回复[回复]

似乎主要是针对机场,而不是个人?注意关键词“提供”。在这种情况下,个人有技术能力搭建VPN自用且不分享似乎不受限制?--菲菇维基食用菌协会 2021年11月14日 (日) 17:54 (UTC)回复[回复]
现在的“机场主”,基本上都是肉身在墙外了,早几年前的时候肉身墙内的“机场主”就已经有不少被抓去蹲大牢了,充分说明网信办就算不立这个新规,官老爷照样要以铁拳伺候为他人翻墙提供方便的人士。立与不立的差别可能就只在于力度了吧……毕竟有了明文规定就可以更好地放开手脚了。不过这一次立新规我们欣喜地看到了“防火长城”终于有了一个官方命名:“数据跨境安全网关”。另外,这次的数据安全条例的网络审查部分与今年一月的《互联网信息服务管理办法》意见稿相比,细节更多,界定范围更广,处罚力度也更大了,相信《互联网信息服务管理办法》要么就真的放置不管直到下一次修订征求意见,要么当中的网络审查部分也向这一次制定的《网络数据安全管理条例》看齐。GitHub贵为为翻墙提供方便的一大宝地,今年开始遭遇间歇性访问干扰,网信办这番动作,加之GFW话题甚为活跃的V2EX今年4月已被彻底封锁,墙要彻底干GitHub只是时间问题。总之,各维基百科镜像站拥有者们,多留一点心眼吧,搞不好这次网信办是要来真的……--🔨留言) 2021年11月15日 (一) 01:52 (UTC)回复[回复]
注意:此前并不是没有明文,相关行为一般可以适用“非法经营罪”或者“(提供)侵入、非法控制计算机信息系统(程序、工具罪)”。--伞木 留言 2021年11月15日 (一) 02:18 (UTC)回复[回复]
你上面提到的那两条罪行,顶多也只算是间接说明帮助他人绕过审查是非法的。这次是直接明确表明为绕过网络审查提供方便就要受到制裁。直接和间接也会有差别,间接的话对于法律条文的解释必然会出现不同意见(记得以前见过有人在微信公众平台写文章分析就在说非法侵入计算机系统罪用在“机场主”案不适合),直接的话就没有这个问题。--🔨留言) 2021年11月15日 (一) 02:34 (UTC)回复[回复]
您想多了,这个条款其实就是用来弥补法律漏洞(空白罪状的法源问题,即上述罪名中“违反国家规定”表述)而已。另外,行政处罚前置,某种程度上也可以减轻被刑事定罪的风险。见此。--伞木 留言 2021年11月15日 (一) 04:17 (UTC)回复[回复]
那像墙内那些超大型YouTuber比如李子柒和办公室小野怎么办?都被抓起来请喝茶吗?--不爱思考得猪留言) 2021年11月16日 (二) 15:39 (UTC)回复[回复]
@AlexLeeCN:哦,原来如此。现在我注意到现在很多机场也都提供IPLC线路和阿里云。那么使用这些机场服务的用户就不能算是在“翻墙”了,也就符合《网络数据安全管理条例的征求意见稿》了。--不爱思考得猪留言) 2021年11月16日 (二) 22:18 (UTC)回复[回复]
@不爱思考得猪:机场转售的做法并不是合规的,专线只能企业内部自用,见此协议4.4.和附件1第三条。--伞木 留言 2021年11月17日 (三) 04:53 (UTC)回复[回复]
@AlexLeeCN:你这样一说我就糊涂了。那李子柒和办公室小野也是使用机场转售的IPLC上网的,那么她们的做法也并不是合规的?还是会被抓起来请喝茶?--不爱思考得猪留言) 2021年11月17日 (三) 14:26 (UTC)回复[回复]
@不爱思考得猪:您仔细读读此次的法条,打击的是提供而不是使用相关工具,youtuber总不会自己开机场吧。。。--伞木 留言 2021年11月17日 (三) 14:48 (UTC)回复[回复]
@AlexLeeCN:那如果所有开机场的都被打击了,李子柒和办公室小野管谁去要IPLC服务呢?还是说两个团队在《网络数据安全管理条例的征求意见稿》正式实施以后都要肉身翻墙了?YouTuber总不会自备IPLC线路吧。--不爱思考得猪留言) 2021年11月17日 (三) 15:35 (UTC)回复[回复]
(~)補充:另外,依据上面提到的数年前肉身墙内机场主被抓案例的逻辑,自建自用代理也需要注意一定的风险……当年编程随想说自己不用自建代理,给出的理由是购买VPS必然留下交易记录。--🔨留言) 2021年11月15日 (一) 02:28 (UTC)回复[回复]
是的,这的确是编程随想一贯的风格。他说自己不缺钱,但是就是怕留下支付证据蛛丝马迹被六扇门摸到然后一锅端。--不爱思考得猪留言) 2021年11月16日 (二) 15:40 (UTC)回复[回复]
沒必要做免責聲明和法律風險提示,這樣會把人嚇跑。--中文維基百科20021024留言) 2021年11月16日 (二) 15:10 (UTC)回复[回复]
还是有必要的,而且特别要强调本站不由管理员运营,以免因“境外反动网站和有害信息”拿管理员开刀。桐生君[讨论] 2021年11月16日 (二) 16:36 (UTC)回复[回复]
同意,还是有必要的。并且现在已经有免責聲明和法律風險提示,在Help:如何访问维基百科#非直接连接里有显示:“本站有义务告知阁下:使用代理服务器可能违反您所在国家和地区的法律,阁下有可能受到相关处罚。”--不爱思考得猪留言) 2021年11月16日 (二) 20:15 (UTC)回复[回复]

镜像站建议都停掉,因为完全符合这个条款,自己翻数据跨境安全网关可能还不符合,但镜像站是肯定的。桐生君[讨论] 2021年11月16日 (二) 16:38 (UTC)回复[回复]

墙外镜像站为何要停掉?难道墙内的法律还能长臂管辖墙外的网站不成?--不爱思考得猪留言) 2021年11月16日 (二) 20:12 (UTC)