gateway

Route 53 支援 DNS64，以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制，讓 IPv6-only 的機器可以連到 IPv4-only 的服務：「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64，針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變)，這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範：

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上：

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊，所以不能保證 NAT64 一定會動，但大多數的情況應該是可以解決，至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

看起來這個月 HiNet 連外大概會不怎麼順...

在 Twitter 上看到這則障礙資料：

因 APG 海纜障礙影響 HiNet 客戶連線美國、中國及香港部份網站之連線品質
🕓 2021-10-30~2021-11-30, 2021-10-30 10:00AM

2021 年 10 月 30 日發生 APG 海纜障礙，客戶連線美國、中國及香港部份網站可能造成部分連線有少許延遲現象。https://t.co/bBapFA47He

— HiNet 網站公告 (@HiNetNotify) October 30, 2021

APG (Asia Pacific Gateway) 在 2016 年啟用，還算是新的海纜，看起來會有不少頻寬受到影響... 這點在 HiNet 上用 SmokePing 監控對 dynamodb.ap-southeast-1.amazonaws.com 的 packet loss 就很明顯的可以看出來了：

連過去封包掉的亂七八糟的，然後公司做東南亞生意，操作起來苦哈哈... 不過其他 ISP 看起來還行，應該有機會先繞過去。

Ubuntu 環境 PPPoE 遇到拿的到 IPv6 address 但是卻不通的問題

在 Ubuntu 的環境裡透過 PPPoE 上拿 IPv6 address 不是什麼大問題，搜一下大概都可以找到，在 /etc/ppp/options 的最後面加上這串就可以了 (或是在 /etc/ppp/peers/ 裡面的檔案對特定的設定加)：

+ipv6 ipv6cp-use-ipaddr

不過我遇到的問題是，ppp0 雖然拿到了 IPv6 address (從 ip addr 或是 ifconfig 可以看到)，但 mtr -6 www.google.com 確不通。

找問題時發現 netstat -6rn 有兩筆 IPv6 default gateway，刪掉 enp3s0 的那筆馬上就通了，所以是跟 routing 有關的問題，在本地端收到了 default routing，優先權還比 ppp0 拿到的還高。

因為這台主機是跑 Netplan，所以就用 Netplan 的方式強制關掉本地端的 Router Advertisement (RA)：

network:
    version: 2
    renderer: networkd
    ethernets:
        enp3s0:
            accept-ra: false

最後重開機確認後就通了...

Amazon API Gateway 又在搞奇怪的東西了...

Amazon API Gateway 宣佈一個新的產品，提供 HTTP APIs 管理 RESTful APIs (???)：「Amazon API Gateway Offers Faster, Cheaper, Simpler APIs Using HTTP APIs (Preview)」。

官方是這樣描述 HTTP APIs 的：

Use HTTP APIs to build high performance RESTful APIs that require API proxy functionality without API management features. HTTP APIs are optimized for serverless applications and HTTP backends, and offer up to 70% cost savings compared to REST APIs.

你已經有了 RESTful APIs，然後跑去接個沒有 API management features 的 API Gateway...？

然後翻了一下之前 API Gateway 的豐功偉業，本來打了一大堆，但還是留點口德好了... 看起來 API Gateway 團隊裡老大的後台很硬啊，搞成這樣都沒被幹掉？

話說回來，去年 ALB 宣佈支援 AWS Lambda，該不會是 API Gateway 實在太爛，所以 Serverless 的大方向逼 ALB 支援的啊？

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN)，不使用 AWS 自己提供的串接服務，而是用 pfSense 串接。

會自己搞主要有幾個考慮：

考慮到 AWS Transit Gateway 的費用，每掛一個上去就要多收一次錢，另外上面處理的流量要再收費。
應用的流量不大，所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity，算是夠用了。
而且應用在寫的時候也考慮到斷線後的處理，加上用戶端的網路本來就不怎麼穩定，AWS Transit Gateway 的 SLA 再怎麼高，我也還是得處理斷線時的後續機制，不如就不要那麼緊張...

在設定的時候要注意的事情：

EC2 的 Source IP/Destination IP 檢查要關掉，這算是基本盤。
VPC 內的 Routing 要確認過一輪。
EC2 上的 Security Group 對於 pfSense 的主機得全開，因為 pfSense 會丟出不屬於他自己 IP address 的封包，也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing)，這些都還是會經過 Security Group 的檢查，而 Security Group 能設定的數量有限，基本上應該會全開...
pfSense 在設完 IPsec 後，同樣在 pfSense 上面的 firewall 需要手動加開，因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法，只是老方法還是很好用...

Cloudflare 提供 IPFS 的 HTTPS Gateway

IPFS Gateway 基本上就是個 Proxy，這次 Cloudflare 直接提供 *.cf-ipfs.com 服務：「Continuing to Improve our IPFS Gateway」。

用把 hash 放進 subdomain 的方式讓我想起當年的 Coral CDN 計畫...

Anyway，我覺得對 IPFS 的幫助還是有限，畢竟本來 IPFS 官方就有提供 Gateway，現在只是一個比較快的 Gateway，能做的功能還是那些...

AWS Transit Gateway：不用再自己處理多個 AWS 帳號之間的 routing 了

AWS 推出 Transit Gateway，讓多個 AWS 帳號之間的 routing 問題總算不用自己處理了：「New – Use an AWS Transit Gateway to Simplify Your Network Architecture」。

這個問題常出現在組織架構大一點的情境下：為了讓各單位自己付自己單位的帳，所以大家都建立了自己的 AWS 帳號。但內部還是有互相連線的需求，雖然把 IP range 都有切開，但還是得搞定彼此之間的 routing...

之前 AWS 還做了「AWS Global Transit Network」這份說明，解釋要怎麼處理 routing，在說明裡官方當時還提供了不少在雲上面建立 router 的方案。像是其中一個方式是用 Cisco 的方案做：「AWS Solution – Transit VPC」、「Overview - Transit Network VPC (Cisco CSR)」。

而現在則是可以直接用 AWS 的服務解決了：

You can attach up to 5000 VPCs to each gateway and each attachment can handle up to 50 Gbits/second of bursty traffic. You can attach your AWS VPN connections to a Transit Gateway today, with Direct Connect planned for early 2019.

每個接點都要收租用費 (美國是 $0.05/hr，一個月大約 $36；日本是 $0.07/hr，一個月大約 $50.4)，另外流量要收 USD$0.02/GB，其實就是本來的 in + out 的費用 (在 EC2 同區的流量是要收 in + out 的費用的)。

Amazon API Gateway 推出分級收費 (降價)

Amazon API Gateway 推出分級收費：「Amazon API Gateway Announces Tiered Pricing」。

原先的費用不變，大多數的地區是超過 333M reqs/month 的部分降價了... (不過雪梨跟南非是超過 1B reqs/month，而且北卡超過 333M 的部分也只降個零頭，實際比較深的折扣還是在 1B)，333M reqs/month 這個量換算下來需要 11.1M reqs/day，平均值要 128 reqs/sec，看起來是設計給整個站都搬上去的折扣方案 (不然就是本身量就超大)。