Apple 要求六月開始的 iOS 程式都必須能在 IPv6-only network 運作

Apple 對 iOS 程式的新政策:「Supporting IPv6-only Networks」。

也就是說,在 ISP 提供 NAT64 的環境下 client 想要連 210.61.183.31 時會連 IPv6 的位置 ::d23d:b71f,ISP 會幫忙 NAT 出去。而client 端的應用程式要能夠在這樣的網路環境下正常運作。

這測試環境沒建過,不知道會遇到什麼問題... @_@

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

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

AWS 推出 NAT Gateways

每次遇到 AWS 業務就會抱怨的功能總算推出來了,VPC NAT Gateways:「New – Managed NAT (Network Address Translation) Gateway for AWS」。

與自己用 EC2 架設的不同點在於處理的流量也要計費,但好處是以前得自己處理 HA,現在 AWS 幫你做掉這塊,不過 scalability 還是限制在 10Gbps:

The gateway has built-in redundancy for high availability. Each gateway that you create can handle up to 10 Gbps of bursty TCP, UDP, and ICMP traffic, and is managed by Amazon. You control the public IP address by assigning an Elastic IP Address when you create the gateway.

要注意的是流量計費這塊收費很貴 (非常貴),有大量連外需求的機器,還是用 public ip 直接連外會比較省,或是用老方法自己架設 NAT instances 處理。

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 的問題應該會更痛快?

建立 Amazon VPC 的 High Availability NAT 架構

Amazon VPC 的架構裡最讓人碎碎唸的一個架構:NAT instance。

Amazon VPC 分成 Public Network 與 Private Network。

前者的 Public Network,裡面的機器除了會有 Private IP 外,需要申請 Public IP (可以是隨機分配,也可以是 Elastic IP) 透過 Intenet Gateway (沒有 NAT 功能) 連外,這邊問題比較小,因為 Routing Table 設一下就好了,High Availability 以及 Scalablility 的問題 AWS 會自己解決掉。

後者 Private Network 因為需要自己架設 NAT instance,所以要自己處理 High Availability 以及 Scalability 問題,由於把機器丟在後面,前面用 ELB 是蠻常見的架構,AWS 一直沒推出 NAT service 讓人感覺很疑惑...

目前一般在處理 Private Network 的 HA NAT 架構是參考「High Availability for Amazon VPC NAT Instances: An Example」這篇文章,但這篇文章的作法有點複雜。

我可以接受有一些 downtime 時間以及一些小狀況,相對的,我想要換取極低的管理成本。

研究了一陣子,最後決定的作法是受到「An Alternative Approach to “HA” NAT on AWS」這篇的啟發,這篇也只講了很簡單的概念,實際上還是要自己研究。

目前是做在 us-west-2 (Oregon) 的 1b 與 1c 兩個 AZ 上。下面討論時就不說明這點了。

規劃的想法是 1b 與 1c 兩個 AZ 各建立一個 auto scaling group,透過 auto scaling 各跑一台 NAT instance 處理自己 AZ 的 NAT traffic (所以不是手動跑)。然後我不想要自己建 image 寫太多 hard code 進去,最好是現成的用一用就好 XD

所以有幾個重點:

  • NAT instance 拿現成的 amzn-ami-vpc-nat 使用,寫這篇文章時是用 2014.09 版。
  • 由於官方的 NAT instance 支援 userdata 在開機時執行指令,所以完全透過 userdata 指定需要的做動就好。
  • 由於 Amazon 官方給的 instance 有 aws 這隻工具 (aws-cli),而這隻工具在有掛上 IAM Role 時會去 http://169.254.169.254/ 上取得對應的 IAM Role 權限,所以都不需要寫太多 hard code 的東西進去。

機器開起來以後希望做幾件事情:

  • 把自己的 Source/Destination IP check 關閉。
  • 把傳進來的 Route Table 的 0.0.0.0/8 設成自己。這邊需要傳進來是由於 NAT instance 是跑在 Public Network 裡,我不會知道要改哪個 Route Table。

所以就有兩個重點,一個是 userdata,其中粗體是要修改的 route table id:

#!/bin/bash
ROUTE_TABLE_ID=rtb-1a2b3c4d
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 modify-instance-attribute \
    --region us-west-2 \
    --instance-id "${INSTANCE_ID}" \
    --no-source-dest-check
aws ec2 replace-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}" || \
aws ec2 create-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}"

最前面事先抓 instance_id,然後修改 Source/Destination 檢查,最後面的指令是先試著 ReplaceRoute,如果失敗就 CreateRoute (注意到 shell 的 || 操作)。

另外的重點是 IAM Role,這台機器對應的 IAM Role 權限要開三個:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:ModifyInstanceAttribute"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

拿 t2.medium 測試,burst 可以到 200Mbps 左右,應該還算夠用?反正不夠用就自己挑其他機器開吧 XD

最後討論一下 Availability 的情況。這樣的架構可能會有七八分鐘的 downtime,也就是當 instance 掛了,被 auto scaling 重新拉一台新的起來。這邊不做 cross-zone NAT 是因為這樣比較簡單,這邊的 downtime 我還可以接受。

至於某個 zone 掛掉,應該 cross-zone NAT 趕快導到另外一區的問題... 整個 zone 都滅了就沒有這個問題啊 XDDD

自動將流量轉到 Tor 上面的硬體

Zite 上看到「Tiny Anonabox to offer online anonymity through Tor」這篇文章。

Kickstarter 上可以看到更完整的資料:「anonabox : a Tor hardware router」。

可以想像出來大概是什麼技術組合起來。分別處理 DNS query 以及實際連線的部份應該就可以搞定很多應用了。

不知道隱私的部份可以做到什麼程度,畢竟在 Tor 上面仍然有監聽的風險,如果讓 HTTP traffic 在上面跑的話等於是裸奔...

Ubuntu 12.04 上用 KVM (CLI) 裝 FreeBSD

過年後在家裡弄了一台技嘉的準系統跑 Ubuntu 12.04,結果手上突然沒機器可以跑 porttools 測試,而這台機器平常也沒接鍵盤,就想直接跑 command line 的 KVMFreeBSD。其實知道方式後就很簡單,只是一開始沒弄懂花了不少時間...

首先是安裝 KVM,這部份用 apt-get install kvm 就可以拉下來裝好了。

真正要做的第一部是先用 qemu-img 建立 40GB 的 disk image (qcow2):

qemu-img create -f qcow2 ~/vm/image.qcow2 40G

然後直接用 iso image 安裝 (抓 iso image 的事情也跳過去請各位自己來),設為 4 CPU (-smp 4)、1024MB RAM (-m 1024),並且透過 serial console 安裝 (-nographic -curses),開機先從 cdrom 上開 (-boot d):

kvm -smp 4 -drive file=/abs/path/vm/image.qcow2,if=virtio -cdrom /abs/path/vm/FreeBSD-10.0-RELEASE-amd64-bootonly.iso -m 1024 -nographic -curses -net nic,model=e1000 -net tap -boot d

其中網路的部份卡了最久,後來發現預設值的 -net nic -net user 意思是:

  • -net nic 表示在 Guest OS 內建立一張網卡接到 KVM 的 vlan0。
  • -net user 表示在 KVM 的 vlan0 上建使用 userland mode NAT。

由於 userland mode NAT 很受限 (只有 TCP 與 UDP 會通),所以我用 -net nic -net tap 表示直接 bridge 到 virbr0 上再 NAT 出去。而我希望對 Guest OS 使用 e1000,所以最後就變成 -net nic,e1000 -net tap

接下來安裝 FreeBSD 時就可以用 DHCP mode 抓到 IP 了,由於我希望可以從 Host 直接連進去,所以我是設成 static IP。

裝完後就不需要掛 cdrom 與優先從 cdrom 開始開:

kvm -smp 4 -drive file=/abs/path/vm/image.qcow2,if=virtio -m 1024 -nographic -curses -net nic,model=e1000 -net tap

先前用 -hda /abs/path/vm/image.qcow2 掛上去,結果 i/o 很慢,被 delphij 提醒後改跑 virtio,速度就正常多了。不過這是因為 FreeBSD 10 就內建支援 virtio 了,如果是使用 FreeBSD 9 的需要另外再透過 ports 裝進去。

記錄下來給需要的人玩看看,下次也許應該玩玩看 VNC display?

用 pfSense 架設 Firewall (以及 NAT)

pfSense 是一套很不錯的 firewall 以及 NAT 服務,上面還可以跑一切服務 (像是 OpenVPN 或是 Squid),不過後來都是用商用的硬體方案來處理...

看到「Build your own pro-grade firewall」這篇突然想到要查 pfSense 是否可以 High Availability,如果做的夠好的話,其實可以用兩台機器來跑,成本相對低很多。

結果查到這篇官方文件「Configuring pfSense Hardware Redundancy (CARP)」,裡面有幾個關鍵字,像是 XMLRPC Sync 似乎暗示了設定也可以同步?


官方文件裡的配置圖。

該測試看看了,兩台 server 也才十萬,但兩台能跑到 500Mbps+ 的硬體防火牆的價錢就貴多了... (不過比較省電?)

BT Retail 開始實際測試 CGNAT...

英國的 ISP BT Retail 開始測試 CGNAT (Carrier-grade NAT) 了:「BT Begins Customer Tests of Carrier Grade NAT」。

空前但未必是絕後的大型 NAT 計畫,如果 CGNAT 可行,IPv6 會再往後延個好幾年吧...

Update:被 comment 提醒跑去測試,發現中華的 3G 早就是了:(CGNAT 會用 100.64.0.0/10,範圍到 100.127.255.255)

ISP 架設 NAT 解決 IPv4 不夠的問題...

Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題:「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做),但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司,也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留,拿來給營運 CGNAT 的 ISP 使用:

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換;如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情):

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞,那麼很多應用就很苦了 (得靠 UDP hole punching 打洞,這還得在沒有 randomized NAT port 的情況下才打的通),不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式?IPv6 遙遙無期... XD