Tag: ipv4

GKE 在推廣拿 240.0.0.0/4 來當 Private IP 用

看到「Leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE」這篇，GKE 在推 240.0.0.0/4 當作 Private IP 用，可以看到文章裡面一直在說 240.0.0.0/4 跑起來沒有什麼問題，也可以透過 NAT 連到 internet 上的其他服務...

看到想用 240.0.0.0/4 大概是 10.0.0.0/8 不夠用的概念，本來一開始腦袋閃過去是 65536 個 IP 不夠用 (心裡覺得「喔在 microservice 架構下公司大一點，把 container 開成這樣好像也合理」)，突然發現不對，10.0.0.0/8 是三個 256 的乘積，是 16M 個 IP address...

16M 的 IP address，如果一個 IP address 對應到一個 container，以 Google 在 2023 年全球有 182K 員工來看，平均下來每個員工可以開 87 個 container？(不能再多了？)

有這樣的概念後回頭讀這篇還蠻「有趣」的...

Backblaze 宣佈支援 IPv6

Backblaze 發了「Announcing Support for IPv6」這篇公告，宣佈支援 IPv6。

不過跟 AWS 採用 opt-in 的作法不太一樣，他們是直接全上 IPv6 了：

No action needed on your part: Unlike some of the traditional cloud providers, we chose to use the same endpoint URL and let the client choose whether or not to use IPv6. This allows for any systems already IPv6 enabled to benefit immediately. In fact, if your systems are IPv6 enabled and you are a B2 customer using the S3 compatible API, you might already be connecting to us over IPv6 now.

看起來沒有切換時間，是 rolling update：

While our IPv6 deployment isn’t completely done yet (we’re phasing the roll out through our environment), we thought we’d share some of the decisions we made that affect performance and functionality.

這種作法對於企業客戶來說看起來不是什麼好事，如果機器的 IPv6 stack 是爛的，而且沒有 Happy Eyeballs 或是類似可以偵測哪邊是通的演算法的話，就直接爛掉了。

往 IPv6 推是蠻重要的沒錯，但這麼簡單粗暴好嗎 XD

AWS 的 VPC 可以設定 Private IPv6 address 了

AWS 的 VPC 以前都只能設定 public IPv6 address，現在總算是可以設定 private IPv6 address 了：「AWS announces private IPv6 addressing for VPCs and subnets」，另外一篇講的比較詳細：「Understanding IPv6 addressing on AWS and designing a scalable addressing plan」。

IPv6 address 的熟悉度沒有 IPv4 address 高... 看起來 AWS 所提到的 private 包括了 GUA 與 ULA：

Private IPv6 addresses on AWS can include ULA, which are intended for local communication, and private GUA, which could be globally routable according to protocol definition.

GUA 好像是就是拿 public ip 區段用 (反正 IPv6 區段夠大)？反而是 ULA 這邊用的 fd00::/8 跟以前 IPv4 的 private range 剛好相對應，比較好理解...

合併 GitHub Actions 的 IP address

在 GitHub 官方文件「About GitHub's IP addresses」中，是有提到 https://api.github.com/meta 這組 API endpoint，可以取得當下的 GitHub Actions 所使用的連外 IP address，不過如果你實際掃下來後會發現量相當大，以現在的情況來說，IPv4 address 有 3708 筆，IPv6 address 則有 801 筆：

$ cat github-actions-ipv4.txt | wc
   3708    3708   58233
$ cat github-actions-ipv6.txt | wc
    801     801   17522

實際去看的時候會看到一些吐血的，像是這包 /31 的：

13.105.49.0/31
13.105.49.2/31
13.105.49.4/31
13.105.49.6/31
13.105.49.8/31
13.105.49.10/31
13.105.49.12/31
13.105.49.14/31
13.105.49.16/31

這包還真的就整整 128 筆，你就不能輸出個 13.105.49.0/24 嗎...

用 ChatGPT 問了要怎麼解決，被提示有 netmask 這個工具可以用，不需要另外自己編譯，可以直接用 apt 裝起來然後倒進去讓他跑就好，整包搭配 jq 與 HTTPie 處理掉 (換 curl 基本上也沒問題)：

netmask --cidr -- $(http https://api.github.com/meta | jq -r '.actions[]')

Update：看到資安的朋友按讚突然想到，這邊用了 $() 把資料丟到 command line 包裝，可能會有安全上的顧慮，請自己斟酌...

不過整包 (IPv4 + IPv6) 還是有 3187 行，但總是有個方法可以整理起來用，不用自己刻一堆程式處理...

測 IPv4 NAT VPS，以及架設 HTTPS Proxy

因為 AWS 開始收 Public IPv4 address 費用的關係 (而且頗貴，參考「AWS 將開始收取 IPv4 的 Public IP 費用」)，我把其中一台主機改成只有 IPv6 address 後遇到不少問題 (在「把 AWS 上的 EC2 instance 改成 IPv6-only」這邊)。

由於有 proxy 的需求，剛好找機會玩一下 IPv4 NAT VPS... 這種 VPS 最基本的大概就是會給一個 IPv4 address 上 non-standard port 當作 SSH port，讓你可以連進去管理；另外通常會給 port forwarding 的功能，而且是固定不能換的，讓你可以開一些 port 出來用。

我的用途是 IPv6 address 的 proxy，所以要找有給固定的 IPv6 address 的，另外希望跑在日本，這樣其他用途也比較方便。

過年期間翻了一下找到 NAT VPS，有 256MB 跑個 proxy 類的應用應該還 OK，實際上是 256MB RAM + 64MB swap 的 OpenVZ 類環境，kernel 有到 5.2.0 還算堪用，上面可以選 Ubuntu 22.04 安裝。

費用的部分 US$7/year 還行，網路上是有看到 128MB RAM 的 機器，但這樣連裝東西都綁手綁腳的，太容易 OOM。

(剛拿到機器的時候還試著裝 Percona Server for MySQL，結果就 OOM 跑不完 setup 的流程，看起來得自己改設定混過去，但只是想確認 256MB RAM + 64MB swap 可以弄到什麼程度，就反安裝了...)

在上面把想測的東西測試完後，實際的 proxy 設定比較簡單... 先設定一個只有 IPv6 address 的 domain 申請 Let's Encrypt 的 SSL certificate，然後掛給 Squid 用。

然後在 IPv6-only 的機器上用 curl -v --proxy https://username:password@proxy-jp.example.com:12345/ https://home.gslin.org/robots.txt 確認沒問題後就可以把服務都掛過去。

有些服務會吃環境變數 HTTP_PROXY 與 HTTPS_PROXY，有些是在設定檔內設定，基本上都是照著文件設就可以了。

我遇到的 application & library 都可以吃 HTTPS Proxy 協定，就沒什麼大問題... 如果有遇到不行的，也可以考慮在 Squid 裡面直接放行特定的 IPv6 address。

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡，兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet，這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet，但我希望 VM 是走社區網路，所以用 bridge mode 設定到網卡上，用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到，前幾天用 Line 傳照片的時候很慢 (之前就有發生了，一直忘記去追問題)，花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢，這點可以從 Speedtest 的測試結果看到：

先講最後的結論，在交叉測了很多組合後，我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled：

回到當時抓問題的情況，當時先用筆電與 host 測試都沒看到問題，所以看起來應該是 VM 裡面的狀況，但不確定是什麼情況，畢竟不是斷掉...

由於下載速度正常，只有上傳速度卡住，一開始想到的是跟 MTU 相關的問題，所以找了指令降到 1400 後測試，還是一樣...

後來先把 VM 的網路改成 NAT，再測試上傳速度就正常了...

接著想要換個網路卡類型看看，結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了，但想說先去看看 Windows 10 網卡設定裡面的設定，結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗？)。

然後一關就正常了，交叉再開關兩次確認這個參數有影響，就肯定這個 workaround 應該是有效了...

另外在自己找完問題後，在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

把 AWS 上的 EC2 instance 改成 IPv6-only

因為「AWS 將開始收取 IPv4 的 Public IP 費用」的關係，先試著把其中一台 EC2 instance 改成 IPv6-only，結果遇到不少問題...

首先是對外服務的部分，本來想用 CloudFront 擋在前面，但 CloudFront 到現在還是不支援 IPv6-only origin：「CloudFront support for IPv6 origins」，所以這邊的選擇變成是 Cloudflare。

第二個是 AWS 自家的 API 還是有些沒有 IPv6 address，像是取得 AWS 擁有的 IP pool 的 https://ip-ranges.amazonaws.com/ip-ranges.json (本來是要取得 CloudFront 的區段，用在 nginx 的設定裡)。

另外就是周邊的問題，很多服務都沒有 IPv6 address，像是 api.slack.com：

各種 proxy 與 NAT 架構還是必要的措施...

捷克政府宣布 2032/06/06 政府網站將停用 IPv4 服務

看到「Czech republic sets IPv4 end date (konecipv4.cz)」這篇，捷克政府公告了政府網站將在 2032/06/06 停用 IPv4 服務：「Czech republic sets IPv4 end date」。

On 17 January 2024, the Government of the Czech Republic approved the material "Restarting the implementation of DNSSEC and IPv6 technologies in the state administration". On the basis of this decision, the Czech state administration will stop providing its services over IPv4 on 6 June 2032. Thus, the Czech Republic knows its IPv4 shutdown date.

剛好昨天在試著將手上 AWS 的 EC2 instance 拔掉 IPv4 address (因為 2024/02/01 開始收費，參考先前寫的「AWS 將開始收取 IPv4 的 Public IP 費用」)，結果還是遇到相依服務還沒有上 IPv6 endpoint 的問題，如果要轉移的話得開 DNS64 與 NAT64，但因為目前就只有兩台小機器在 AWS 上，在上面租 NAT64 或是自己架 NAT64 的費用反而比付 IPv4 address 的費用還貴，就先暫時丟著了。

我這邊遇到的問題是 api.slack.com 目前只有 IPv4 address，這邊因為是走 HTTPS，也許可以靠其他在有 IPv6 address 的 VPS 上的 proxy server 解決 (我剛好有租一些 VPS instance)，這幾天再來看看怎麼弄...

AWS 的 VPC 開放自訂 IPv6 CIDR 了，但還是有 4 的倍數的限制...

AWS 的公告，VPC 裡的 IPv6 可以自訂 CIDR 了：「VPCs and subnets now support more sizes for IPv6 CIDRs」。

不過還是有限制，首先是 VPC 的大小必須是 /44 到 /60 中 4 的倍數，也就是只有 /44、/48、/52、/56 以及 /60 這五個可以用，而 subnet 也有類似的限制，但從 /44 到 /64，所以剛好就是多了 /64 可以用：

Amazon VPC allows customers to create VPCs and subnets of different sizes using IPv6 CIDRs. With this capability, customers can now create VPCs in sizes between /44 and /60, and subnets in sizes between /44 and /64, in increments of /4.

先前的限制是 VPC 只能給 /56 以及 subnet 只能給 /64 的搭配，是個「可以動」但總是覺得「...」的設計：

Before today, AWS supported one standard IPv6 CIDR block size of /56 for VPC and /64 for subnet, whereas IPv4 CIDR block size were flexible for both VPCs and subnets.

不過我實際在 ap-northeast-1 上測試，發現如果是 AWS 發的 IPv6 address，固定就是 /56 的大小，然後 subnet 在選擇的時候可以選 /56、/60 與 /64。

這邊提到 VPC 可以選擇大小，應該是其他方式帶進來的 IPv6 address？

另外這次的 /4 的遞增限制，我猜是 AWS 裡面 SDN 上面的限制？IPv4 的 CIDR 有 33 個大小 (/0 到 /32)，IPv6 上面如果也處理 33 個的話，反過來設計剛好是 /4 遞增的 workaround？

不過話說回來，我記得前陣子 AWS 公佈要收 Public IPv4 address 的費用時 (參考「AWS 將開始收取 IPv4 的 Public IP 費用」)，Hacker News 上有人抱怨還是有很多 AWS 的服務是 IPv4 only，在純 IPv6 network 上面是不太會動的；把這些服務的 IPv6 endpoint 生出來應該要趕快放到 roadmap 上...

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.