Tag: tunnel

拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西，GitHub 上的專案頁在 pufferffish/wireproxy 這邊：

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN，而是透過 proxy 協定讓使用者可以使用，這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化，像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是，這是一個 userland 而且不需要 root 權限的實作；這點蠻容易可以理解的，只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通，的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具，看起來是 server 端的實作，支援 TCP 與 UDP：

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...？

SSH 的各種好用的功能

在「An Excruciatingly Detailed Guide To SSH (But Only The Things I Actually Find Useful)」這篇看到在介紹 SSH 的各種好用的功能。

其中當然會提到 tunnel，這部份裡面提到了一張圖，原始文章是「A Visual Guide to SSH Tunnels: Local and Remote Port Forwarding」這邊，圖解 SSH tunnel 的功能 (不過只有 -L 與 -R 的)：

回到原來這篇文章，這篇講的東西比較多一點，關於 tunnel 相關的還包括了 -D 與 -J。

另外提到了 -A、-t、-g 與 ~? 的用法，以及其他各種跟 SSH 有關的工具。

翻了一輪後應該就 -g 還不熟，另外發現 -J (ProxyJump) 居然可以用逗號 , 指定一串跳板機，一路跳進去... 翻了 manpage 發現有寫：

Multiple jump hops may be specified separated by comma characters.

Tailscale Funnel 公開測試

去年 11 月的時候寫過 Tailscale Funnel 的消息：「Tailscale 也推出類似 Cloudflare Tunnel 的產品，Tailscale Funnel」，剛剛則是宣佈公開測試：「Tailscale Funnel now available in beta」。

測了一下，設定不算太難，但有些步驟要做：

  • 在網頁上先允許 Access Controls 內的 Funnel。
  • 然後允許 DNS 內的 HTTPS Certificates。
  • 剩下就是照著文件跑，在本地跑對應的指令。

他的想法是把 *.ts.net 這個網域拿出來 internet 上面用，但他希望 Let's Encrypt 簽的 SSL key 應該要放在本地端，而不是讓 Tailscale 看到內容。

但同樣也考慮到使用者的體驗，Tailscale 不需要使用者自己處理 SSL certificate 一堆事情，而是實做在 tailscaled 這隻程式裡面，讓本地端的程式還是走 HTTP 而非 HTTPS。

對應的，使用者如果想要取得對應的 key 與 cert，也可以透過 tailscale cert 指令取得。

測了一下位置，HiNet 的使用者會透過東京的節點轉進來，拿來跑測試開發機應該是夠用。

以他的用法來說，跟 Cloudflare Funnel 的定位不太一樣，反倒是擠壓 ngrok 這類服務。

Tailscale 也推出類似 Cloudflare Tunnel 的產品，Tailscale Funnel

Tailscale 也推出了類似 Cloudflare Tunnel 的產品，叫做 Tailscale Funnel：「Introducing Tailscale Funnel」。

都是透過 server 本身主動連到 Cloudflare 或是 Tailscale 的伺服器上，接著外部的 request 就可以繞進來了。

不過 Tailscale Funnel 的定位跟 Cloudflare Tunnel 有些差異，看起來 Tailscale Funnel 比較偏向給 dev/stage 環境的用法，Cloudflare Tunnel 像是要跑在 production 的設計？

目前是 alpha 階段，有些限制，像是目前能開的 port：

The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.

另外從技術面上看起來一定得用 TLS 連線，因為他得透過 TLS 的 SNI 資訊來決定是誰：

We can only see the source IP and port, the SNI name, and the number of bytes passing through.

對於已經有用 Tailscale 的使用者來說好像可以玩看看，但另外一點是 Cloudflare 的機房密度很高，這點可能是 Tailscale 也要想一下的問題？

試用 Cloudflare 的 Argo Tunnel

Cloudflare 宣佈讓大家免費使用 Argo Tunnel 了，也順便改名為 Cloudflare Tunnel 了：「A Boring Announcement: Free Tunnels for Everyone」。

Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

Cloudflare Tunnel 的功能就像 ngrok，在用戶端的機器上跑一隻 agent 連到 Cloudflare 或是 ngrok 的伺服器，這樣外部連到 Cloudflare 或是 ngrok 的伺服器後就可以透過這組預先建好的連線連上本機的服務了，常見的應用當然就是 HTTP(S) server。

本來是付費功能，一般使用者應該也不會需要這個功能，這次把這個功能免費丟出來的用意不知道是什麼...

不過既然都免費了，還是花了點時間測了一下，可以發現 ngrok 的設定比較簡單，Cloudflare 的 cloudflared 設定起來複雜不少，不過文件還算清楚，照著設就好。

Anyway，有些事情有了 Cloudflare Tunnel 就更方便了，像是有些超小型的 VPS 是共用 IPv4 address 而且沒有 IPv6 address 的，可以透過 cloudflared 反向打進去提供服務，同樣的，在 NAT 後面的機器也可以透過這個方法很簡單的打通。

順便說一下，現在的 blog.gslin.org 就是跑在 cloudflared 上面了，官方提供的 ARM64 binary 跑在 EC2 的 t4g 上面目前看起來沒有什麼問題，而且比起本來 nginx 都是抓到 Cloudflare 本身的 IP，現在加上這兩行後反而就可以抓到真的使用者 IP address 了：

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

跑一陣子看看效果如何...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing，也就只針對部份 IP range 走進 VPN，其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些，因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器)，但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多，算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能：「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少，目前知道的單位大多也都還是自己架...

將本機開發網站展示給外部看的工具 inlets

要講 inlets 前要先講 ngrok 這個服務。這個服務可以在開發機上主動建立連線到外部伺服器，接著透過這個連線與本機的 web server 溝通，讓外部的客戶可以很方便的進行測試 (通常會開個 Zoom 之類的工具邊討論邊修改)，算是 reverse proxy as a service 的服務。

類似機制的服務還有 Cloudflare 的 Argo Tunnel，不過產品定位不太一樣。

而 inlets 就是 open source 版本的 ngrok，你只要在外部租一台主機就可以用了。左邊是自己的開發機 (像是 Macbook)，右邊則是外部的主機 (租用 VPS)：

不過這個跟開發模式也有關...

Cloudflare 推出 Argo Tunnel

Cloudflare 推出了 Argo Tunnel，可以將內部網路與 Cloudflare 之間打通：「Argo Tunnel: A Private Link to the Public Internet」。

Cloudflare 在去年推出了 Wrap (可以參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」這篇)，這次其實只是改名：

During the beta period, Argo Tunnel went under a different name: Warp. While we liked Warp as a name, as soon as we realized that it made sense to bundle Warp with Argo, we wanted it to be under the Argo product name. Plus, a tunnel is what the product is so it's more descriptive.

看起來沒有什麼新的玩意... 純粹改名字 :o

VPN 的評價

文章的作者試了很多家 VPN 服務，然後文章的標題有點長，有種輕小說的感覺...：「I tested the most recommended VPN providers using my credit card to find the best ones — and which ones you should avoid.」。

不過這種文章有很多東西很主觀，大家心裡有個底就是了...

作者比較滿意的是 TunnelBear 與 OVPN 這兩家，也許等手上 PIA 到期的時候再試看看要怎麼選好了，畢竟 PIA 還是目前最便宜的方案。

用 Facebook Chat 當作 VPN tunnel...

在同一天的 Hacker News Daily 上看到這兩篇，這是怎樣 XDDD：

RMS 對 Facebook 的意見就不提了，來討論後面這個專案：

The idea of this project is to tunnel Internet traffic through Facebook chat (packets are sent as base64), the main component is tuntap and also the Google's Gumbo parser which does the interaction with Facebook (login, send/receive messages, etc.).

用 C++ 寫的... 不過 Facebook 可以通的環境通常可以有其他的 VPN 選擇吧 @_@