幹壞事是進步最大的原動力
找資料才發現 RFC 7526 廢掉 6to4 了：「Deprecating the Anycast Prefix for 6to4 Relay Routers」。
看起來像是無法解決的技術問題：
While this makes the forward path more controlled, it does not guarantee a functional reverse path.
去程的部份比較沒問題，但回程的部份就不一定會動。
不過目前看起來 HE 的 192.88.99.1 還有在運作，真的用 6to4 連 IPv6 network 的人至少還有機會動，等之後 IPv6 更普及應該會慢慢退場...
在「目前 AWS 台北區只能開 *.2xlarge 的機器」這邊把機器開起來了，所以先測一下 AWS 台北區對台灣各家的 ISP 的網路狀況。
先看台灣內的點，看起來都有 peering，用 IP 測可以看到 latency 都很低：
再來試看海外 internet 的部份，美國蠻多點是從東京 AWS 過去，但測了香港的部份 www.three.com.hk，是從 TPIX 換出去，看起來台灣這邊也有一些出口，peering 與 transit 目前沒看到大問題。
但幾乎所有透過 GeoDNS-based 的查詢都會被丟到東京：
走 anycast 的 Cloudflare 就好不少，像是付費版本的 www.plurk.com 就是台北的 PoP，而免費版本的 wiki.gslin.org 也會丟到亞洲的某個點上？(看不出來是不是東京，出現 jtha 這個有點像是日本，但也有可能是泰國的點？)
這應該主要還是因為這段 IP 目前還是被認到東京的 ap-northeast-1 上，得等各家調整才有機會放到台灣的 PoP 上，不然就是要故意用沒有 EDNS Client Subnet 的 DNS resolver 了。
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::/96prefix 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 上的方法...
先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到，因為 Google Workspace 要廢掉免費版本，所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用，所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號，然後用 Cloudflare 把信件 forward 到新的帳號裡。
但如果想要避開 Google 的服務的話，在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案，主要是付費的為主。
討論裡常被提起的方案：
我自己是很愛 Fastmail，他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上)，而且鍵盤快速鍵與 Gmail 幾乎相同，所以學習成本很低，就把其中一個 domain 掛上去用，然後把一些服務的註冊 email 都往這邊掛。
而費用的部份，除了可以月繳外，年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y)，第一次用一年後，後面就是刷三年了...
如果有在用 Office 的話，Microsoft 365 應該也是個選擇方案，不過我對 Outlook 的 folder-based 的設計邏輯用不慣...
然後是 iCloud+，看討論裡面提到穩定度似乎不太行，但也有人用的好好的，我自己是只有拿來同步 Apple 裝置用，沒有用到郵件服務的部份...
另外是自己有架設 Email service，話說這年頭自己搞 Email system 超麻煩的，對於沒搞過的人 SPF 與 DKIM 加上 DMARC 絕對會搞死自己，乖乖丟雲端服務比較省事，我純粹是要保持多路暢通而已...
Cloudflare 宣佈 Email Routing 這個 beta 功能可以讓一般人用 (包括免費帳號)：「Email Routing is now in open beta, available to everyone」。
當然，你要先有心裡準備 Cloudflare 會看得到信件裡面的內容，之後可能會幹些有的沒的事情...
這次會把這個功能開放出來，可以看到主要是 G Suite legacy 宣佈要收費的關係：
Most recently, with users wanting to set up Email Routing for more of their domains and with some of G Suite legacy users looking for an alternative to starting a subscription, we have been onboarding tens of thousands of new zones every day into the closed beta.
透過這個功能，至少收信的部份可以透過 Custom addresses 這個功能轉到個人版的 Gmail 或是其他的 email system 上，另外也可以透過 Catch-all address 的功能直接收所有信件，以免費的系統來說，看起來還行，而發信的部份就透過自己本來的 email system 來發，這樣 Cloudflare 看起來也不需要處理 spam 之類的問題。
看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息，VPC 可以把整個網段配到某台 EC2 Instance 上了。
之前也有其他方法可以做到類似的事情：
目前就是用這個方法搞定 VPN server 的：我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address，而且可以被 VPC 內直接存取，而不要被 NAT 掉。
好像該開張票轉移過去...
在 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
最後重開機確認後就通了...
AWS 大阪區開放給大家使用了，而且有標準的三個 AZ 可以用：「AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services」。
大阪區因為之前就已經有機房 (附加在東京區)，所以對應的 routing 看起來不算太差，但也沒有特別好... 剛剛測了一下從 HiNet 光世代過去的 latency，分別是 35.5ms (東京的 ap-northeast-1) 與 34.6ms (大阪的 ap-northeast-3)。
另外測了其他的 ISP，有些上日本的點是以東京為主，反而會多繞了一圈，大阪區的 latency 會比較高。
不過如果放遠來說，東京大阪的直線距離大約是 400km，光纖的傳輸速度大約是光速的 2/3，所以單趟大約差了 2ms，如果有機會最佳化的話應該有機會擠出 4ms 出來？
然後是 EC2 的 Pricing 頁面，上面還是寫 Asia Pacific (Osaka-Local)，無法確定是新資料還是舊資料，但以往的慣例應該是更新了...
對照文章裡有提到支援的機器，目前看起來還沒有很齊，像是目前都還沒有 AMD 與 ARM 架構的機器，另外也沒有 GPU 類型的機器：
The Asia Pacific (Osaka) Region supports the C5, C5d, D2, I3, I3en, M5, M5d, R5d, and T3 instance types, in On-Demand, Spot, and Reserved Instance form. X1 and X1e instances are available in a single AZ.
就支援的類型隨意挑了幾個 instance type 比較，翻了一下價錢看起來跟東京的一樣。
整體看起來，如果是有考慮到異地的需求是可以考慮，另外如果是新的服務的話也可以考慮看看 (畢竟各 ISP 應該有機會再把 latency 壓出來)，但既有的服務應該不需要急著搬...
算是繼上篇「用 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 看了一下應該沒錯...
公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡，ap-southeast-1)，但發現偶而會很不順，傳輸的時候會很卡，所以後來決定租了一條專線用 AWS Direct Connect 接進去。
不過因為跑在 AWS 上面的服務是掛在 public network 上，而不是 private ip 的網段，所以就不能用 IPsec site-to-site 打通收工，而需要搞 BGP routing，然後就卡關卡的亂七八糟 XD
首先是文書作業的部份，因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權)，這部份在 web console 上建立完 Public VIF 後會進入審核階段，接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定，我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。
這邊比較有趣的是，如果你沒有買 support plan 的話無法開 technical support，但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別：「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。
過了審核後接下來是設定 pfSense 的部份，因為是要接通 public network 的部份，所以你要收 AWS 提供的 BGP routing，這部份在 pfSense 上會透過 OpenBGPD 解決，但主要還是因為對 BGP 不熟悉，所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題，不然現在事後來看，自己 tcpdump 應該就有能力找到問題了...
主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。
這是一個 TCP extension，連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改：「Protection of BGP Sessions via the TCP MD5 Signature Option」。
要注意的是這個協定不是 application level，而是在 TCP 層本身就保護起來，包括 3-way handshake 的部份，所以從一開始 SYN 封包過去就要有 md5sig 的資訊。
這也表示用 telnet 不會通是正常的，這點讓我找問題找錯方向好久...
另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD)，這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到：
Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.
That module is required for TCP_SIGNATURE to function.
If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.
到了對應的選項那邊要選擇，因為我們的 pfSense 機器比較低階，沒有那堆硬體加速度的東西，所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。
設定完後新的連線也還是不會有效果，後來想了一下還是整台重開機，然後就通了就通了就通了就通了就通了...
果然弄很久的問題都會是蠢問題，純粹就是不熟悉這些東西造成的。