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

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

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

抓出正在使用的 DNS Server

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

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

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

Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息：「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係，找了一下果然發現之前有些計畫在跑：「AWS X-Ray SDK w/ OpenTelemetry API」，不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線，本來在推的 OpenCensus 與 OpenTracing 從網站上可以看到決定會再支援兩年，但重心會改放到 OpenTelemetry 上：

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息，先前有一些稿子是會往 OpenTelemetry 支援，但這一波沒看到新聞稿...

用 Amazon SNS 送簡訊可以固定發送號碼了

Amazon SNS 的簡訊功能可以申請固定發送號碼了：「Amazon SNS now supports selecting the origination number when sending SMS messages」。

固定的號碼包括了短碼與長碼：「Requesting dedicated short codes for SMS messaging with Amazon SNS」、「Requesting dedicated long codes for SMS messaging with Amazon SNS」。

短碼是三到七碼，依照地區而有差異：

A short code typically contains between three and seven digits, depending on the country or region that it's based in.

要注意的是短碼的部份需要開 support case 申請，而不是直接在 web console 上操作：

Open a case with AWS Support by completing the following steps.

長碼則是有可能到 12 碼，依照不同地區的設計有所不同：

A long code (also referred to as a long virtual number, or LVN) is a standard phone number that contains up to 12 digits, depending on the country that it's based in.

不過現在長碼的部份只有美國可以用，而且有速率限制：

Support for long codes is restricted to the United States only. Sending rates for long codes are restricted to 1 message per second. This restriction is set by the telecom carriers, and isn't a limitation of Amazon SNS. If you send a large volume of messages from a long code, wireless carriers might begin to block your messages. Your applications that use Amazon SNS should limit the number of messages that they send each second.

說道 Amazon SNS 送簡訊的費用，實在不怎麼好看，量小加減用 (包在 AWS 費用裡，省人力另外跑請款的單子)，量大還是要找其他家接比較划算...

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息，Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份，這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因，是因為 DebConf20 需要一個非封閉式平台的直播架構，而 PeerTube 看起來很適合這個情境：

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題，這個算是其中的一個方向，試著在解決平台壟斷的問題...

四個 HDMI 的顯示卡

在 Facebook 上正妹 wens 問是不是用華碩的 GT710-4H-SL-2GD5 這張顯示卡：「The Most Innovative ~$50 Graphics Card For Linux Users」，看了一下是一張蠻有趣的顯示卡，而且價位還蠻有競爭力的，拉一篇出來記錄好了...

我自己是用四螢幕，先前一直都是用 1080 Ti 在接 (2 HDMI + 2 DP)，但覺得好像太吃電，後來在網路上弄了一張有四個 miniDP 輸出的 Quadro P600 顯示卡，另外又找了四條 miniDP 轉 DP 的線。

換上去後發現有時候不是那麼順，後來發現是因為常常開一堆 Twitch 反而吃了不少 GPU 資源 (在 Linux 下可以用 nvidia-smi 觀察)，而且有時候還是希望跑個 KataGo 分析圍棋棋局，所以還是需要 GPU 計算能力，就換回用 1080 Ti 了...

不過這張 GT710 是四個 HDMI，用一般的 HDMI 線就可以了，相較於 P600 提供的 miniDP 需要 miniDP 轉 DP 的線，取得上應該容易不少：

另外他只需要 PCI Express 2.0 (x1) 而且是被動散熱，手上的 P600 得用到 PCI Express 3.0 (x16) 而且上面還是有一顆風扇，我猜 GT710 這張應該是更省電？不過官網上沒寫 GT710 這張的功耗，不過在「GeForce 700 series」這邊是寫 19W，而 P600 的最大功耗是 40W。

目前有看到的缺點應該是多顆 4K 解析度下時的更新頻率只有 30Hz：

* Detailed digital max. resolution:
3840×2160@60Hz for 1 monitor
3840×2160@30Hz for more than 2 monitors

對於想要有多螢幕輸出的人可以考慮看看，目前查到的價位上在新台幣 2000 上下，比 Quadro 便宜不少，畢竟定位還是不太一樣...

PayPal 也要提供加密貨幣服務

先是看到「PayPal to allow cryptocurrency buying, selling and shopping on its network」這篇，另外翻到了 PayPal 的新聞稿：「PayPal Launches New Service Enabling Users to Buy, Hold and Sell Cryptocurrency」。

幾個比較重要的地方是，這次會提供的是 Bitcoin、Ethereum、Bitcoin Cash 以及 Litecoin 這四種：

To increase consumer understanding and adoption of cryptocurrency, the company is introducing the ability to buy, hold and sell select cryptocurrencies, initially featuring Bitcoin, Ethereum, Bitcoin Cash and Litecoin, directly within the PayPal digital wallet.

會先提供美國 PayPal 的使用者使用，然後再展到其他服務以及地區：

The service will be available to PayPal accountholders in the U.S. in the coming weeks. The company plans to expand the features to Venmo and select international markets in the first half of 2021.

另外這次的服務也不是自己跳進去搞，而是透過 Paxos Trust Company 建立起防火牆，所以當加密貨幣那邊出包的時候大概就會切割出來：

The service is enabled in the U.S. through a partnership with Paxos Trust Company, a regulated provider of cryptocurrency products and services.

比較像是個嘗試，只是這個主題很適合發新聞稿...

Amazon SNS 也支援 FIFO 模式了

看到 Amazon SNS 也支援 FIFO 模式了：「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。

Amazon SQS 在 2016 年就已經先支援了：「Amazon SQS 支援 FIFO 了」，官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。

在使用 FIFO mode 時與 SQS 有一樣的速度限制，每個 topic 只能到 300 TPS：

You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.

不過之前有需要保持順序的應用應該都先用 SQS workaround 了，不然就是自己搞能夠 FIFO 的 pub/sub 架構了。

有風聲說司法部會把 Chrome 拆出 Google

看到這則新聞時決定讓子彈飛了一陣子，但好像沒看到什麼新消息：「Feds may target Google’s Chrome browser for breakup」，Hacker News 上也有討論可以翻翻：「Feds may target Google's Chrome browser for breakup (politico.com)」。

Google 在 Chrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情)，會直接先把 Google Chrome 拆出來的消息不算太意外。

不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章，Google 很多服務都有其他平台可以提供，或是 open source 軟體可以使用，但每次一講到 YouTube 時大家都很頭痛，都會提到 YouTube 的難以取代性，因為目前其他平台沒有一個是堪用的...

不知道什麼時候會發動調查...