EC2 API 支援 IPv6,以及 Lightsail 支援 IPv6...

看到 AWS 丟出了兩個有點「有趣」的消息:「Amazon EC2 API now supports Internet Protocol Version 6 (IPv6)」、「Amazon Lightsail now supports IPv6」。

先是 EC2 的 API 支援 IPv6 的消息,但也不是全部都支援了 (亞洲區只有印度有支援,新加坡、日本、南韓與香港都沒在上面):

Usage of Amazon EC2’s new dual-stack endpoints are available at no additional charge. The new endpoints are generally available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Mumbai) and South America (São Paulo).

不過畢竟也不是直接面向使用者的部份,不算太意外就是了... 但另外聽到 Lightsail 支援 IPv6 的消息就比較意外了:

Amazon Lightsail now supports Internet Protocol version 6 (IPv6) on Lightsail resources like instances, containers, load balancers and CDN. With this launch, Lightsail resources operate in dual-stack mode, accepting both IPv4 and IPv6 client connections. This helps unlock application scenarios where some end user clients are IPv6 only.

本來以為 EC2CloudFront 有的東西在 Lightsail 上都會有,原來 IPv6 是沒支援的啊,這功能補的好晚...

Amazon (AWS) 手上有全世界 3% 的 IPv4 可用位置?

看到「Amazon owns more than $2B worth of IPV4 addresses」這篇提到,算了一下才發現 Amazon (AWS) 手上有超多 IPv4 位置...

As of today, December 11, 2020 AWS self reports owning 109,847,486 IPV4 addresses - at a price of $20 this is almost $2.2B and at $30 it’s almost $3.3B.

這邊要算可用的 IPv4 位置不能直接拿 2^32 算,需要扣掉特殊用途的...

最大的兩組是 Multicast 與保留不用的部份,分別是 224.0.0.0/4240.0.0.0/4,這邊有 32 個 Class A 的空間,再扣掉 0.0.0.0/810.0.0.0/8127.0.0.0/8 這三個 Class A 的空間,然後其他零星小的算一算再全部抓起來扣一扣,Amazon (AWS) 手上掛了將近全世界 3% 的 IPv4 可用位置,相當驚人...

Google 的好像沒有完整的,只有 Google 自家服務的,沒有包括 GCP...

Cloudflare 拔掉使用 Cookie 分析的功能

這兩則應該可以一起看,雖然相差了兩個多月。

首先是今年九月底的時候提供隱私優先的分析系統:「Free, Privacy-First Analytics for a Better Web」,接下來是最近 (十二月) 宣佈要把 __cfduid 這組 cookie 拔掉:「Deprecating the __cfduid cookie」。

文章裡面沒有提到現在是怎麼偵測的,但我猜是瀏覽器的 fingerprint 資料已經足夠辨識了,不需要用到 cookie,這點可以參考 EFF 的「Cover Your Tracks」。

所以 privacy-first 這件事情也只是程度上而已,為了要防禦 bot,還是得正確辨識出不同的使用者,也就是說,現在不用 cookie 不代表 privacy 就高很多。不過這的確是試著在技術上努力降低疑慮就是了...

真的想要在 internet 上隱藏身份的人還是用 Tor 吧,基本上最少應該拿 Tor Browser,更小心一點應該用 Tails 這類軟體。

EC2 的 Monitoring 提供更多關於限流的資訊

AWS 對於 EC2 的網路推出了五個新的監控指標:「Amazon EC2 announces new network performance metrics for EC2 instances」。

看起來都是跟限流有關的指標,看起來是在壓榨機器極限時會用到:

The new metrics inform customers in real time of network traffic impacted when instance allowances for inbound and outbound bandwidth, packets-per-second (PPS), connections tracked and PPS to link-local services are exceeded.

需要有最新的 ENA driver 才會提供 (看了一下現有的機器沒出現這些值 XD):

These metrics are available today in all global commercial AWS regions on instances running the latest version of the Elastic Network Adapter (ENA) driver with support for Linux, Windows ENA driver support will be available soon with version 2.2.2.0.

不另外收費:

They can be accessed from within the instance at no extra cost using simple command line tools.

這個功能在所有 AWS 商業區以及 GovCloud (US) 都已經上線:

Instance Level Network Performance Metrics is available in all AWS Commercial and GovCloud (US) Regions, with the exception of China (Beijing) and China (Ningxia).

先記錄起來就好,一般用法應該都還好...

AT&T 網路的問題

Hacker News Daily 上看到個有趣的 troubleshooting 過程,AT&T 的線路會造成 random bit flipping 的問題,另外在 Hacker News 上的討論野蠻熱鬧的:「AT&T Fiber in the SF Bay Area is flipping bits (twitter.com/catfish_man)」。

有人生了一個 script 出來測試,這隻 script 會抓 www.example.com 的 HTTP 與 HTTPS 結果比較,從下面大家的留言回報,可以看出來有 random bit flipping 的問題:「bmastenbrook/example-test.sh」。

然後總算是解決了:

可惜看不到 AT&T 的回應,大家只能猜測是 memory 相關的問題,也許壞的部份有多個地方,造成 ECC 機制在某些情況下不夠用...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

AWS 推出了 AWS Network Firewall

AWS 推出了 AWS Network Firewall,可以在 VPC 層做更多細緻的設定了:「AWS Network Firewall – New Managed Firewall Service in VPC」。

本來的 Network ACLs 的設計也是對 VPC 做過濾,但就是很標準的 stateless filtering:

Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

而這次推出的 AWS Network Firewall 引入了 stateful filtering 的能力:

另外介紹裡面也提到支援 Suricata 的語法,不過太久沒碰 IDS 這塊了,我只知道 Snort

A stateful rule group with Suricata compatible IPS rules has all settings defined within the Suricata compatible specification. For example, as following is to detect SSH protocol anomalies. For information about Suricata, see the Suricata website.

目前支援的區域很少,只有 us-east-1us-west-2eu-west-1 可以用:

AWS Network Firewall is now available in US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions. Take a look at the product page, price, and the documentation to learn more.

另外價錢上不算便宜:「AWS Network Firewall Pricing」,比較特別的是用 AWS Network Firewall 的話,包含了免費的 NAT Gateway 額度可以用...

印象中 Network ACLs 不用另外付費 (找了一下沒找到收費的標準?),如果可以用 Network ACLs 解決就用 Network ACLs,不能的再考慮用 AWS Network Firewall 吧...

CloudFront 新增泰國節點

看到 Amazon CloudFront 新增了泰國曼谷節點的消息:「Amazon CloudFront launches in Thailand」,原來泰國之前沒開啊...

Amazon CloudFront announces its first two edge locations in Thailand.

另外依照網路架構,先前泰國的流量應該是往新加坡或是香港跑 (我覺得新加坡可能比較像?),不過也不是那麼確定... 畢竟地理位置比較近的馬來西亞可以透過陸地就拉過去,不需要走海纜,只是不確定馬來西亞的點有沒有買 transit:

These new edge locations in Bangkok will provide viewers as much as a 30% reduction in p90 latency measures.

然後最近都至少是兩個點在開了,對服務穩定性比較好,維修的影響也比較小...

Starlink 北美北部封測

看到 Starlink 的北美北部的封測消息了:「I just officially received an email invite to the Starlink beta.」。

大家最在意的費用部份,設定費 USD$499,月費 USD$99:

It's called the Better Than Nothing Beta.

  • Estimated speeds 50Mbps to 150Mbps
  • Estimated latency 20ms to 40ms
  • Some interruptions in connectivity to be expected
  • $499 for the phased array antenna and router
  • $99 per month subscription

翻了一下 Reddit 上面的討論,目標族群跟之前猜測的差不多,這對於地廣人稀地區的使用者 (像是阿拉斯加的村落) 多了一個替代方案:「Starlink is 600x better than my current ISP BEFORE you consider data cap. My jaw dropped when I saw the official numbers.」。

I live in a rural village in Alaska and pay around $200/mo for service that is running fast if it hits 500kbps with a 40GB data cap.

Half the price for up to 300x faster service? Elon please start launching some polar orbits.

另外從「Mods, could we get a stickied post for confirmed beta invited states?」這邊可以看到目前主要都是北美北部的州拿到邀請,應該是商業策略...

OpenBGPD 接 AWS Direct Connect 時只讓單區路由的方法

算是繼上篇「用 pfSense 接 AWS Direct Connect (Public VIF) 的方式」的改善,上篇的方法設定完後預設會是全部都會 routing 進來。也就是說,如果你接到新加坡區,美東 routing 也會進來。

這可能是你要的,但也可能不是你要的,所以找了一下方法,在 AWS 的文件裡面有提到可以透過 BGP community 控制這些 routing:「Routing policies and BGP communities」。

第一個方向是從 pfSense 送出去的封包,這個要過濾從 BGP 送進來的 routing table:

AWS Direct Connect applies the following BGP communities to its advertised routes[.]

把:

allow from 1.2.3.4

改成:

allow from 1.2.3.4 community 7224:8100

另外一個是讓 AWS 不要把我們的 network 送到其他區,這是在 network 上加上 BGP community tag:

You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions.

把本來的:

network 1.2.3.4/30

變成:

network 1.2.3.4/30 set community 7224:9100

先這樣搞,用 mtr 看了一下應該沒錯...