Tag: cidr

合併 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 行，但總是有個方法可以整理起來用，不用自己刻一堆程式處理...

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 上...

雞肋功能：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

AWS Public IP 的變動可以透過 Amazon SNS 訂閱

在「Subscribe to AWS Public IP Address Changes via Amazon SNS」這邊提供利用現有的 Amazon SNS 所提供的新功能。

依照說明，訂 arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged 就可以了：

會收到類似於這樣的東西：

{
  "create-time":"yyyy-mm-ddThh:mm:ss+00:00",
  "synctoken":"0123456789",
  "md5":"6a45316e8bc9463c9e926d5d37836d33",
  "url":"https://ip-ranges.amazonaws.com/ip-ranges.json"
}

不過之前就可以 polling 了，這個功能好像還好...

Ping 整個 IPv4 的結果...

目前的電腦與網路已經有能力一次掃完整個 IPv4：「The result of pinging all the Internet IP addresses」。

用 ping 不一定準確，因為目前 Windows 作業系統預設會開啟防火牆，不會接受 ping。不過仍然是個有趣的方法 :p

首先是整個 IPv4 address space 只有 7% 的 IP address 會回應 ICMP ping：

另外有各 /8 的回應數量：

可以看到很多是空的... XD