Home » Posts tagged "ip"

Vultr 推出 $3.5/m 的方案

Twitter 上看到 Vultr 推出了 USD$3.5/month 的方案:

這規格與價錢明顯就是對 Amazon Lightsail 的新方案反應...

最早的時候 Vultr 提供了 USD$2.5/month 的類似方案,但後來限制到只有紐約與邁阿密有,最近則是限制到只有 IPv6 address 沒有 IPv4 address (會需要靠 Cloudflare 這類服務幫忙 proxy),而且限制只能開兩台。

這次推出的方案跟 USD$2.5/month 的規格一樣,不過是有 IPv4 address,所以多了 USD$1/month。

AWS 提供自帶 IP 到 AWS 上的服務了...

AWS 宣佈提供自帶 IP 到 AWS 上的服務了:「Announcing Bring Your Own IP for Amazon Virtual Private Cloud (Preview)」。

目前只在 us-west-2 有,另外需要申請:

Bring Your Own IP is available for preview in the US West (Oregon) region. You can request access to this feature by completing this request form.

不知道是不是直接放 routing 出來?如果是的話,照慣例 IPv4 應該是至少要 /24?從申請表格上看起來像是這樣沒錯:

IPv4 Prefix you want to onboard. You need a minimum of /24 ARIN registered prefix. The Net Type should either be Allocated or Assigned:

DNS over TLS 的 Privacy 改善

在上一篇提到 DNS over TLS 的「用 Stubby 在 Ubuntu 上跑 DNS over TLS」這篇,裡面 Gholk 留言提到:

可是 isp 還是可以從你接下來要去的 ip 知道你查了什麼吧?除非是 http proxy 多個域名一個 ip.

在「Does SNI represent a privacy concern for my website visitors?」這邊提到了 SNI 對隱私的問題,但他的想法剛好跟這個主題有關。

現代的瀏覽器架構使得使用者要在網路上保護自己很難 (這邊指的是隱私),但我們還是會利用各種方式加高 ISP 的難度,而這邊通常指的是成本:在 168.95.1.1168.95.192.1 上面記錄並且分析的成本,會比在所有的出口或是骨幹上面截聽封包的成本來的低很多,所以會走 DNS over TLS。

Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本,讓使用者可以在不暴露自己的 IP address 的情況下,使用 Cloudflare 提供的 DNS Resolver 服務:「Introducing DNS Resolver for Tor」。

不過沒看懂,如果使用者想要透過 Tor 保護自己的話,本來就可以透過 Tor 存取 1.1.1.11.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了?(像是 Google8.8.8.8)

好像找不到什麼使用的理由...

Cloudflare 推出 Spectrum:65535 個 TCP Port 都可以轉的 Proxy...

Cloudflare 推出了 Spectrum,文章標題提到的 65533 應該是指 80 & 443 以外其他的 port:「Introducing Spectrum: Extending Cloudflare To 65,533 More Ports」。

然後因為 TCP proxy 不像 HTTP proxy 與 WebSocket proxy 可以靠 Host header 資訊判斷,在 TCP proxy 需要獨占 IP address 使用 (i.e. 一個 IP address 只能給一個客戶用),而因為 IPv4 address 不夠的關係,這個功能只開放給 Enterprise 客戶用:

Today we are introducing Spectrum, which brings Cloudflare’s security and acceleration to the whole spectrum of TCP ports and protocols for our Enterprise customers.

雖然現在限定在 Enterprise 客戶,但 Cloudflare 還是希望看看有沒有其他想法,目前提出來的選項包括了開放 IPv6 address 給所有人用,或是變成獨立付費項目:

Why just Enterprise? While HTTP can use the Host header to identify services, TCP relies on each service having a unique IP address in order to identify it. Since IPv4 addresses are endangered, it’s quite expensive for us to delegate an IP per application and we needed to limit use. We’re actively thinking about ways to bring Spectrum to everyone. One idea is to offer IPv6-only Spectrum to non-Enterprise customers. Another idea is let anyone use Spectrum but pay for the IPv4 address. We’re not sure yet, but if you prefer one to the other, feel free to comment and let us know.

類似的產品應該是 clean pipe 類的服務,但一般 clean pipe 是透過 routing 重導清洗流量,而非像 Cloudflare 這樣設計... 不知道後續會有什麼樣的變化。

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務:「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」,主打項目是隱私以及效能。

然後因為這個 IP 的特殊性,上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去):

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNSOpenDNS 比較),可以看到平均速度快不少:

在台灣的話,HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency:

可以比較同一台機器對 168.95.1.1 的反應速度:

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種,不透過 PPPoE,直接設定 IP address 使用 bridge mode 連線的使用者),兩者的 latency 就差不多,不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/,理論上不會發 IP-based 的 SSL certificate 才對?不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update:查了資料發現是可以發的,只是大多數的 CA 沒有提供而已...

將找 Origin Server IP 位置自動化的 CloudFlair

Twitter 上看到 CloudFlair 這個工具,可以找被 Cloudflare 保護的網站,將尋找後面 Origin Server 的 IP address 的過程自動化:

這隻程式配合 Censys 的資料去找,而不是自己獨立掃整個 IPv4 address。

另外這隻程式也不保證掃的出來,像是透過 Cloudflare 去年十一月推出的新服務 Wrap,就不需要將 Port 80/443 對 Internet 公開 (參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」)。

不過還是蠻好玩的工具啦 XDDD

PChome 24h 連線會慢的原因... (續篇)

上一篇「PChome 24h 連線會慢的原因...」寫到 DNS resolver 會倒在路邊,但沒寫會怎麼倒... 因為規格書上沒有寫當問不到要問的東西時要怎麼處理,所以每一家處理的方式都不太一樣。

我把對各 DNS resolver 查詢 100 次的結果放在 GitHub Gist 上:「Query 24h.pchome.com.tw」,大家都是回 SERVFAIL,只是時間不一樣 (最後一個 x.xxxx total 的部份表示實際秒數,wall clock)。

先看這次的主角好了,HiNet168.95.1.1168.95.192.1,同時也應該是 PChome 24h 服務使用人數最多的 DNS resolver。

這兩個 DNS resolver 在遇到問題時不會馬上回 SERVFAIL,加上業界有小道消息說中華自己改了不少 code,所以跟一般的 open source software 行為不太一樣。由於看不到 PChome 端的 DNS packet,所以只能就行為來猜... 應該是在第一輪都查不到後,會先 random sleep 一段時間,然後再去問一次,如果第二次還是失敗的話才回應 SERVFAIL

這個 random sleep 看起來可能是 10 秒,因為數據上看起來最長的時間就是這個了。

SEEDNet 的 139.175.1.1 以及 Google8.8.8.8 都沒這個問題,都會馬上回應 SERVFAIL

前陣子新出的 9.9.9.9 (參考「新的 DNS Resolver:9.9.9.9」) 則是有些特別的狀況,可以看到前面有三個 query 很慢 (第 2、3、5 三行),但後面的速度就正常了。可能是新加坡那邊有三台伺服器在服務 (目前我這邊測試的機器到 9.9.9.9 會到新加坡),在第一次遇到都沒有答案時會有特殊的演算法先確認,之後就會 cache 住?

所以各家 DNS resolver 反應都不太一樣,然後最大那家有問題 XD

24h.pchome.com.tw 慢一次,ecvip.pchome.com.tw 再慢一次,圖片的 a.ecimg.tw 再慢一次,一個頁面上多來幾個 domain 就會讓人受不了了 XD

其實我只要改成 8.8.8.8 或是改走 proxy.hinet.net 就可以解決啦,但還是寫下來吧 (抓頭)。

Archives