6to4 在 2015 年就 deprecated 了...

找資料才發現 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 更普及應該會慢慢退場...

Google One 的使用者都有 VPN 服務可以用了...?

MacRumors 上面看到 Google 提供 VPN 服務給所有付費的 Google One 使用者使用:「All Paid Google One Subscribers Now Get VPN Access」。而 Google 的公告在這裡:「New security features for all Google One plans」。

主打隱私性,避免被追蹤 IP 位置之類的:

VPN by Google One adds more protection to your internet activity no matter what apps or browsers you use, shielding it from hackers or network operators by masking your IP address. Without a VPN, the sites and apps you visit could use your IP address to track your activity or determine your location.

看到這則留言,很貼切 XDDD

Google running a VPN is like McDonalds running an exercise gym.

不了謝謝 XDDD

透過 DNS 找自己 IP、查詢 ASN 資訊以及匯率

Hacker News 上看到「Bizarre and unusual uses of DNS (fosdem.org)」這篇,裡面把 DNS 的各種創意性的服務都整理出來了。原文在「Bizarre and Unusual Uses of DNS」,是今年 FOSDEM 的演講內容,PDF 投影片在「Bizarre and unusual uses of DNS」這邊。

裡面提到兩個服務可以抓自己的 IP address,第一組是 Google 的服務,像是這樣:

$ dig o-o.myaddr.l.google.com txt
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "114.34.121.114"

但可以抓到我真正的 IP 是因為我自己有架設 DNS resolver。如果一般用中華電信的 DNS resolver 168.95.192.1,會出現中華的 IP address 資訊:

$ dig o-o.myaddr.l.google.com txt @168.95.192.1
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 5      IN      TXT     "2001:b000:180:8001:0:1:10:143"

如果是用有支援 ECSGoogle Public DNS (像是 8.8.8.8),則是會帶出 ECS 資訊:

$ dig o-o.myaddr.l.google.com txt @8.8.8.8
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "172.217.43.204"
o-o.myaddr.l.google.com. 60     IN      TXT     "edns0-client-subnet 114.34.121.0/24"

這算是技術限制了。另外一方面,OpenDNS 提供的 myip.opendns.com 就沒那麼好用了。

第二個是 Team Cymru 提供的 DNS 服務,可以透過 DNS 查某些 IP 的 ASN 資訊,像是以中華電信 168.95.192.1 這個 IP 為例:

$ dig 1.192.95.168.origin.asn.cymru.com txt
;; ANSWER SECTION:
1.192.95.168.origin.asn.cymru.com. 14400 IN TXT "3462 | 168.95.0.0/16 | TW | apnic | 1997-04-09"

$ dig 1.192.95.168.peer.asn.cymru.com txt
;; ANSWER SECTION:
1.192.95.168.peer.asn.cymru.com. 14400 IN TXT   "1239 9680 | 168.95.0.0/16 | TW | apnic | 1997-04-09"

翻了一下,AS1239SprintAS9680 是中華在美國的 ASN。

第三個有趣的是匯率,沒有直接開 public domain 讓大家查,你需要把 DNS 指過去查:

$ dig 100USD-TWD.fx @dns.toys
;; ANSWER SECTION:
100USD-TWD.             3600    IN      TXT     "100.00 USD = 3066.41 TWD" "2023-02-26"

ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

AWS 台北區的網路狀況 (Routing & CDN 的情況)

在「目前 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 了。

Ubuntu 下面搞 Multi-home 架構

家裡的 internet 架構大概是這樣 (省略過其他裝置):

一邊是 HiNet 的線路直接接中華的數據機 (modem),這段是用 PPPoE 撥接;另一邊是第四台網路 (北都),另外上面寫的 Switch 應該是 IP 分享器 (一台 ASUS 的機子,刷 DD-WRT),作圖的時候寫錯了...

最後是電腦的部份,我的桌機是跑 Ubuntu,用兩張個不同的實體線路 (界面分別是中華的 enp4s0 與第四台的 enp6s0f0) 接到了這兩個不同的網段上面。

打算跑 source routing 的架構來善用兩邊的頻寬,想法上面大概是這樣拆解:

  1. 機器本身有個 192.168.3.x 的 static ip。
  2. 針對 source ip 是 192.168.3.x 的封包,預設會往 192.168.3.254 這台分享器丟,然後 NAT 出去。
  3. Squid 在本機上跑一個 proxy server,指定 source ip 是 192.168.3.x

有了這樣的架構,我就可以在瀏覽器上面就透過 SwitchyOmega 這類的套件,指定某些網段要走第四台的頻寬出去了。

另外可以指定 http proxy 的服務也可以透過這個方法往第四台的線路連出去。

其中第二點需要把 source ip 是 192.168.3.x 的封包丟到 192.168.3.254 這段需要一些設定,首先是需要設定一個獨立的 routing table,我是在 /etc/iproute2/rt_tables 裡面放:

2       second

然後因為我是透過 NetworkManager 在管理網路界面的,我希望在 enp6s0f0 啟動時自動設定這個 source routing 邏輯,所以我在 /etc/NetworkManager/dispatcher.d/99-enp6s0f0 這邊寫了:

#!/bin/bash

interface=$1
event=$2

if [[ "$interface" == "enp6s0f0" && "$event" == "up" ]]; then
    ip route add default via 192.168.3.254 table second
    ip rule add from 192.168.3.0/24 table second
fi

然後要記得把這個檔案 chmod 755 讓他可以執行。

接著是 Squid 的設定,在 /etc/squid/squid.conf 裡面這樣寫:

#
http_access allow all
#
access_log /var/log/squid/access.log squid
cache deny all
cache_dir null /tmp
cache_log /dev/null
cache_mem 8 MB
dns_v4_first on
forwarded_for off
http_port 3128
tcp_outgoing_address 192.168.3.x

其中最後的 192.168.3.x 換成自己的固定 IP address。這邊因為 traffic 基本上都是 HTTPS 了,也不需要開 cache,就這樣設定...

這邊比較特別的是 dns_v4_first 的設計,這個是讓 Squid 儘量用 IPv4 的位置連線。這是因為北都的網路沒有提供 IPv6 位置,所以如果網站的 DNS 如果有 IPv6 位置的話就會從 HiNet 這邊的 IPv6 出去了...

另外 ping 與 MTR 之類的工具不會動在這這樣的架構下是正常的,因為這些工具會自己組合 raw packet 丟,不是透過 Linux 的 network stack 處理,所以不會被我們指定的 ip rule 解析。網路上看起來是有方法可以 mitigate,但我就先放著了...

這樣看起來還算堪用,先這樣用一陣子看看... 先前是在 Raspberry Pi 上面跑個 proxy server 導流量,但會受限於 Raspberry Pi 的硬體限制,效能上面就普普通通,現在直接用桌機拼看看...

DOS 下的 TCP/IP 程式組

Hacker News 上看到「mTCP: TCP/IP applications for DOS PCs (brutman.com)」這個有趣的東西,在 DOS 環境下的 TCP/IP 程式組,原網站在「TCP/IP applications for your PC compatible retro-computers」這邊。

不過我覺得比較神奇的是,他的測試環境是真的包括一堆老機器跟網卡耶 XDDD

裡面提到的 NE1000ISA 界面的卡,這樣聽起來保養的都還不錯...

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用:「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面,這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了,只開放給 CloudFront 的伺服器存取:

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段,因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方,這個 prefix list 的權重很重,使用他會算 55 條 rule 的量,在 security group 內很容易撞到 60 條的限制,在 route table 裡面則是直接撞到 50 條的限制;不過這兩個限制都可以跟 AWS 申請調昇:

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

  • It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.
  • It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條,HTTPS 也一條,那就會算 110 rules 了,有暴力的感覺...

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊,Akamai 有提供工具,可以看 DNS resolver 的資訊:「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的,這些對外雖然有一個 IP address 在服務,但後面是一整個 cluster,所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個):

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

1.1.1.1 會給假的 ECS 資訊:

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...