GCP 的 IPv4 也要漲價了

前幾天收到 GCP 的信件,提到 2024/02/01 開始 IPv4 address 要漲價了,在「External IP address pricing」這邊也可以翻到這些資訊。

External IP 的部分,漲 25%:

Static and ephemeral IP addresses in use on standard VM instances will go from $.004 to $.005.

Static and ephemeral IP addresses in use on preemptible VM instances will go from $.002 to $.0025.

用一個月 720 小時算,一般 VM 的費用等於是從 $2.88/mo 漲到 $3.6/mo 左右的費用。

Cloud NAT 吃的 IPv4 address 的部分,從本來沒有收變成要收費:

Static and ephemeral IP addresses mapped to Cloud NAT Gateway will go from No Charge to $0.005.

IPv6 Excuse Bingo (IPv6 理由伯賓果?)

在「AWS IPv4 Estate Now Worth $4.5B (toonk.io)」這邊的討論意外的看到「IPv6 Excuse Bingo」這個網站...

這個 bingo 是動態的,每次 reload 都會有不同的版本出來,理由超多...

不過實際用 IPv6 network 後會發現各種鳥問題真的多,之前 (到現在) 最經典的就是 HECogent 的 IPv6 network 因為錢的問題談不攏而不通的問題,在維基百科上面就有提到從 2009 年開始就不通了:

There is a long-running dispute between the provider Cogent Communications and Hurricane Electric. Cogent has been refusing to peer settlement-free with Hurricane Electric since 2009.

所以夠大的服務如果要弄 IPv6 都得注意到這點,像是 CDN 或是 GeoIP-based load balancer 就不能把 Cogent 的用戶導到 HE 的位置上面,反之亦然。

不過話說 AWS 手上有 128M 個 IPv4 address,整個 IPv4 address 的空間也才 4.29B,也就是說光 AWS 手上就有大約 3% 的 IPv4 address 空間,如果扣掉不可用的區段的話就更高了...

AWS 將開始收取 IPv4 的 Public IP 費用

一個蠻大的改變,AWS 宣布所有的 IPv4 address 將在明年二月開始收費:「New – AWS Public IPv4 Address Charge + Public IP Insights」。

這包括了有掛在 EC2 上面的 IPv4 address:

We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not (there is already a charge for public IPv4 addresses you allocate in your account but don’t attach to an EC2 instance).

費用算是相當貴,$0.005/hr 已經比 t4g.nanous-east-1 的 $0.0042/hr 還貴了。

另外一個有趣的點是 Jeff Barr 會自己貼到 Hacker News 上?在「AWS Public IPv4 Address Charge and Public IP Insights (amazon.com)」這邊可以看到。

回到原來的主題,改跑 IPv6 only 會有兩個方向的流量要解決,一個是從機器連出來的部分,另外一個是從外面連到機器的部分。

對於比較大的服務,連出來的部分是可以靠 NAT64 類的方式處理掉 (但如果用 AWS 服務的話也很貴,參考 AWS 的 DNS64 and NAT64),或是透過 socks5 proxy 與 http proxy 解決。

而比較小的單機 (像是當 VPS 用的 EC2 instance) 似乎就沒有太好的解法了。

另外從外面連到機器的部分,如果只有 HTTP(S) protocol 還可以加減透過 CDN 解 (像是 Cloudflare 或是 AWS 本家的 CloudFront),但 SSH 類的服務就稍微麻煩了,台灣要弄到便宜的固定 IPv6 address 有點麻煩,HiNet 的企業固定制是有對應的方案:「HiNet固定制IPv6服務說明」,但最低的 16M/3M 也要 $1292/mo (大約是 US$41/mo),可能要找有提供固定 IPv6 的 VPS?

雖然是個很靠悲的事情,但這也讓雲端架構裡面朝 IPv6 的動力多了點...

6to4 在 2015 年就 deprecated 了...

找資料才發現 RFC 7526 廢掉 6to4 了:「Deprecating the Anycast Prefix for 6to4 Relay Routers」。

看起來像是無法解決的技術問題:

While this makes the forward path more controlled, it does not guarantee a functional reverse path.

去程的部份比較沒問題,但回程的部份就不一定會動。

不過目前看起來 HE 的 192.88.99.1 還有在運作,真的用 6to4 連 IPv6 network 的人至少還有機會動,等之後 IPv6 更普及應該會慢慢退場...

Google One 的使用者都有 VPN 服務可以用了...?

MacRumors 上面看到 Google 提供 VPN 服務給所有付費的 Google One 使用者使用:「All Paid Google One Subscribers Now Get VPN Access」。而 Google 的公告在這裡:「New security features for all Google One plans」。

主打隱私性,避免被追蹤 IP 位置之類的:

VPN by Google One adds more protection to your internet activity no matter what apps or browsers you use, shielding it from hackers or network operators by masking your IP address. Without a VPN, the sites and apps you visit could use your IP address to track your activity or determine your location.

看到這則留言,很貼切 XDDD

Google running a VPN is like McDonalds running an exercise gym.

不了謝謝 XDDD

ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

Ubuntu 下面搞 Multi-home 架構

家裡的 internet 架構大概是這樣 (省略過其他裝置):

一邊是 HiNet 的線路直接接中華的數據機 (modem),這段是用 PPPoE 撥接;另一邊是第四台網路 (北都),另外上面寫的 Switch 應該是 IP 分享器 (一台 ASUS 的機子,刷 DD-WRT),作圖的時候寫錯了...

最後是電腦的部份,我的桌機是跑 Ubuntu,用兩張個不同的實體線路 (界面分別是中華的 enp4s0 與第四台的 enp6s0f0) 接到了這兩個不同的網段上面。

打算跑 source routing 的架構來善用兩邊的頻寬,想法上面大概是這樣拆解:

  1. 機器本身有個 192.168.3.x 的 static ip。
  2. 針對 source ip 是 192.168.3.x 的封包,預設會往 192.168.3.254 這台分享器丟,然後 NAT 出去。
  3. Squid 在本機上跑一個 proxy server,指定 source ip 是 192.168.3.x

有了這樣的架構,我就可以在瀏覽器上面就透過 SwitchyOmega 這類的套件,指定某些網段要走第四台的頻寬出去了。

另外可以指定 http proxy 的服務也可以透過這個方法往第四台的線路連出去。

其中第二點需要把 source ip 是 192.168.3.x 的封包丟到 192.168.3.254 這段需要一些設定,首先是需要設定一個獨立的 routing table,我是在 /etc/iproute2/rt_tables 裡面放:

2       second

然後因為我是透過 NetworkManager 在管理網路界面的,我希望在 enp6s0f0 啟動時自動設定這個 source routing 邏輯,所以我在 /etc/NetworkManager/dispatcher.d/99-enp6s0f0 這邊寫了:

#!/bin/bash

interface=$1
event=$2

if [[ "$interface" == "enp6s0f0" && "$event" == "up" ]]; then
    ip route add default via 192.168.3.254 table second
    ip rule add from 192.168.3.0/24 table second
fi

然後要記得把這個檔案 chmod 755 讓他可以執行。

接著是 Squid 的設定,在 /etc/squid/squid.conf 裡面這樣寫:

#
http_access allow all
#
access_log /var/log/squid/access.log squid
cache deny all
cache_dir null /tmp
cache_log /dev/null
cache_mem 8 MB
dns_v4_first on
forwarded_for off
http_port 3128
tcp_outgoing_address 192.168.3.x

其中最後的 192.168.3.x 換成自己的固定 IP address。這邊因為 traffic 基本上都是 HTTPS 了,也不需要開 cache,就這樣設定...

這邊比較特別的是 dns_v4_first 的設計,這個是讓 Squid 儘量用 IPv4 的位置連線。這是因為北都的網路沒有提供 IPv6 位置,所以如果網站的 DNS 如果有 IPv6 位置的話就會從 HiNet 這邊的 IPv6 出去了...

另外 ping 與 MTR 之類的工具不會動在這這樣的架構下是正常的,因為這些工具會自己組合 raw packet 丟,不是透過 Linux 的 network stack 處理,所以不會被我們指定的 ip rule 解析。網路上看起來是有方法可以 mitigate,但我就先放著了...

這樣看起來還算堪用,先這樣用一陣子看看... 先前是在 Raspberry Pi 上面跑個 proxy server 導流量,但會受限於 Raspberry Pi 的硬體限制,效能上面就普普通通,現在直接用桌機拼看看...

Pointer tagging

Hacker News 上看到「Pointer Tagging for x86 Systems (lwn.net)」這篇,在講目前的 64 bits 環境下還不可能提供整個 64 bits 可以定位的位置,所以 pointer 裡面比較高的那些位置就可以被拿來挪去其他用的想法。

先算了一下數字,如果以 8 bits 為一個單位來算,之前經典的 32 bits 定位空間是 4GB,40 bits 是 1TB,這兩個都已經有機器可以做到了 (AWS 提供的 u-12tb1.112xlarge 是 12TB)。

接下來的 48 bits 的時候可以到 256TB,這個不確定目前有沒有單一機器可以做到 (印象中 IBM 好像很喜歡幹這個?),56 bits 則是到 64PB,最後的 64 bits 則是 16EB。

真的是沒注意到...

使用 Tor 的 .onion 位置,而非透過 Exit Node 存取網站的好處

在「Twitter 的 Tor Onion 位置」與「BBC 這次拿出短波廣播...」這兩篇我都有在懷疑為什麼要提供 Tor.onion 位置,不是直接透過 exit node 連出去就好了嗎,結果今天看到「Why offer an Onion Address rather than just encourage browsing-over-Tor?」這篇在解釋。

對使用者來說,用 .onion 的好處是隱私性會更好,因為 exit node 本身不一定安全,必須透過 HTTPS 保護才有基本的防護,而且就算用了 HTTPS 還是可以從 HTTPS 的 handshake 得到不少資訊。

對網路本身來說,exit node 算是稀缺資源,大多數人可以架 Tor 的 relay node,但沒辦法做 exit node,因為 exit node 的特性會導致常常收到各種警告。因此能用 .onion 位置存取,也會降低對 exit node 的壓力。

另外 CA/Browser 在 2020 的時候就允許發出 .onion 憑證:「讓 Tor 的 .onion 支援 HTTPS」,看起來應該也是多一層保護...