强制 Cloudflared tunnel 使用 http2, 解决掉线问题

2023 年 3 月 1 一日附加:
Cloudflare LAX 的数据中心基本被墙的差不多了, Tunnel 最近越来越不好用, 刚刚关掉代理试了一下, 根本连不上了.
用 Tunnel 的小伙伴们不用往下看了, 本文不能解决你的问题, 也许是时候找个其他解决方法了.

最近 cloudflared argo tunnel 很不稳定.

我一开始根本没有意识到 tunnel 不稳定, 直到我跑了一个依赖 cloudflare tunnel 内网穿透的 api server, 才发现 api 的可用性还不到一半的时间, 我得每隔几个小时手动重启一下 cloudflared 的容器.

一开始我认为这是因为 cloudflared 的流量被代理了, 所以就去 openclash 设置了不代理流量, 给容器的源 ip 和目标域名都加了规则. 但是设置完之后不见好居然还更严重了. 我就开始思考难道是 cloudflare 被墙了? 防火墙敢墙 cloudflare?

閱讀全文 强制 Cloudflared tunnel 使用 http2, 解决掉线问题

在 Openwrt 上使用迷雾通透明代理局域网流量

前言

(如果你不想听我 BB, 可以直接跳转到 最后一段: #结论.)

先解释一下为什么要这么做.

我原本用的是 clash + 澳洲 VPS (V2Ray), 奈何最近 GFW 相当疯狂, 从每个星期一封进步到现在的一天一封, 甚至上午换 IP 下午封, 强度这么大, 这谁吃得消? 我尝试使用 Oracle 提供的 API 检测封杀并自动切换 IP, 但是我的功力不到家, 还有就是 Oracle 的文档太过迷惑, 我愣是没写出来.

閱讀全文 在 Openwrt 上使用迷雾通透明代理局域网流量

V2Board 邮件 SSL routines:ssl3_get_server_certificate:certificate verify faile 解决方案

stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

如题, 自己搭建的邮件服务器, 证书采用的是 Lets‘s Encrypt, 确定没有问题. PHP Openssl Extension 已装, 在命令行里跑 echo QUIT | openssl s_client -crlf -starttls smtp -CAfile /etc/ssl/certs/ca-certificates.crt -connect smtp.example.com:587 返回结果正常.

于是简单的读了一下代码, 发现发送邮件使用了 Laravel 提供的 Mail 模块. Laravel Mail 的配置文件位于 config/mail.php, 在 config/mail.php 尾部添加下面这段代码:

'stream' => [
        'ssl' => [
            'allow_self_signed' => true,
            'verify_peer' => false,
            'verify_peer_name' => false,
        ],
    ],
如图所示

保存, 再次发送测试邮件, 发送成功.

搭建並維護一個 Snowflake 網橋

前言

Tor 作為一個公益項目, 每年通過捐贈獲得的收益少的可憐 — 其中一半還是政府捐助的. 去年又碰到了網橋數量嚴重不夠的問題. 我因為經常免費使用 Tor 的服務, 早有想要公益運行一個網橋或者中繼的念頭, 奈何 GFW 對 Tor 的流量高度敏感, 基本是運行半個小時就把 IP 永久封禁, 可謂是心有餘而力不足.

最近 Tor 推出了 Snowflake 協議, 顧名思義, 就是通過無數網友像雪花一樣的努力, 讓極權政府防不勝防, 最終讓萬惡的防火牆被滿天大雪埋葬. 原理是將 TOR 流量加密隱藏在正常的 WebRTC 協議流量中瞞天過海.

閱讀全文 搭建並維護一個 Snowflake 網橋

WordPress + Cloudflared + V2ray 異地組網並隱藏流量

目標

  • 異地組網, 遠程訪問家中環境
  • 結合海外 VPS 翻牆 ( 不在此篇討論 )
  • 使用 V2Ray TLS 加密流量
  • 將 TLS 流量隱藏在正常的 HTTPS 流量中達到混淆目的
  • 使用 Cloudflare 的內網穿透服務, 達到防探測目的 ( 服務器直接和 CF 溝通, 沒有端口暴露 )
  • 使用 Cloudflare 的 CDN 服務, 達到防牆、加速作用

如果你並不是想要做異地組網, 而是想要在 VPS 上跑 (Nginx/Caddy/Apache) + WP + V2Ray, 那麼你其實用不著這麼複雜. 你只需要看這篇文章就可以了.

(這篇博文主要是討論一個沒多少人做過的方案的可行性, 所以你會看到後面還有一大通廢話; 作為教程本文是不合格的, 如果想要尋找教程請出門右轉谷歌搜索. )

網絡拓墣示意圖
閱讀全文 WordPress + Cloudflared + V2ray 異地組網並隱藏流量

為 jsProxy 應用 Material 界面

如果你還不知道的話, jsProxy 是一個基於瀏覽器端實現的網頁代理. 用人話說, 就是你可以把 jsProxy 當作 “翻牆瀏覽器” 使用. 而和雜七雜八的 “翻牆瀏覽器” 不同, jsProxy 不紀錄用戶數據, 而且無需安裝, 隨時可以使用.

因為可以部署在 Cloudflare Workers ( 從雲端運行腳本 ) 的緣故, jsProxy 一直被視為一個很好的白嫖途徑. 不過其他都好, 就是介面有點… 怎麼說呢, 太過復古. 而且 jsProxy 已經長期無人維護, pr 攢了一大堆無人理會, 導致一大堆鏈接無法打開, 默認搜索引擎是谷歌也導致了每次使用它總會被谷歌以機器人的理由擋下來, 體驗非常不友好.

不是我太挑剔, 但是原本的介面真的是有夠醜的

本著 DIY 的精神, 我稍微改動了一下 jsProxy 的代碼, 然後用 MDUI 庫給他前端做了一個美化. 因為我並沒有怎麼學過前端知識, 所以整個網頁現在基本就是一堆 tag soup. 不過總算跑起來了, 而且看著還不賴.

現在 jsProxy 的樣式看起來好多了.

自我感覺良好 ing

得益於 MDUI, 這個網站現在還跟上了 “響應性設計” 的概念, 儘管我完全不知道響應性設計到底是什麼鬼東西. 我修改了默認搜索引擎, 把它改成了 Duckduckgo, 我還刪掉了網站圖標改成了 fontawesome 的字體優化加載速度, 添加了暗黑模式… ( 為什麼要加省略號, 已經沒有可列的了啊 ) 總之, 現在的 jsProxy 絕對比原來的 jsProxy 要好用不只一點.

如果想要體驗的話, 你可以在點擊下方鏈接前往我自己用 CF Worker 搭建的服務, 或者 Clone Git 源碼.

鏈接: jsproxy.justin.education
源碼: git.io/jsproxy-material

WebRTC IP 洩露漏洞

記得惡維事件嗎? 六扇門跨省追捕中學生然後把他們扔進監獄言行拷打一直電到陰毛燒焦為止.
據說有一些完全無辜的網友被攪進這件事情, 就是因為他們曾經瀏覽過或者編輯過惡維, 警方在惡維的數據庫裡查到了他們的 IP.

能上惡維一定是掛了 VPN 的啊? 啊對, WebRTC Leak 就是 Leak 了 VPN 背後的 IP, WebRTC Leak 的原理和 PoC 可以在這裡找到.

這是因為惡維“很走心”的在站點上掛了一個 JS, 利用了 WebRTC 漏洞從而繞過代理紀錄了瀏覽者的真實 IP.

惡俗掛掉了 (舊的), 但是誰都不能說什麼時候某個網站也會掛掉, 帶一大批網友下水 (品蔥, 比方說) . 畢竟正常人誰會注意網站加載了那個 JS, 有沒有用 WebRTC. 說不定 JS 還是加密的, 根本防不勝防.

你可以在 這個網站 檢測自己有沒有中招.

解決方案

手機端如果是使用 Chrome , 除了掛 V2 之類的代理其他根本就無解, Firefox 還可以自己更改設置, Chrome 已經不允許了

PC端的話可以使用插件, 可以改設置 ( 我推薦使用插件的啦 ), 比如 Firefox 就有這款插件.

當然, 電腦手機都可以使用 Tor 瀏覽器來規避這種風險; 我的建議是, 就不要使用手機瞎幾把瀏覽境外反動勢力集團網站.

如果手頭暫時沒有 Tor, 只是想要簡單的瀏覽網頁 ( 沒有登錄等需求 ), 可以使用網頁代理來訪問網站. 你也可以使用我手頭的這個 JSProxy 反向代理, 親測可以防止 WebRTC leak. ( 因為原作者太長時間沒有更新, 這個 JSProxy 好像不能 Pass Cloudflare CDN 保護, 訪問品蔥等網站會一直卡在 JS 詢問頁面上. 所以如果有 Tor 還是用 Tor 吧.

四月加速月報

我現在正在使用加拿大的服務器, 仍然是老朋友 Vultr.

但是和美國的服務器不同, 同樣是被墻, 這次的 ping 表現出一些有趣的特徵.

Ping的結果

觀察淪陷區的圖案, 我們可以發現雖然是被墻, 但是墻的方式也根據運營商和地區有所不同. 比如說北京的騰訊雲和阿里雲, 就更加傾向於隨機丟包, 而江蘇聯通與青島阿里雲則是丟包 + 延遲. 至於江蘇的移動則是基本不管不顧!

從這次 Ping 的結果其實我們可以略窺墻的策略 — 對於服務器來說側重於干擾通信質量, 而對於對通信質量要求不那麼高的用戶來說是加大延遲來達到勸退目的.

另外, 這種不是一刀切, 而是不同線路不同策略的築牆方式也證明了傳統意義上的, 在大陸主要網絡出口設卡的理論已經不適用於現代的中國網絡審查 — 如今中國網民與之對抗的, 乃是一張三維立體, 相互響應的巨大審查網絡. 更壞的是, 我們甚至對這張日益完善的網絡一無所知, 換言之, 它對我們來說是完全的黑箱狀態!

在 2021 年, 居然還仍然有不少網友認為翻牆僅僅是 “vpn” 而已, 這顯然已經落後於加速的步伐. 希望未來能有更多自由民參與到對抗中共的言論審查中去, 開發更多門檻更低的上網方式; 而對於我們這些牆內的P民來說, 最好的方式應該就是將自己 Keep up to date, 手頭常備多種方式, 並用郵件訂閱一些自由的信息來源!

轉載: 從系統概念到OSI模型

版权声明
本文轉載自编程随想的博客, 文中所述一切不代表本人立場. 原文鏈接:
https://program-think.blogspot.com/2021/03/Computer-Networks-Overview.html

★本文的目标读者

  今天这篇的标题是“扫盲”,也就是说:即使那些完全不懂 IT 领域,也不懂通讯领域的读者,依然能看懂(至少能看懂一部分)。为了做到这点,俺会尽量使用通俗的比喻,并适当加一些示意图。
  另外,就算你已经比较了解网络通讯领域,本文中提到的某些部分,也可能是你所不知道的。也就是说:懂行的同学,看看此文,也会有帮助。
  本文的标题特地强调了【系统性】——俺希望这篇教程能帮助读者对“计算机网络”这个领域进行系统性学习(何为“系统性学习”?请看这篇教程
  为了做到【系统性】这个目的,这篇教程很长。俺开博12年,这篇的长度估计能排到前5名。建议大伙儿慢慢看,不要着急。

閱讀全文 轉載: 從系統概念到OSI模型

IP 再次被關懷

IP再次被GFW關懷了。
這幾個月GFW發作 頻率之高,密度之大,都是去年下半年所沒有的。
Vultr中美國的IP已經有一大批被牆掉了,看起來GFW是早有準備。
我有點納悶,可能是因爲兩會的原因GFW才這麼興奮。

我有億點點納悶啊

不過話說回來,我的服務器鏈接都是直接KCP不帶任何僞裝的(圖快),不牆它牆誰呢?
聽說Vultr支持命令行管理了,很興奮。希望可以搞一個自動換IP的東西出來。
最近事情多,來不及更新博文。以後被牆都要寫一篇博文證明這個博客還活着。