Category Archives

14 Articles

ipip.tk地理位置查詢

0   1281 轉為簡體

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

使用方法

查詢當前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   1776 轉為簡體

功能類似於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   1667 轉為簡體

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上運行:

搭建一個不被審查的串流站點

17   35420 轉為簡體

原標題:被害妄想症該如何生存

先看配置:

假設:

審查機關擁有運營商級別的入侵檢測設備(比如GFW)

說明:

  1. 全站使用https,關閉SSLv3,關閉弱加密組件
  2. default_server開啟80端口,使用自簽名證書;真實需要訪問的域名(example.com)必須使用有效的證書,或者在本地信任根證書。注意example.com不能開啟80端口,且與default_server使用的證書不能相同。不要使用泛域名證書。這是為了防止審查機關通過直連IP查看返回的證書中的Common Name來得到真實域名。這樣配置之後,直連IP https://xxx.xxx.xxx.xxx默認是返回自簽名證書,無法得到真實example.com。
  3. 選擇性開啟autoindex,通過cookie鑒別。注意也可以通過HTTP Basic Authenication認證。對匹配文件夾的uri(”/”結尾)做認證,示例中只有帶cookie coo=coo的請求才會返回autoindex,否則返回404。
  4. 在location /中禁用目錄末尾自動加斜杠,因為如果自動加斜杠,審查機關可以通過暴力猜測出服務器上有哪些目錄確實存在(返回了301到末尾加/的url)。方法是if (-d $request_filename)返回404。