SCTP over UDP

Red Hat 的 blog 上看到 SCTP over UDP 的方式,讓不支援 SCTP 的 NAT 裝置也能使用 SCTP:「An easier way to go: SCTP over UDP in the Linux kernel」。

這個方式也是個標準,在 RFC 6951:「UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication」。

Linux kernel 則是在 5.11 之後才支援,不過翻了一下 5.11 是一般版,在 2021 年二月釋出,在五月底就已經 EoL:

Stream Control Transmission Protocol over User Datagram Protocol (SCTP over UDP, also known as UDP encapsulation of SCTP) is a feature defined in RFC6951 and implemented in the Linux kernel space since 5.11.0.

上一個 LTS 版本是 5.10,下一個不知道是什麼時候了...

EC2 API 支援 IPv6,以及 Lightsail 支援 IPv6...

看到 AWS 丟出了兩個有點「有趣」的消息:「Amazon EC2 API now supports Internet Protocol Version 6 (IPv6)」、「Amazon Lightsail now supports IPv6」。

先是 EC2 的 API 支援 IPv6 的消息,但也不是全部都支援了 (亞洲區只有印度有支援,新加坡、日本、南韓與香港都沒在上面):

Usage of Amazon EC2’s new dual-stack endpoints are available at no additional charge. The new endpoints are generally available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Mumbai) and South America (São Paulo).

不過畢竟也不是直接面向使用者的部份,不算太意外就是了... 但另外聽到 Lightsail 支援 IPv6 的消息就比較意外了:

Amazon Lightsail now supports Internet Protocol version 6 (IPv6) on Lightsail resources like instances, containers, load balancers and CDN. With this launch, Lightsail resources operate in dual-stack mode, accepting both IPv4 and IPv6 client connections. This helps unlock application scenarios where some end user clients are IPv6 only.

本來以為 EC2CloudFront 有的東西在 Lightsail 上都會有,原來 IPv6 是沒支援的啊,這功能補的好晚...

Amazon (AWS) 手上有全世界 3% 的 IPv4 可用位置?

看到「Amazon owns more than $2B worth of IPV4 addresses」這篇提到,算了一下才發現 Amazon (AWS) 手上有超多 IPv4 位置...

As of today, December 11, 2020 AWS self reports owning 109,847,486 IPV4 addresses - at a price of $20 this is almost $2.2B and at $30 it’s almost $3.3B.

這邊要算可用的 IPv4 位置不能直接拿 2^32 算,需要扣掉特殊用途的...

最大的兩組是 Multicast 與保留不用的部份,分別是 224.0.0.0/4240.0.0.0/4,這邊有 32 個 Class A 的空間,再扣掉 0.0.0.0/810.0.0.0/8127.0.0.0/8 這三個 Class A 的空間,然後其他零星小的算一算再全部抓起來扣一扣,Amazon (AWS) 手上掛了將近全世界 3% 的 IPv4 可用位置,相當驚人...

Google 的好像沒有完整的,只有 Google 自家服務的,沒有包括 GCP...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

升級跳板機

算是做個記錄...

差不多是 2014 年的時候,因為 xDSL 網路的頻寬拉起來比較夠用了,加上當時發生一些事情,而且 HiNetPPPoE 可以申請發一個固定 IP (即「非固固 IP」),所以就用這個功能架了一台小的 server,這樣一來就有一台小的 server 可以用,另外很多 firewall 之類的操作就方便很多。

當時買的機子是 GigabyteGB-XM12-3227Intel i3-3227 + 4GB RAM + 128GB mSATA SSD:

幾年前 CPU 風扇掛過一次,去淘寶上挖了一顆回來後又可以繼續用。

不過後來在上面跑的東西愈來愈多,加上現在的軟體開發愈來愈吃各種資源 (就算只是 command line 環境),i3-3227 的 CPU Benchmarks 跑分也才 1274,記憶體也只裝了 4GB,跑起來還是愈來愈吃力... 大概在年初的時候就有打算要換,直到看到了這個機殼的影片:

我買了一個機殼回來 (還找到 $350 含運的店家),在客廳裝了一台 Intel J1900 + 8GB RAM 的機器接電視用 (不過這又是另外一個故事了),對這款機殼還算滿意,就再去下了一顆回來...

接下來就是湊其他的零件了,既然這次要拿來當半個開發機用,上面的等級要好一點,但又不希望太吃電 (畢竟是一直開著的機器),所以就找了一顆二手的 Intel i3-8100T (35W,CPU Benchmarks 分數 5319),然後在 PChome 24h 上面找了張 H310 的主機板,一個全新的 350W 電源供應器,以及 2*16GB RAM + 500GB SATA SSD。風扇的話是之前 Intel E3-1230 v3 留下來的風扇 (現在上面是掛水冷),扣具的位置是相同的 (LGA115x),就直接拿來用了。

弄好後裝個 Ubuntu 20.04,然後在只有兩顆風扇的環境下 (電源供應器的風扇與 CPU 風扇),CPU idle 只有 35 度上下,壓測也只有 55 度上下,本來還在糾結後方要不要還是裝個 8cm 系統風扇,後來決定還是放一顆上去好了,用負壓的方式把熱帶出來。

如果之後真的遇到灰塵太多的問題,再考慮用先前在「無風扇系統的 CPU 散熱片」提到的方案來換:

接下來就是搭車把機器帶老家裝,就順便被老人家餵食:

回家升級跳板機,然後就被餵食了...

換完後當然如同預期的速度快不少,接下來應該會考慮把線路升級到 300M/100M (現在只有 100M/40M),不過看起來 IP 一定會變,就比較麻煩了,之後再看看機會...

用 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 應該會好不少。