Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務,用客戶的 IP address 放 routing 出去:「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast,不過這邊沒明講:

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6,在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到,以 Cloudflare 的技術架構,應該是都支援?

用自己的 IP 的好處,一個明顯的方向就是 firewall 會好設不少,另外如果需要服務中國或是其他管制地區,比較不會因為 IP space 混用誤殺受到影響?

用 Raspberry Pi 4 與 HDMI-to-USB 組出 KVM over IP 裝置

一樣是在 Hacker News Daily 上看到的專案,弄出便宜的 KVM over IP 裝置:「TinyPilot: Build a KVM Over IP for Under $100」。

主要是他在 Twitter 看到了這則,裡面提到了「Video Capture Cards, HDMI to USB 2.0, High Definition 1080p 30fps, Video Record via DSLR,Camcorder, Action Cam for Live Broadcasting, Live Streaming, Gaming, Teaching, Video Conference」這個產品:

而作者在 eBay 上面也找到了一樣的裝置,但是更便宜 (所以是「親,$11 包郵」?XDDD):

接下來是在接觸 pikvm 的時候發現了 µStreamer 這個專案:

µStreamer is a lightweight and very quick server to stream MJPG video from any V4L2 device to the net.

最後則是發現他使用的 HDMI-to-USB 裝置直接就是輸出 MJPG 格式,連 transcoding 都不用做了,大幅把 latency 降到 200ms:

其實從作者的文章可以知道,你想做的事情說不定在地球上已經有其他人做差不多了,重點是要找出來,而不需要自己硬幹 XD

前陣子爆出「不保留記錄的 VPN」保留了大量的客戶與連線資訊

前陣子 comparitech 發現了宣稱不保留記錄的 VPN 廠商 UFO VPNElasticsearch 伺服器沒有設定好,造成外部可以直接存取,然後發現裡面包含了大量記錄:「“Zero logs” VPN exposes millions of logs including user passwords, claims data is anonymous」,這篇文章的小標把重點先說完了:

UFO VPN exposed millions of log files about users of its service, including their account passwords and IP addresses, despite claiming that it keeps no logs.

目前還是建議在有能力的情況下都自己架,一般常見就是用 OpenVPN,但設定上會比較麻煩一些。如果要方便的話可以用 Openconnect VPN Server (ocserv) 架 server,然後在手機上可以直接用 Cisco 官方提供的用戶端接,像是 Cisco AnyConnect (iOS) 與 AnyConnect (Android),在桌機上一般則是用 OpenConnect 自家的軟體連接。

家裡有 HiNet 的網路的話,可以申請一個固定 IP (透過 PPPoE 的),然後用一台 Raspberry Pi 之類的設備架設。

倒不是說這些 VPN 廠商的服務不能用,只是你必須認知這些 VPN 是拿來繞過地區限制的,而不是為了安全性或是隱私,所以如果是人在外面使用網路,想要避免被商家或是外面的 ISP 看到流量內容,透過自己架設的 VPN 應該會好不少。

雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

架設 MTProxy 加快 Telegram 的速度

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

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

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

關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...

RIPE 的 IPv4 位置發完了

RIPE 在上個禮拜宣佈 IPv4 address 發完了:「[ripe-list] The RIPE NCC has run out of IPv4 Addresses」。

但這不代表不能申請,只是會進到「IPv4 Waiting List」這個列表裡面等待,各種原因取回的會發個這些申請者。

在台灣應該還是沒什麼感覺,因為固網 ISP 手上其實都拿一堆 IP 屯著,讓動態 IP 的架構輪著用,而行動網路上也可以看到不少 ISP 使用 Carrier-grade NAT 之類的架構在跑,最差也還可以拿 Private IP 硬上,暫時也不是太缺...

IPv6 的部份的確有愈來愈好,但還是常常可以看到 IPv4 的 routing 比較好,IPv6 有時候會繞到歐美再回亞洲...

話說起來,應該做看看 IPv6 上的 SmokePing 了,這樣才能比較 IPv4 與 IPv6 的 routing...

Google Cloud Platform 在台灣的機房可以開 Standard Network 的機器了

Google Cloud Platform 一開始是提供 Premium Network,會透過 Google 自家的網路骨幹連到最近的點,然後再透過當地的機房交換出去,這樣可以確保頻寬的穩定性,但成本當然也就比較高...

後來提供了 Standard Network 則是從機房出去後就直接交換,成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇),但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請?),所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了,不確定是已經全開了還是分批開。

測了一下發現網路相當... 爛?是還在調整嗎...

像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題):

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms

然後 168.95.1.1139.175.1.1 也都很差 (61.31.1.1 不給 ping):

PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data.
64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms

--- 168.95.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data.
64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms
64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms
64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms

--- 139.175.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms

不過學術網路倒是還不錯:

PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data.
64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms
64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms
64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms

--- 140.112.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data.
64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms
64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms
64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms

--- 140.113.250.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data.
64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms
64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms
64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms

--- 140.117.11.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms

有需要的人可以測試看看了...

GCE 的 IP 要收費了...

收到信件通知,本來在 GCE 上使用的 Public IP address 是免費的,2020 年開始變成要收 USD$0.004/hr (Standard,約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible,約 USD$1.44/month):

First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.

從 2020 年一月開始生效,但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費),這樣你會知道你的 IP address 費用會吃多少錢:

We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:

January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.

其實整體成本應該是還好,但看到漲價總是不開心... XD