Category Archives

16 Articles

使用Redis協議來調試ngx.shared

0   224 轉為簡體

有時候用ngx.shared的時候想看一下到底存進去的值是什麼,或者想列一下滿足條件的鍵,或者想批量操作,所以這個項目就是用來解決這個問題的。

除了支持ngx.shared提供的操作以外,學習Redis增加了PING(測試連通性),KEYS(列出符合條件的鍵)和EVAL(在服務器上執行Lua腳本)。

已上傳到opm,可以通過

opm install fffonion/lua-resty-shdict-server

一鍵安裝。

由於目前stream和http子系統是兩個獨立的Lua VM,因此不能通過全局變量來共享數據。另外兩個子系統的shdict是分別定義的,因此也不能互擼。所以如果想用這個模塊來在redis-cli里擼http子系統下定義的shdict,需要這個補丁

示例配置:

然後

 

使用lua-nginx-module緩存JSONP

0   1473 轉為簡體

最近給暢言加上了單點登錄,也就是可以用網站的帳號來在暢言上發射評論。暢言會通過你設置的一個接口來獲得用戶名,頭像等。但是我發現隊友暢言會頻繁請求這個接口,有時候會達到單個用戶一秒鐘好幾次??

雖然在php層有redis,壓力不會很大,但是這樣頻繁的請求還是會中防CC的策略,影響用戶正常的瀏覽。所以我決定在CDN上做個緩存。

Read More

ipip.tk地理位置查詢

2   2724 轉為簡體

基於OpenResty ,MaxMind GeoIP數據庫和從bgp.he.net生成的ASN數據庫,因為沒有經緯度的需求所以沒有顯示。下文有源代碼的鏈接,如果需要可以自行修改加上經緯度或者將輸出變為JSON等。

這裡有chrome插件

使用方法

查詢當前IP地理位置

$ curl https://ipip.tk/
x.x.x.x
Country, City
ASN number

查詢當前IP

$ curl https://ipip.tk/ip
x.x.x.x

查詢指定IP的地理位置

$ curl https://ipip.tk/74.125.203.199
74.125.203.199
United States, Mountain View
AS15169 Google Inc.

查詢域名的地理位置

$ curl https://ipip.tk/www.google.com.hk
74.125.203.199
United States, Mountain View
AS15169 Google Inc.

查詢域名的IP

$ curl https://ipip.tk/www.google.com.hk/ip
74.125.203.199

查詢域名的IP和CNAME(如果存在)

$ curl https://ipip.tm/www.google.com.hk/dns
www-wide.l.google.com 74.125.203.199

源代碼

在這裡https://gist.github.com/fffonion/44e5fb59e2a8f0efba5c1965c6043584

需要ngx_http_geoip_module, echo-nginx-module, lua-nginx-module,安裝libgeoip,並將maxmind的舊版geoip數據庫放在/usr/share/GeoIP

通過bgp.he.net生成ASN數據庫

Read More

用 OpenResty 寫了一個 SNI 代理

0   3536 轉為簡體

功能類似於dlundquist/sniproxy

推薦 OpenResty 加上 stream 模塊和 ngx_stream_lua_module 模塊。在 1.9.15.1 上測試通過。

示例配置:

A Lua table sni_rules should be defined in the init_worker_by_lua_block directive.

The key can be either whole host name or regular expression. Use . for a default host name. If no entry is matched, connection will be closed.

The value is a table containing host name and port. If host is set to nil, the server_name in SNI will be used. If the port is not defined or set to nil, 443 will be used.

Rules are applied with the priority as its occurrence sequence in the table. In the example above, twitter.com will match the third rule rather than the fourth.

If the protocol version is less than TLSv1 (eg. SSLv3, SSLv2), connection will be closed, since SNI extension is not supported in these versions.

Let’s Encrypt集中化管理

9   2894 轉為簡體

Let’s Encrypt的證書籤發原理實際上和傳統的PKI一樣,只不過自動化完成了生成CSR和私鑰、提交CSR、取回證書的過程。

此外還要驗證域名所屬,這一部分和傳統的簽發機構是一樣的,不過傳統的簽發機構還允許我們使用域名whois中填寫的郵箱來驗證,而Letsencrypt貌似只能通過http challenge的方式來驗證。即和驗證服務器約定一個uri和隨機字符串,驗證服務器請求這一uri,如果得到的內容和約定的隨機字符串相同,則驗證通過。如圖所示:

letsencrypt_howitworks

官網上抄的)

這意味着我們得在每台部署https的前端的負載均衡服務器上都裝一個letencrypt工具。有沒有什麼集中化管理的辦法的呢?

實際上,由於challenge的uri的有規律,我們可以將前端服務器收到的這類請求代理到同一台專門用來簽發、更新證書的服務器上。如圖所示:

letsencrypt_howitworks_proxypass

  1. 當在服務器B上發起域名a.example.com新的簽發請求後,Let’s Encrypt的簽發服務器返回一個challange uri (8303)和response (ed98)。
  2. 服務器B使用webroot插件將這個uri和response寫入本地磁盤上對應的文件。
  3. Let’s Encrypt的簽發服務器為了驗證example.com的所屬,查詢到example.com指向前端服務器A,於是發送一個HTTP請求/.well-known/acme-challenge/8303到服務器A
  4. 服務器A反代這一請求到服務器B
  5. B讀取剛才第二步時寫入到response,返回到A;A返回到Let’s Encrypt的簽發服務器
  6. 驗證成功,發證!

然後,我們只要從服務器A上取回存儲在B上到證書就可以了。可以在B上做一個RESTful的api。注意要配置allow和deny。

A服務器(前端)的nginx配置如下:

B服務器的nginx配置如下:

然後在B上運行: