Amazon VPC 允許直接把整個網段配到某台 EC2 Instance 上了

看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息,VPC 可以把整個網段配到某台 EC2 Instance 上了。

之前也有其他方法可以做到類似的事情:

  • 用 VPC 提供的 Routing Table 把網段指到某台 EC2 的機器上。
  • 把這台 EC2 機器的「Enable Source/Destination Check」關閉。

目前就是用這個方法搞定 VPN server 的:我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address,而且可以被 VPC 內直接存取,而不要被 NAT 掉。

好像該開張票轉移過去...

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

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

AWS 大阪區開放

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 出來?

然後是 EC2Pricing 頁面,上面還是寫 Asia Pacific (Osaka-Local),無法確定是新資料還是舊資料,但以往的慣例應該是更新了...

對照文章裡有提到支援的機器,目前看起來還沒有很齊,像是目前都還沒有 AMDARM 架構的機器,另外也沒有 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 壓出來),但既有的服務應該不需要急著搬...

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 看了一下應該沒錯...

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 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 去處理。

設定完後新的連線也還是不會有效果,後來想了一下還是整台重開機,然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題,純粹就是不熟悉這些東西造成的。

AWS 的 VPC 在 Routing 上的改善

在這次 re:Invent 發表會上,AWS 也宣佈了一些跟 VPC routing 有關的改善。

第一個是 AWS Transit Gateway 彼此可以互串了:「New for AWS Transit Gateway – Build Global Networks and Centralize Monitoring Using Network Manager」。

第二個是可以拿 EC2 的機器 (實際上應該是 ENI) 當作 routing 的目標:「New – VPC Ingress Routing – Simplifying Integration of Third-Party Appliances」。

不過我記得第二個好像早就可以了啊,這次不知道是簡化了什麼東西...

在 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 前的作法,只是老方法還是很好用...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing,也就只針對部份 IP range 走進 VPN,其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些,因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器),但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多,算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能:「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少,目前知道的單位大多也都還是自己架...

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 的費用的)。

AWS 的 BYOIP 服務開放一般使用了...

先前提到的「AWS 提供自帶 IP 到 AWS 上的服務了...」只能在 us-west-2 上使用 (需要申請),現在則是開放一般使用了:「Announcing the general availability of Bring Your Own IP for Amazon Virtual Private Cloud」。

而且範圍也增加了,除了本來測試的區域 us-west-2,現在 us-east-1us-east-2 都可以用:

This feature is now publicly available in US East (N. Virginia), US East (Ohio) and US West (Oregon) AWS Regions.

費用方面也都不需要額外費用:

There is no additional charge to use the BYOIP feature. Also, you don’t have to pay for Elastic IP addresses that you create from BYOIP address prefixes.

從文件上看起來目前只支援 IPv4,每段最少需要 /24,而且每個 region 最多五個 range,另外保留使用權 (如果 IP 網段之前有很多不良記錄時 AWS 可以拒絕)。