Tag: subnet

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 剛好相對應，比較好理解...

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

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊，Akamai 有提供工具，可以看 DNS resolver 的資訊：「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的，這些對外雖然有一個 IP address 在服務，但後面是一整個 cluster，所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個)：

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

而 1.1.1.1 會給假的 ECS 資訊：

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...

Amazon VPC 支援純 IPv6 的網段了

Amazon VPC 支援純 IPv6 的網段了：「Amazon Virtual Private Cloud (VPC) customers can now create IPv6-only subnets and EC2 instances」。

先前機器都還是要設一個 IPv4 位置，所以網段都必須有 IPv4 network space，這次推出使得機器可以跑在 IPv6-only network 上了，不過 Linux 裡面應該還是會有個 lo 與 127.0.0.1...

短時間應該用不到，不過可以先玩看看感覺一下...

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

五月的時候，DuckDuckGo 的 Charlie 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 了...

關於不推薦用 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 的資訊，配到的伺服器的頻寬就不會太差...

新的 DNS Resolver：9.9.9.9

看到新的 DNS Resolver 服務，也拿到了還不錯的 IP address，9.9.9.9：「New “Quad9” DNS service blocks malicious domains for everyone」，服務網站是「Quad 9 | Internet Security and Privacy in a Few Easy Steps」，主打宣稱過濾已知的危險站台...

由政府單位、IBM 以及 Packet Clearing House 成立的：

The Global Cyber Alliance (GCA)—an organization founded by law enforcement and research organizations to help reduce cyber-crime—has partnered with IBM and Packet Clearing House to launch a free public Domain Name Service system.

也就是說，後面三家都不是專門做網路服務的廠商... 於是就會發現連 Client Subnet in DNS Queries (RFC 7871) 都沒提供，於是查出來的地區都不對，這對使用 DNS resolver 位置分配 CDN 節點的服務很傷啊... (或是其他類似服務)

這是 Google 的 Public DNS (8.8.8.8) 查出來的：

;; ANSWER SECTION:
i.kfs.io.               576     IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 21599 IN CNAME TW.kwc.kkcube.com.
TW.kwc.kkcube.com.      188     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.244.238
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.245.238

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 18 05:30:23 CST 2017
;; MSG SIZE  rcvd: 181

這是 Quad9 (9.9.9.9) 查出來的：

;; ANSWER SECTION:
i.kfs.io.               1800    IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 42702 IN CNAME US.kwc.kkcube.com.
US.kwc.kkcube.com.      300     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.245.238
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.244.238

;; Query time: 294 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Nov 18 05:30:27 CST 2017
;; MSG SIZE  rcvd: 181

再來一點是，在科技領域相信政府單位通常都是一件錯誤的事情，我 pass... XD

Amazon EMR 可以在 Private Subnet 裡面執行了...

以前 Amazon EMR 都只能接著 Public IP 跑 (AWS 端會認這個 IP)，現在可以丟進 Private Subnet 裡面跑：「New – Launch Amazon EMR Clusters in Private Subnets」。

看起來主要是半年前的功能的延伸。

在今年五月時 Amazon VPC 內有直通 Amazon S3 的介面，不需要再通過 Internet 處理：「Amazon VPC 的 Private Subnet 不需要透過 NAT 去 Amazon S3 抓資料了」。

不過這個架構上還是需要 NAT 連外 (連到 AWS 的系統溝通)，不論是傳統的 NAT Instances 或是 NAT Gateways (參考先前的文章「AWS 推出 NAT Gateways」)。

emr_vpc_private_subnet_nat_2

總算是搬進內部網路了...

Amazon VPC 的 Private Subnet 不需要透過 NAT 去 Amazon S3 抓資料了

在今天之前，Amazon VPC 裡 Private Subnet 的機器需要透過 NAT 才能連到 Amazon S3 的 Endpoint API 上操作：(NAT instance 會放在 Public Subnet 裡)

出自「NAT Instances」的說明。

但在這個架構中，如果 NAT instance 不夠大台，甚至是流量需求超過 10Gbps 時就會有效能瓶頸了。而目前沒有比較簡單的方法可以解決。(一種解法是拆多個 subnet 跑，透過多個不同的 NAT instance 連出去，但這樣架構又變複雜了)

今天則是公佈了讓內部可以直接存取 Amazon S3 的方式：「New – VPC Endpoint for Amazon S3」。第一波是美國 (扣除美國政府用的區域)、歐洲、亞洲、澳洲。所以是巴西與美國政府兩個區域還沒上：

Amazon VPC Endpoints for Amazon S3 are available now in the US East (Northern Virginia) (for access to the US Standard region), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), and Asia Pacific (Sydney) regions.

這樣是解了不少問題，不過如果可以直接解決 NAT infrastructure 的問題應該會更痛快？