Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

關閉 GitLab 的 nginx,使用自己裝的 nginx

我自己架設的 GitLab 是透過「Install self-managed GitLab」這邊的方法裝進 Ubuntu 系統內的 (我在自己的 wiki 上也有整理:「GitLab」),他會自己下載所有對應的套件,包括了 nginx

但這樣就直接把 TCP port 80/443 都吃掉了,同一台機器要放其他的 virtual host 就比較麻煩,所以找了些方法讓 GitLab 不要佔用 TCP port 80/443。

首先是找到這篇,資料有點舊,但裡面關掉 nginx 的方法還算是有用:「How to setup gitlab without embedded nginx」。

現在只要把 /etc/gitlab/gitlab.rb 裡面的:

  • nginx['enable'] 改成 false
  • web_server['external_users'] 改成 ['www-data']

然後跑 gitlab-ctl reconfigure 讓他更新設定檔,接下來停掉整個 GitLab 再打開 (或是重開機) 讓 nginx 完全失效就可以了。

接下來弄好自己的 nginx 以及 HTTPS 設定,這個部份我自己偏好用 dehydrated,其他人會有不同的偏好設法。

在弄完 nginx 後再來是 proxy_pass 類的資訊要帶進去,這個部份可以參考本來 GitLab 的 nginx 設定檔 (在 /var/opt/gitlab/nginx/conf/ 這下面),其中最重要的就是 GitLab 本身,我們會在 /etc/nginx/conf.d/upstream.conf 裡面寫入對應的 upstream 資訊 (沒這個檔案就自己生一個):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;
}

接下來是在對應的 virtual host 下設定 proxy_pass

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab-workhorse;
    }

另外我有啟用 GitLab 提供的 Mattermost,所以也要翻設定導進去:

#
upstream gitlab_mattermost {
    server 127.0.0.1:8065;
}

與:

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab_mattermost;
    }

都弄好後叫 nginx 重讀設定,接下來應該就會動了... 然後 TCP port 80/443 也算自由了,要掛其他的網域上去應該都 OK。

架設 MTProxy 加快 Telegram 的速度

在台灣如果是透過 HiNetTelegram 是沒什麼問題 (不需要翻牆),不過連結的 preview 以及圖片影片讀取的速度實在很慢,試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看,發現速度都改善很多...

這邊用的是官方提供的 MTProxy,我把安裝的懶人包放在自己的 wiki 上了:「MTProxy」,在 AWS 或是 GCP 上安裝時,因為網卡拿到的是 Private IP 而非對外的 Public IP,需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。

跑一陣子再來看看有什麼可以調整的...

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品,叫做 Amazon RDS Proxy:「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的):

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算:

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料),而如果是 t2 系列的機器,最低是以 2 vCPUs 計算,不是照使用比例算:

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6,算起來頗貴的... 如果 SLA 允許的話,用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話,可以在這些區域測試:

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.

Cloudflare 提供 IPFS 的 HTTPS Gateway

IPFS Gateway 基本上就是個 Proxy,這次 Cloudflare 直接提供 *.cf-ipfs.com 服務:「Continuing to Improve our IPFS Gateway」。

用把 hash 放進 subdomain 的方式讓我想起當年的 Coral CDN 計畫...

Anyway,我覺得對 IPFS 的幫助還是有限,畢竟本來 IPFS 官方就有提供 Gateway,現在只是一個比較快的 Gateway,能做的功能還是那些...

Mac 上讓 SSH 走 Socks5 的方式

在泰國住的飯店提供頗快的網路:

不過到 HiNet 看起來應該是有繞到美國之類的地區?

gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report 168.95.1.1
Start: 2019-04-07T08:16:33+0700
HOST: Gea-Suans-MacBook-Pro.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.20.1                 0.0%    10    1.8   2.0   1.3   3.1   0.6
  2.|-- node-iyp.pool-101-108.dyn  0.0%    10    3.9   3.6   2.7   4.5   0.6
  3.|-- 172.17.36.105              0.0%    10    3.2   4.1   3.2   8.3   1.5
  4.|-- 203.113.44.205             0.0%    10    6.5   5.3   3.9   6.7   1.0
  5.|-- 203.113.44.177             0.0%    10    5.4   4.8   4.0   7.2   1.0
  6.|-- 203.113.37.194             0.0%    10    4.6   6.5   3.0  11.1   2.5
  7.|-- in-addr.net                0.0%    10    3.9   4.4   3.1   5.6   0.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- pcpd-4001.hinet.net        0.0%    10  355.4 356.9 355.1 365.4   3.0
 10.|-- pcpd-3212.hinet.net        0.0%    10  215.6 216.6 214.2 225.4   3.4
 11.|-- tpdt-3022.hinet.net        0.0%    10  219.4 215.9 214.0 221.5   2.5
 12.|-- tpdt-3012.hinet.net        0.0%    10  218.9 217.2 215.0 218.9   1.4
 13.|-- tpdb-3311.hinet.net        0.0%    10  212.5 212.9 211.9 214.1   0.6
 14.|-- 210-59-204-229.hinet-ip.h  0.0%    10  213.5 212.7 212.0 213.7   0.6
 15.|-- dns.hinet.net              0.0%    10  214.4 214.5 213.7 216.0   0.7

這樣有些影音服務只吃台灣 IP 就沒辦法用了,所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet,所以就得找 Mac 上 SSH 要怎麼設定 Socks5。

本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect()),但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理,因為 nc 有支援 Socks5。

所以就變成兩包 ssh 指令:

ssh -D 1081 gcp.server
ssh -D 1080 -o "ProxyCommand nc -X 5 -x 127.0.0.1:1081 %h %p" hinet.server

然後 127.0.0.1:1080 就是打通的版本了,可以讓瀏覽器直接掛上去使用。

至於後來想起來不需要用 Socks5,可以用 ssh -L 而笑出來又是另外一件事情了 :o

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

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

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

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

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

Algolia 從 Heroku 搬到 GKE 的故事

Algolia 是一個搜尋引擎服務,他可以幫你 index 資料後,你直接 query 他取得結果。

在這篇文章裡 Algolia 決定從 Heroku 搬到 GKE:「The Challenging Migration from Heroku to Google Kubernetes Engine」。

在文章只單純就產品與技術面上的需求在討論,像是一開始討論 IP 白名單的問題:

A good example of this complexity is with IP Whitelisting. One of our customers wanted us to crawl from a fixed IP address so that they could whitelist that IP for high-rate crawling without being throttled by their load balancer. Only two engineers were developing the crawler, so we asked other colleagues to set up an HTTP proxy with a fixed IP address. Yet, as the number of customers grew, many more started asking for the same thing, and our infrastructure team told us it was time for us to take care of it ourselves.

不過我更想知道搬過去後的各類成本差異... 省了多少平台費用,以及多少維護人力的差異,不過看起來沒提到 XD

DuckDuckGo 開始改用 Apple Maps

DuckDuckGo 宣佈採用 Apple Maps 當作搜尋頁提供地圖資訊的資料來源:「DuckDuckGo Taps Apple Maps to Power Private Search Results」。

DuckDuckGo 官方的說法看起來應該是 proxy 之類的方式實做,從瀏覽器的連線上看起來是透過 proxy*.duckduckgo.com 傳輸:

We do not send any personally identifiable information such as IP address to Apple or other third parties.

畢竟地圖是砸錢做出來的東西,Apple Maps 的資料應該沒有 Google Maps 豐富,但就搜尋頁上翻起來應該算是夠用?(尤其對歐美區域)

另外「DuckDuckGo switches to Apple Maps for search results」這邊則是給了反對意見,提到 Apple Maps 的品質一直都不怎樣...

AWS 允許 Hybrid Cloud 下的 DNS Query

AWS 對於 Hybrid Cloud (混合雲,通常是講與傳統機房的混搭應用,也就是雲端跟地端的混搭) 推出兩個功能,一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來,讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain):「New – Amazon Route 53 Resolver for Hybrid Clouds」。

兩者都可以自己幹,但就得花功夫自己架設,而且有很多細節得處理:

  • 建立 EC2 instance,在上面跑 Unbound,然後 EC2 instance 的 DNS servers 設定要指到這邊。
  • 由於 EC2 的 DHCP 服務沒有辦法指定發放的 IP range,所以為了多重意外而中獎 (關機的時候剛好有其他機器 DHCP 拿到這組 IP),需要開獨立的 subnet 只放固定 IP 的服務。
  • 為了系統的穩定性,需要在兩個不同 AZ (或是三個) 架設這些 DNS Resolver,所以對應有兩個或是三個 subnet 得建立。

而地端到雲端通常會簡單一些,因為地端通常都已經有內部的 DNS Resolver 可以用,通常只需要在雲上面有 proxy 的角色就可以解決。

不過現在這些 AWS 都直接提供了:

常見的區域都可以用:

Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.

費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來),但畢竟不需要自己管理,而且對於已經有機房的單位應該只是零頭而已:

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.