用 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 去處理。

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

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

抓出正在使用的 DNS Server

Hacker News 上看到的方式:「Which DNS」,另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP,像 HiNet168.95.1.1 這種 DNS server 後面都有一堆 resolver,這個方式可以知道出去的 IP 是哪個,可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務,不過查了一下沒找到之前有印象的那個,反倒是查到另外一組可以用的:「Introducing a New whoami Tool for DNS Resolver Information」。

Cloudflare 推出了 BYOIP 的服務

Cloudflare 推出了 BYOIP 的服務,用客戶的 IP address 放 routing 出去:「Bringing Your Own IPs to Cloudflare (BYOIP)」。

照敘述上看起來應該是 anycast,不過這邊沒明講:

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing.

裡面沒有提到 IPv4 或是 IPv6,在 https://developers.cloudflare.com/byoip/ 這邊看起來也沒提到,以 Cloudflare 的技術架構,應該是都支援?

用自己的 IP 的好處,一個明顯的方向就是 firewall 會好設不少,另外如果需要服務中國或是其他管制地區,比較不會因為 IP space 混用誤殺受到影響?

用 Raspberry Pi 4 與 HDMI-to-USB 組出 KVM over IP 裝置

一樣是在 Hacker News Daily 上看到的專案,弄出便宜的 KVM over IP 裝置:「TinyPilot: Build a KVM Over IP for Under $100」。

主要是他在 Twitter 看到了這則,裡面提到了「Video Capture Cards, HDMI to USB 2.0, High Definition 1080p 30fps, Video Record via DSLR,Camcorder, Action Cam for Live Broadcasting, Live Streaming, Gaming, Teaching, Video Conference」這個產品:

而作者在 eBay 上面也找到了一樣的裝置,但是更便宜 (所以是「親,$11 包郵」?XDDD):

接下來是在接觸 pikvm 的時候發現了 µStreamer 這個專案:

µStreamer is a lightweight and very quick server to stream MJPG video from any V4L2 device to the net.

最後則是發現他使用的 HDMI-to-USB 裝置直接就是輸出 MJPG 格式,連 transcoding 都不用做了,大幅把 latency 降到 200ms:

其實從作者的文章可以知道,你想做的事情說不定在地球上已經有其他人做差不多了,重點是要找出來,而不需要自己硬幹 XD

前陣子爆出「不保留記錄的 VPN」保留了大量的客戶與連線資訊

前陣子 comparitech 發現了宣稱不保留記錄的 VPN 廠商 UFO VPNElasticsearch 伺服器沒有設定好,造成外部可以直接存取,然後發現裡面包含了大量記錄:「“Zero logs” VPN exposes millions of logs including user passwords, claims data is anonymous」,這篇文章的小標把重點先說完了:

UFO VPN exposed millions of log files about users of its service, including their account passwords and IP addresses, despite claiming that it keeps no logs.

目前還是建議在有能力的情況下都自己架,一般常見就是用 OpenVPN,但設定上會比較麻煩一些。如果要方便的話可以用 Openconnect VPN Server (ocserv) 架 server,然後在手機上可以直接用 Cisco 官方提供的用戶端接,像是 Cisco AnyConnect (iOS) 與 AnyConnect (Android),在桌機上一般則是用 OpenConnect 自家的軟體連接。

家裡有 HiNet 的網路的話,可以申請一個固定 IP (透過 PPPoE 的),然後用一台 Raspberry Pi 之類的設備架設。

倒不是說這些 VPN 廠商的服務不能用,只是你必須認知這些 VPN 是拿來繞過地區限制的,而不是為了安全性或是隱私,所以如果是人在外面使用網路,想要避免被商家或是外面的 ISP 看到流量內容,透過自己架設的 VPN 應該會好不少。

雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

架設 MTProxy 加快 Telegram 的速度

在台灣如果是透過 HiNetTelegram 是沒什麼問題 (不需要翻牆),不過連結的 preview 以及圖片影片讀取的速度實在很慢,試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看,發現速度都改善很多...

這邊用的是官方提供的 MTProxy,我把安裝的懶人包放在自己的 wiki 上了:「MTProxy」,在 AWS 或是 GCP 上安裝時,因為網卡拿到的是 Private IP 而非對外的 Public IP,需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。

跑一陣子再來看看有什麼可以調整的...

關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...

RIPE 的 IPv4 位置發完了

RIPE 在上個禮拜宣佈 IPv4 address 發完了:「[ripe-list] The RIPE NCC has run out of IPv4 Addresses」。

但這不代表不能申請,只是會進到「IPv4 Waiting List」這個列表裡面等待,各種原因取回的會發個這些申請者。

在台灣應該還是沒什麼感覺,因為固網 ISP 手上其實都拿一堆 IP 屯著,讓動態 IP 的架構輪著用,而行動網路上也可以看到不少 ISP 使用 Carrier-grade NAT 之類的架構在跑,最差也還可以拿 Private IP 硬上,暫時也不是太缺...

IPv6 的部份的確有愈來愈好,但還是常常可以看到 IPv4 的 routing 比較好,IPv6 有時候會繞到歐美再回亞洲...

話說起來,應該做看看 IPv6 上的 SmokePing 了,這樣才能比較 IPv4 與 IPv6 的 routing...