標籤 網絡 下的所有文章

整理筆記:BGP

BGP,Border Gateway Protocol,邊界網關協議。是一種去中心化、自治、矢量的外部網關協議(EGP)。幾個月前,因興趣使然,決定瞭解一下。說是去瞭解——只不過是偶爾無事可做的時候用來消磨時間罷了。

就像 OSPF、RIP 等內部網關協議(IGP)一樣,BGP 中也有鄰居的存在,通常稱為 peer。但與 IGP 不同,IGP 通常通過廣播來發現鄰居。BGP 中的鄰居必須手動配置鄰居關係。每個 peer 都有自己的 ASN (Autonomous System Number),BGP 中通過 AS 與 peer 來形成鄰接關係。

BGP 有兩種。擁有不同 ASN 的 peer 形成鄰接關係後,會成為 eBGP(External BGP),而擁有相同 ASN 的 peer 則是 iBGP(Internal BGP)。

eBGP 用於在不同的 AS 中交換路由信息。每個 AS 只知道自己的 IP 前綴(如:45.76.204.0/23,代表 45.76.204.0 – 45.76.205.255,寫這篇文章時,它在互聯網上由 AS20473 廣播)。AS 知道怎麼路由到自己的前綴。 AS 通過與其它 AS 形成鄰接來獲取對方前綴的 nexthop。

BGP 是通過「廣播」來交換信息的。默認情況下,BGP 會廣播自己所知道的路由(包括從別的 peer 學習到的路由,nexthop 會變成自己)給所有的 peer。廣播信息中會有一個 AS_PATH 屬性,記錄著這個前綴經由的 AS。peer 不會接受 AS_PATH 內有自己的 AS 的路由,來防止回環。通過這樣的方法,組成了互聯網。

前面說到 eBGP 會把從別的 peer 學到的路由的 nexthop 改成自己。在 iBGP 中不會。這樣可能會廣播一個 iBGP peer 不可達的 nexthop 給 iBGP peer。這時通過 next-hop-self 可以將 nexthop 改成自己。

默認情況下,eBGP 的 TTL 只有 1。這意味著,若 eBGP peer 不是直接連接,則通信數據包會在抵達到下一跳時被丟棄(iBGP 則沒有限制)。通過 ebgp-multihop 可以增加 TTL。一般情況下這沒有用。因為經由的路由沒有和你或者對方 peer,peer 會將接受到的 prefix 的 nexthop 設為它接到數據包的前一跳(即經由路由)。而經由路由沒有與你 peer,他們不知道怎麼抵達你的前綴。

所以它並不是這麼用的。在多條鏈路的時候 ebgp-multihop 就有用了。假設你與 peer 有兩條條連線:

+-----------------+ +-----------------+
| AS1             | | AS2             |
| eth0: 10.0.0.1 ----- eth0: 10.0.0.2 |
| dummy0: 1.1.1.1 | | dummy0: 2.2.2.2 |
| eth1: 10.1.0.1 ----- eth1: 10.1.0.2 |
+-----------------+ +-----------------+

Routing table: 
| AS1                   | AS2                  |
| 2.2.2.2 via 10.0.0.2  | 1.1.1.1 via 10.0.0.1 |
| 2.2.2.2 via 10.1.0.2  | 1.1.1.1 via 10.1.0.1 |

Peer config AS1:
nei 2.2.2.2 remote-as 2
nei 2.2.2.2 ebgp-multihop 2
nei 2.2.2.2 update-source dummy0

Peer config AS2:
nei 1.1.1.1 remote-as 1
nei 1.1.1.1 ebgp-multihop 2
nei 1.1.1.1 update-source dummy0

通過這種方式,就能有兩條到 peer 的連線。即使其中一條斷開,也能保持鄰接關係。

與 ISP 的 BGP peer 通常有幾種:

– 「Single Homed」只有單一鏈路,只與一個 ISP 形成鄰居關係。
– 「Dual Homed」有多條鏈路,只與一個 ISP 形成鄰居關係。
– 「Single Multi-homed」與多個 ISP 形成鄰居關係,每個 ISP 只有一條鏈路。
– 「Dual Multihomed」與多個 ISP 形成鄰居關係,每個 ISP 有兩條鏈路。

通常,要抵達一個前綴會有多條路徑。BGP 通過幾種方法來確定選擇哪一條。每個 peer 都可以指定 Weight 屬性,Weight 最高者會被選中(例:Single Multi-homed 時選擇優先出口 ISP)。iBGP 可以指定 Local Preference 屬性。Local Preference 最高者會被作為出口(例:Dual Homed 時選擇優先出口)。若選擇進入自己 AS 的優先路徑,可以使用 Metric 屬性。Metric 最低的路徑會被作為進入 AS 的路徑(例:Dual Homed 時選擇優先入口)。

另外一種影響選路決策的方法是 Prepend。Prepend 就是字面意思,用於在 AS_PATH 前添加一串 AS_PATH。BGP 會優先選擇最短的 AS_PATH。所以,通過 prepend 加長 AS_PATH 可以避免 BGP 選擇這條路徑,而去選擇其它更短的路徑。

BGP 中的 Communities 是一個附加位,通常用於告知 peer 該如何對它的其它 peer 廣播你廣播給它的前綴。Communities 通常是你的 peer 預先配置的一系列規則。可能是 prepend,可能是設置 weight,等。例如 AS20473 提供了這些 Communities:

AS20473 tags prefixes that are learned or originated as follows:

Originated by 20473:                  20473:500
Customer prefix originated by 20473:  20473:540
Prefix learned from Transit:          20473:100
Prefix learned from Public Peer:      20473:200
Prefix learned from Private Peer:     20473:300
Prefix learned from Customer:         20473:400
Prefix learned from AS number:        20473:XXXX
Do not announce to specific AS:       64600:XXXX
Prepend 1x to specific AS:            64601:XXXX
Prepend 2x to specific AS:            64602:XXXX
...

BGP 里有種東西叫做 Route Reflector(RR)。可以想象成 OSPF 里的 Designated Router。RR 有三種角色。eBGP 鄰居,iBGP 成員(client)鄰居,與 iBGP 非成員鄰居。從 eBGP 鄰居,與 iBGP 成員鄰居學習到的前綴會廣播給所有的鄰居。而從 iBGP 非成員鄰居學來的前綴只會被廣播給 iBGP 成員鄰居與 eBGP 鄰居。通過 BGP Confederation 也能達成和 Route Reflector 類似的效果。由於這允許了 iBGP 成員間的前綴學習,可能導致回環,BGP 引入了 Originator 與 Cluster List 來避免回環。Originator ID 由 RR 成員自己設置,iBGP 會無視 Originator ID 是自己的路由。Cluster List 類似 AS Path,在多個不同的 RR 組互相連接時,廣播給其它 RR 組的 Cluster List 內會加上自己的 Router ID,若在 Cluster List 中看到自己的 Router ID,則不會接受。

BGP 另外一個很重要的部分就是 filter。不同的 bgpd/路由器 有不同的實現,甚至是不同的名字。但大致功能就是:設置出站/入站前綴的屬性,或者禁止某個前綴被廣播/被接受。比如,Multihomed 的時候你可能會成 Transit AS,如果你不是 ISP,可以通過禁止某個 AS 的前綴從你這裡出站來避免成為 Transit AS 而節省帶寬。前面說到的設置 Weight/MED 等,也都會用到 filter。

和 IP 一樣,ASN 也是由 IANA 分發給 RIR,個人/組織再向 RIR 申請的。但是,在僅與一家 ISP peer 的時候,並不一定需要自己的 ASN。ISP 可能會給你一個公共 ASN,或者使用私有 ASN 來 peer。私有 ASN 的範圍是 64512 – 65534 與 4200000000 – 4294967294。(16 位 ASN 與 32 位 ASN)私有 ASN 是不能出現在公共網絡上的。通過 remove-private-as,可以移除 AS PATH 里的私有 ASN(若 PATH 中包含公共 ASN,則不會起效)。

有時候會使用 MPLS VPN 來通過 ISP 連接兩處地理隔絕的網絡。如果它們的 AS 相同,BGP 會以為這是回環而拒絕接受前綴。這時候可以在用戶的邊界路由(CE)上做 allow-as-in,或者 ISP 的邊界路由(PE)上做 as-override。allow-as-in 會忽略 AS PATH 中的自己的 ASN。as-override 會將 CE 設備的 ASN 換成 PE 設備的 ASN,而避免 AS PATH 里出現 CE 設備的 ASN。

寫得很混亂,想到什麼寫什麼,純粹靠記憶,可能有錯誤之處。

筆記:用伺服器上第二 IP 為 NAT 後的裝置提供公網地址

上回說到給宿舍的路由提供 IPv6。其實裡面很大一個原因是想通過外網來訪問 NAS 和 PC。可是並不是哪裡都有 IPv6。那就把公網 IPv4 也提供一下吧。

當然。沒法讓整個局域網都有公網 IPv4,買不起 IPv4 塊。只路由一個 IPv4,給網關用。

順帶一提,v6 隧道的中繼節點換到了 vultr 在 NY 的伺服器。過去只有 8 毫秒,不在 HE 的黑名單裡,還只要 2.5 US$ 一月,很舒心。更有趣的是 vultr 能很方便的新增 IPv4 地址。每個額外的地址要 2 US$ 一月。也就是說,總價 4.5 US$,就能擁有一個 IPv4 和一塊 /48 的 IPv6 出口網關。

總之,進入正題。首先,tap 可能是 down 的,用 ifconfig 把它帶起來,然後將要給隧道客戶端用的 IPv4 公網地址(假設是 108.61.xxx.xxx)路由到 tap 上:

ip route add 108.61.xxx.xxx/32 dev tap0

當然,如果這個 IP 地址已經在 ethX 或者 ensX 上了,要先刪除掉,也就是:

ip addr del 108.61.xxx.xxx/xx dev ensX

然後,回到路由上。添加一個新的路由表,這個表中使用隧道的 interface 作為網關,然後添加一條策略路由規則,讓所有來源於 108.61.xxx.xxx 的流量在那個表裡邊 lookup。不這麼做的話,路由器會從默認網關應答發到 tap0 上的流量 —— 那就完蛋了,這流量它根本就不知道跑去哪裡了。在 MikroTik 裡的做法:

/ip route add distance=1 gateway=ovpn_tunnel routing-mark=tap0_gateway
/ip route rule add src-address=108.61.xxx.xxx/32 table=tap0_gateway

設置好後,108.61.xxx.xxx 的 IP 就已經路由到路由器(隧道客戶端)上了。在它上面的隧道介面新增 108.61.xxx.xxx 這個地址,應該就能正常工作了。MikroTik 中:

/ip address add address=108.61.xxx.xxx interface=nato-us-ny network=108.61.xxx.xxx

路由跟蹤一下(從 Linode KDDI 發起):

                                               Packets               Pings 
 Host                                        Loss%   Snt   Last   Avg  Best  Wrst StDev 
 1. AS2516  106.187.33.2                      0.0%    20    1.1   0.9   0.6   2.2   0.0 
 2. AS2516  124.215.199.169                   0.0%    20    8.3   6.0   0.5  13.4   4.8 
 3. AS2516  otejbb206.int-gw.kddi.ne.jp       0.0%    20    1.2   2.4   1.2   8.6   2.2 
 4. AS2516  pajbb002.int-gw.kddi.ne.jp        0.0%    20  115.8 124.2 115.7 179.9  19.4 
 5. AS2516  sjeGCS002.int-gw.kddi.ne.jp       0.0%    19  109.1 117.4 108.4 261.1  34.9 
 6. AS2516  ix-sj6.int-gw.kddi.ne.jp          0.0%    19  108.6 118.7 108.5 189.4  23.5 
 7. AS3257  ae21.cr0-sjc1.ip4.gtt.net         0.0%    19  119.4 120.4 116.4 181.9  14.9 
 8. AS3257  xe-4-0-0.cr0-nyc4.ip4.gtt.net     0.0%    19  174.3 176.2 172.3 193.3   5.2 
 9. AS3257  as20473-gw.nyc40.ip4.gtt.net      0.0%    19  175.7 178.9 175.0 194.2   4.9 
10. AS20473 vl39-br1.pnj1.choopa.net          0.0%    19  190.0 192.5 189.7 201.6   4.2 
11. AS20473 vl901-c12-10-j2-2.pnj1.choopa.ne  0.0%    19  202.4 198.0 189.1 205.8   3.8 
12. ??? 
13. AS20473 v4-transit.nat.moe                0.0%    19  174.0 173.9 173.7 174.6   0.0 
14. AS20473 v4-gateway.internal.nat.moe       0.0%    19  197.4 199.8 197.3 236.4   8.8

搞定。這裡 v4-transit 是隧道伺服器的主要 IPv4 地址,v4-gateway.internal 是隧道客戶端,也就是路由器。成功給內網裝置提供了一個公共 IPv4 地址,不是用什麼反向連線,也不是什麼 DNAT,是真正的路由到路由器上的 IPv4 地址。

運營商級 NAT 內使用 Tunnelbroker

在學校裡想用 IPv6,但是學校沒給分發。於是就決定使用 Hurricane Electric 的 Tunnel Broker。不好說學校防火牆有沒有堵掉 protocol 41,也就是 6in4。但至少學校的 IPv4 出口不接受 ICMP。

然後 Tunnel Broker 就不開心了。說是必須要允許來自它的 ICMP,才能設定 IPv4 端點。那能怎麼辦,我也很無奈啊。那就只好從別的地方用什麼手段「中繼」一下了吧。

原本是想用 Digital Ocean 的,學校內連線它美國東部的資料中心只有 7 毫秒左右的延時。可是 Tunnel Broker 還是不高興。說這 IP 段在黑名單裡。就很生氣。換了另外一臺在美國中部的機子,成功建立端點。

一開始想的方案是通過 OpenVPN IP 隧道。因為,只要好好做轉發,就算端點在 NAT 後面也是沒有問題的。現實總是不太美好,總之,隧道內的隧道無法建立。去 superuser 題了個問,有人說「 IPv6 does not have fragmentation like IPv4 does, so shrinking the MTU with tunnels in tunnels could cause other problems. IPv6 also has a minimum MTU of 1280」。看了看自己 MTU 明明是 1500 —— 可能還有別的什麼玄學,總之這個方案被拋棄了。

然後就會想到直接用 OpenVPN 分發 IPv6 了,對吧?可是奈特使用的路由器,也就是之前提到的 MikroTIk 的路由器,上面的 OpenVPN 實現不支援 IPv6。

嗯 —— 那,放棄了?

當然不行。都研究了這麼多了。雖然路由器上面的 OpenVPN 不直接支援 v6,但是我們可以直接用 tap 隧道呀。tap 隧道的話就相當於 ethernet 了,好比兩張網卡用線連起來一樣。是執行在 Layer 2 上的。所以啥協議都能往上面套。

在伺服器直接分發估計也行,不過奈特傾向於在路由器這邊做。總之,無論怎麼做,先從 Tunnel Broker 申請一段 /48 的 IPv6 塊。然後,從裡面隨便選一塊 /64 出來。路由到 tap 介面的 link-local 地址上。也就是說:

ip -6 route add <your /64 zone>::/64 via fe80::...

然後回路由器來,在上面把 IPv6 路由到 tun 隧道的 IPv6 link-local 上。在 MikroTik 裡的話:

/ipv6 route add dst-address=2000::/3 gateway=fe80::...4%ovpn-tunnel

然後就搞定了。接下來就是區域網裝置的地址分配,不想在隧道伺服器那邊做,所以就在本地 LAN 橋上新增剛才路由到這兒的區域的地址塊,並且廣播:

/ipv6 address add address=<your /64 zone> interface=bridge advertise=yes

然後就:

IPv6 測試成功

IPv6 測試成功

好了。就這樣。

筆記:hAP ac (RB962UiGS-5HacT2HnT) 上的 5Ghz 無線配置

出於某些原因,用 OpenVPN 架了一個 site-to-site 的隧道 – 用來連線在學校宿舍裡的網路和某處的一個區域網。因為廣播的包也需要走隧道,那 OpenVPN 的 tun 隧道就行不通了,只能用支援 Layer 2 的 tap。隧道的這邊是一臺 RB3011UiAS-RM,手頭有一臺能使用的 hAP ac。現在想要做的事是,讓連線 WiFi 的移動裝置也能接入這個 VPN 的網路。

嗯,既然 Android/iOS 的 OpenVPN 不支援 tap,更何況 tap 上根本就沒有 DHCP,看著手頭有的裝置,能想到的只有設定一個無線網路,並且和 VPN 介面橋接來實現了。

說來學校是不讓學生自設 AP 的,如果私自架設 AP 會導致網口直接被禁用。不過,只要 WLAN 介面在 NAT 後面,就不會有事。猜測應該是有無線 IDS 記錄各個 WiFi 的 BSSID,如果在某個網口看見和 BSSID 一樣的 MAC,就禁用吧。為什麼會知道?因為在 cli 操作的時候一個不小心把 WLAN 介面和 WAN 介面橋接一塊兒去了,然後沒過幾分鐘,網口就被禁用了。如果學校沒有用魔法的話,這大概是唯一的方法。

但是無線還是得用的。偷偷的放在 NAT 後面,降低功率,選個不會干擾學校通訊的頻率 —— 只有這樣了。雖然覺得像是在做虧心事。看了看周圍的無線電頻率,都分佈在 CH 34-64, 149-165 裡。說實話這是第一次見排列這樣整齊的網路,每隔 5 個頻道就有一坨 20Mhz 的無線電,總之應該是做了很仔細的規劃,將不同 AP 之間的干擾降低到最低。我也不想打破這份寧靜,於是就決定使用 100-144 之間的頻率了。不知道為什麼沒有任何網路在這個區間,根據 FCC,這些個頻率在美國是能使用的,可能有些客戶端會拒絕使用這些頻率?沒有頭緒。

總之,既然這些區間完全沒有別的網路,那就可以放心的使用 80 Mhz 頻寬了。決定使用 CH 104-110。首先把國家設定成 US,頻率模式用 regularoy-domain。這樣頻率列表就只會顯示合法的頻率。

然後,來看看頻率表:

無線頻率表

無線頻率表

80 Mhz 的頻道是第二個,那麼我們就把中心頻道放那兒吧。也就是說,20/40/80Mhz eCee。(e: extension, C: center,即 eCee = CH104(20Mhz): e, CH106(80Mhz): C, CH108(20Mhz): e, CH110(40Mhz): e)。

總之,無線電配置看起來是這樣的:

無線電配置

無線電配置

配置好了,看看速度:

無線速率

無線速率

1300Mbps, 80Mhz,沒問題了。

某廠商的「精準IP定位API」

無意之間,看見了百度的高精度IP定位API。在這裡找到了能夠拿來測試的工具。該怎樣說呢,這API還真是,非常有趣。

舉個例子,如果把之前 @lbx 的,位於新加坡shadowsocks 服務器的 IP 進行查詢,會得到奈特曾經就讀的高中的位置:

百度的定位API

百度的定位API

先不管為什麼這個頁面標題是「AIP」而不是「API」,我一個新加坡服務器,怎麼就跑到佛山去了呢?但是位置的確是對的,這個代理服務器主要是在學校裡邊使用,學校的移動網絡連接這台新加坡服務器速度比較快。所以猜測是,手機上的,百度開發的 App,提交了用戶的 GPS 信息到服務器上。和用戶的 IP 位址進行匹配,然後由此生成 IP-CIDR 到 GPS 座標的對應吧。

於是接下來對其餘幾個 shadowsocks 服務器進行考察,發現也是類似的效果。例如日本的機子被認為在濟南,而正好那裡有頻繁使用日本服務器的用戶。

要說的話,百度這個做法其實挺危險。透過公網 IP 對應 GPS,會增加網民被「人肉」的危險。從前,知道了對方 IP 位址後,只能獲得大概的地理位置,需要花費好一番功夫才能拿到精確地理位置需要一番周折。而現在百度幫忙做了這個工作,這是要搞事情啊。並且,若百度真的是使用這樣的方式定位,但一定數量的人開始搗亂,例如偽造 GPS 位址之後,定位信息也會錯亂。

筆記:在 OpenWRT 使用 PPTP 將兩個遠端局域網連通

需求:

  1. 兩個網段不同的局域網,文中使用:
    • 192.168.0.0/24
    • 192.168.1.0/24
  2. 一個PPTP服務器,使用獨立於上述兩個網絡的網段,文中使用:
    • 10.1.0.0/24

步驟:

  1. 按照這裡為OpenWRT配置PPTP支持。
  2. 設置PPTP
    1. 設置憑據
    2. 為PPTP創建新的防火牆區域,允許LAN=>PPTP轉發以及PPTP=>LAN轉發
    3. 在PPTP接口的高級選項中取消勾選「使用默認網關」。
    4. 在pptp伺服器上,chap-secret中為客戶端指定IP地址(推薦),文中使用:
      • 192.168.0.0/24網段的pptp賬戶:10.1.0.2
      • 192.168.1.0/24網段的pptp賬戶:10.1.0.3
    5. 將兩個OpenWRT的PPTP接上服務器。
  3. 配置靜態路由表
    1. 在192.168.0.0/24網段的路由上,設置下列路由:
      • 接口:pptp;目標:10.1.0.0,子網掩碼:255.255.255.0,網關10.1.0.1。
      • 接口:pptp;目標:192.168.1.0,子網掩碼:255.255.255.0,網關10.1.0.1。
    2. 在192.168.1.0/24網段的路由上,設置下列路由:
      • 接口:pptp;目標:10.1.0.0,子網掩碼:255.255.255.0,網關10.1.0.1。
      • 接口:pptp;目標:192.168.0.0,子網掩碼:255.255.255.0,網關10.1.0.1。
    3. 在pptp服務器上,設置下列路由:
      • 接口:pptp;目標:192.168.0.0,子網掩碼:255.255.255.0,網關10.1.0.2。
      • 接口:pptp;目標:192.168.1.0,子網掩碼:255.255.255.0,網關10.1.0.3。

      如果在步驟2.4中沒有為客戶端指定IP地址,則每次IP變動後都需要重新指定兩個192.168網段的網關至其在PPTP服務器上的IP地址。

至此,兩個網絡便已經通過pptp接在了一起。

問題:

  1. kmod-mppe似乎在某些路由器上沒法加載,那麼,直接禁用它吧。在服務端與客戶端中的pptp配置文件中注釋掉就可以了。
  2. OpenWRT的pptp有些奇怪。在pptp斷開後有幾率無法連接,這時候,把服務器地址修改下(域名換成IP,或者IP換成域名),就能解決了。

這些問題怎麼來的?誰知道呢…

“技術並不可恥”——快播案所感

快播,在當時那個時候可謂是看片神器,與傳統播放軟體不同的是,快播集成了不一樣的播放引擎,應用P2P加速技術以及全格式支援,使其成為了當時最好用的播放器。何曾幾時,我們開啟快播,只為讓在生活在繁雜之中的我們的心,得以休憩。我們不能否認快播曾給我們帶來歡聲笑語——然而現在,快播卻被這樣莫須有的罪名囚禁著。這可謂是擊碎了萬千總是快播使用者的心。

當然因其這種特性,也成為了各黃色網站的欽定播放器。這些網站通過快播的QSI機制,可以使用快播的快取技術及P2P技術,滿足了使用者的“高頻、剛需”。正如王欣太太所說的:

最開始大家用的是迅雷,就是要先下載才能看,而快播只要5-10秒就可以看,如果按每人每天節約半小時計算,可以說快播在迅雷的基礎上幫全中國人省了兩千年。

2016年1月7日、8日北京市海澱區人民法院對被告單位深圳市快播科技有限公司及其主管人員被告人王欣、吳銘、張克東、牛文舉進行了公審。

在這場庭審以前,他的名字叫“那個快播CEO”。在這場庭審以後,他成了這個國家最有種的男人。

在審判過程中,快播的辯方展示出一種碾壓姿態,王欣面對公訴方的提問,表現也是無懈可擊。

技術並不可恥

從其表面意思來看:“技術本身是無罪的”。正如菜刀一樣,可以做菜,也可以殺人。只是使用方法或使用的人不同。所以技術本身並不可恥,可恥的是需求。

快播的主營業務是播放器業務、遊戲業務和機頂盒業務。播放器業務靠資訊廣告、搜尋引擎合作以及會員收入。王欣在法庭上解釋道:

第三方網站管理者可以將QSI下載到自己電腦裡,通過編輯視訊得到一個雜湊碼,也就是編號,他如果將編號粘到網上,線民就可以看見視訊了。

快播播放器和快播伺服器不具備釋出功能和搜尋功能,釋出者只能通過其他軟體上傳視訊,快播從中不獲得利益。只是使用個人需求使用了快播的技術平臺,卻判了快播的罪。

若按其邏輯大眾使用百度搜索搜尋淫穢內容是否有罪?

迅雷下載是否有罪?

這個雲那個雲是否有罪呢?

我們手機每天都有收到詐騙資訊,中國移動為什麼不轉型啊?

微信工具從開發到現在,是有多少刑事案件是通過微信傳播淫穢視訊的,還有百度雲,這個雲那個雲的,對還有QQ,QQ最嚴重。為什麼不去關停騰訊公司,百度公司?

你看直播造人,是不是要關鬥魚啊?

這樣說的話,那對所有的技術公司都是一個打擊。在開發技術前,你要預知:“這個技術的使用者會不會拿它去犯法呢?”這對技術的創新何嘗不是一種打擊呢?

王欣:我們只是一家技術研發公司,就算使用者不用我們的技術,也會用其他公司的技術。

雖不得不說快播是促進了淫穢內容的傳播,但倒下了一個快播公司,也無法徹底根治色情內容的傳播,會有新的技術替代它。

正所謂:有需求就有供需不平衡、有供需不平衡就有市場流通的問題。

最後,祝好人一生平安。


来自NAT的话:

其實對於快播被審,我原本是不以為意的。畢竟我從來沒有用過… lol 不過在看了公審之後。我… 蛤蛤蛤蛤 :)

不過笑歸笑,公訴人有幾句話真是說到民眾的心坎裡了啊!加密了不能解密嗎?能!你說為了公正執法,為啥不能呢?哦你說隱私權啊?我跟你講你不要拿法律當擋箭牌!你看看你看看,我們一直調侃著說的話,這次終於是被直接了當,大膽的說出來了。有骨氣,佩服!你看看人萬惡的資本主義老美,NSA偷看個隱私還弄個稜鏡項目,偷偷摸摸,根本不像個大國的樣子。再看看我們社會主義國家,完美!查就查,查的你啞口無言,這執法效率沒得說!偷偷傳播淫穢色情,一下子就能被發現了呢!哪像那些資本主義國家,說著治理治理,根本就什麼都不做!你說實打實的證據就擺在伺服器裡,不查,明顯口是心非,心口不一,不作為。

蛤蛤蛤哈蛤蛤,你國真是太棒了!

不過民眾大概是反應過激了(我也是)。難得有吐槽這凌駕於自己頭上的“公正”政策的機會了。也好,有些事情不發洩妥妥的得逼死。讓憤青們噴一噴,事也就了結了。所以感謝公訴人給廣大民眾了這麼一個完美大發洩途徑。

再者說了,其實王欣是不是真清白大家也都清楚——不過,託了公訴人那不著邊際的言語的福,這案子怕是難定罪了。這次搞的這個案子啊,exciting!或許這樣是有助於提高民智的。這場戰爭已經昇華到了另一層面:這已經不僅僅是快播的戰爭,而是對於整個體制的抗爭。

”這真是一場反色情的戰爭嗎?開始也許是的,但現在已經是一場反體制的戰爭了,這是一個比色情嚴重得多的問題,而在這個問題上,王欣被迫站在被告席上,被迫以被告的身份,指控一個體系對人類天性的壓抑和對法律體系的漠視,如果站在被告席上的不是一個被逼著上的王欣,很難想象我們能不能如此諷刺地看到事實真相。“——徐湘楠@知乎

不說了,感覺我已經生活在水深火熱中了 :)

使用 bind9 作為 GeoDNS 伺服器

在繼續前,你需要先了解GeoDNS為何物,以及bind之基本使用方式。

簡單來說,若要讓bind為不同地區的使用者返回不同的查詢結果,則需要判斷DNS請求從何而來。國家IP資料從MaxMind便能獲取到。倘若要將MaxMind的IP地址資料庫變為bind的acl,可以利用這裡的指令碼。但是為了簡化過程,我們直接下載預先做好的的acl檔案。

要如何做到呢?依舊是透過上面提供的連結。

只需要下面這一條指令就能夠下載到acl了。

curl http://phix.me/geodns/download/MaxMind/GeoIP.acl.gz | zcat > geodns.acl

下載完成了之後,進到bind的全局設定裡頭,將這個檔案include進去,然後還需要稍微做些修改。

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

// GeoDNS Configuration

// acl file sepified the IP zones of countries. 
include “/etc/bind/geodns.acl";

include "/etc/bind/named.conf.cn";
include "/etc/bind/named.conf.us";
include "/etc/bind/named.conf.any";

include “/etc/bind/named.conf.default-zones”;

在這裡,/etc/bind/named.conf.cn中指明瞭中國地區解析的地址,/etc/bind/named.conf.us則是美國,/etc/bind/named.conf.any則是任何。需要注意的是,要將any放在最後。否則any將會匹配任何查詢,換言之,在any之後的地區都不會被解析。

這裡將named.conf.cn的內容放出來作為範例:

view "china" {

	match-clients { CN; };
	recursion no;

	zone "magicnat.com" {
		type master;
		file "/etc/bind/zones-china/magicnat.com";
	};

	zone "magicnat.org" {
		type master;
		file "/etc/bind/zones-china/magicnat.org";
	};

	zone "nat.moe" {
		type master;
		file "/etc/bind/zones-china/nat.moe";
	};

	zone …
};

每一個view,就是每一個區域。這個區域要解析的國家在match-clients中定義。例如中國就是CN,美國則是US。也可以將兩個國家一併寫在match-clients中。若要匹配任何國家,則可以使用any。還有一點也是需要注意的:在使用view之後,就不能在view之外存在zones。在named.conf.default-zones中的區域就會出現問題。可以在配置檔案中將其include註釋,也可以將其加入一個view,就像這樣:

view "local" {

	match-clients { any; };
	recursion no;

	// prime the server with knowledge of the root servers
	zone "." {
		type hint;
		file "/etc/bind/db.root";
	};

	// be authoritative for the localhost forward and reverse zones, and for
	// broadcast zones as per RFC 1912

	zone "localhost" {
		type master;
		file "/etc/bind/db.local";
	};

	zone "127.in-addr.arpa" {
		type master;
		file "/etc/bind/db.127";
	};

	zone "0.in-addr.arpa" {
		type master;
		file "/etc/bind/db.0";
	};

	zone "255.in-addr.arpa" {
		type master;
		file "/etc/bind/db.255";
	};

};

最後一點:若是你像我這樣將default-zones的clients設為any的話,你得將載入default-zones的語句放在配置檔案的最末尾。原因和將any區域放在最後是一樣的。

ShadowManager 穩定版本釋出

歷時 4 個月(明明就是五天),shadowmanager的開發終於結束了。

ShadowManager 是一個用於同時維護多個不同加密的 shadowsocks 伺服器的輕量級,可擴展指令碼。

預設命令的使用方式如下:

add: 新增一個伺服器到 shadowmanager 的管理,需要 3 個參數。埠,密碼,和加密方法。
start: 啟動 shadowmanager,無需參數。
stop: 停止 shadowmanager,無需參數
restart: 重啟 shadowmanager,無需參數。
status: 檢視 shadowmanager 狀態,無需參數。
show: 顯示所有 shadowsocks 伺服器,無需參數。
remove: 移除指定 ID 的 shadowsocks 伺服器,使用 "show" 來檢視所有伺服器,需要 1 個參數,伺服器 ID。
enovr: 啟用一個或多個覆寫,可將覆寫名作為參數(可選)。
disovr: 禁用一個或多個覆寫,可將覆寫名作為參數(可選)。

Shadowmanager 的特性之一是其可擴展性,在 Shadowmanager 中,提供了覆寫(Overrides),包含(Includes)與鉤子(Hooks)。它們可以被用來修改那些未在 Shadowmanager 中給出選項的行為。包含在 Shdowmanager 載入後讀取,覆寫在 Shadowmanager 載入之前。在每個覆寫之前都有兩位字元,它們所代表的是載入的優先順序。優先順序從 00 排列至 zz,字元越往後,優先順序越高。

目前,Shadowmanager 提供這些覆寫:

  • 00-no-root:該覆寫通過替換 root 檢測函數來跳過 root 檢查,在需要臨時關閉 root 檢測時很有用。
  • 10-base64-encrypted-passwd:使用 base64 來儲存伺服器的密碼。這在你需要在密碼中使用特殊字元時有用。
  • 20-json-to-shadowmanager:該覆寫提供了一個 ‘json2manager’ 命令,可以用於將shadowsocks json 配置檔案轉換為 shadowmanager 的配置檔案。
  • 30-generate-qr-code:為 Shadowmanager 的伺服器生成二維碼。
  • 40-randpass:新增一個命令 ‘add-randpass’ 至 shadowmanager,這個命令允許使用者新增隨機密碼的 shadowsocks 伺服器。
  • 70-time-limit:以小時限制每個 shadowsocks 伺服器可以使用的時間。這個覆寫會使用 pre-add 事件鉤子,並新增一個 Cronjob 來檢查賬戶並移除過期伺服器。
  • 90-pre-server-daemon:為每個伺服器使用單獨的程序。在需要分開統計每個伺服器的流量時有用。
  • 90-screen-start:這個覆寫將替換 ‘start’ 命令原本的實現,使用該覆寫會讓 shadowsocks 伺服器在 screen 內啟動,而不是作為服務啟動。這在需要檢視伺服器日誌時有用。
  • 99-chinese-usage:這個覆寫提供了中文的幫助文字。
  • aa-wizard:為 shadowmanager 的伺服器新增、伺服器移除等操作提供一個嚮導。
  • zz-interactive-mode:這個覆寫會使得 shadowmanager 以互動式模式啟動。該方法可能會引起一些問題,故不推薦。

鉤子是在特定行為執行前後運行的函數。這些鉤子可以在 hooks/ 中定義。某些覆寫可能會按需修改鉤子來達成某些目的。在非原版的實現中也可以定義鉤子。(例如覆寫與包含,甚至鉤子本身!)

usage: hook <hooked_function>

Hook 命令會檢測函數是否存在,若存在則會將其執行。

若想要新增您自己的命令用法與解釋至 shadowmanager,您可以使用 ‘add-help’ 與 ‘add-usage’。這兩個命令都會從標準輸入讀取輸入。幫助文字的語言可以在這兩個命令的參數內定義。若留空,則會被作為預設語言顯示(當偏好語言不能被提供時使用)。

usage: echo '   <your-command>: <your-explaination>' | add-help [help-language]
usage: echo '   <your-command>: command-name <parameters>' | add-usage [help-language]

Shadowmanager 釋出於 MIT 協議。項目地址:https://github.com/MagicNAT/shadowmanager/

伺服器被偉大的牆堵上的二三事

就在前天,我的伺服器很不幸的被牆了。那時我用著用著 Shadowsocks,突然之間發現自己的IP地址跑去了fallback的伺服器。

第一個反應是,噫,垃圾玩意,又炸了了吧?( ̄. ̄)

然後緊接著我就發現,誒我去,怎麼網站也掛了?(⊙A⊙)

再接著,我就發現,臥槽?SSH都掛了?Σ(° △°|||)

再然後… 我就發現伺服器被牆了。(;´-`)

實際上一開始還有點小激動,臥槽,牆了啊!感覺自己好厲害啊!(。・`ω´・)

之後就開始苦惱了,轉移IP估計沒個一天搞不定。(´._.`) 伺服器上還有別的網站呢,讓別人操心多不好啊。

說轉移,那就轉移吧,發好工單,兩分鐘就拿到了新IP,於是就去把伺服器上的配置檔案全部改了一遍,然後重啟,等待分配新的IP。

重啟一下,嗯… 這不就分到新IP了嗎,接下來該改ns就可以了吧,還是很方便的嘛。( ; ̄ω ̄)ゞ

然後我在瀏覽器裡輸入了新的IP。

一秒… 兩秒… 三秒…

(・∀・*) 誒?

五秒… 八秒.. 十秒… Timeout!

(° ▽、° ) 誒??

(ʘдʘ|||) 這個IP還是個被牆的IP啊!

深呼吸、緩了緩,然後繼續發工單。(´・_・`)

Linode 那邊的客服倒也不敢怠慢,馬上又給了我個新IP。不得不說 Linode 服務還是不錯的 (才不是軟文!_(:з」∠)_

又把配置全部修改一遍,重啟好之後,我打開了瀏覽器,輸入IP。

(・∀・(・∀・ (・∀・*) 可以的吧?可以的吧?一定可以的吧?

很幸運的,只過了一秒,它開啟啦!!(′▽`〃)

本來以為我到這IP轉移就快要結束了,然後殘酷的現實告訴我,我還是太年輕了。

我開啟enom,等待那破網站緩緩地開啟,然後緩緩的開啟登陸介面,輸入使用者密碼,按下提交。

然後就這樣等了好幾分鐘。

噫?密碼不正確?(,,Ծ‸Ծ,,)

好咯,那我換個。

誒?還是不正確?(ㆀ˘・з・˘)

好咯我輸了,重置密碼咯。我緩緩地走完了密碼重置流程,開啟郵箱。

( ・∀・) 郵件呢?

(・∀・*) 誒沒有嘛?

(*・∀・) 奇怪了,在哪裡呀?

(o゜▽゜)o 難道是我填錯了啥?

那再來一次咯…

又走了一次漫長的流程。然而,

還是什麼鬼都沒有啊!(* ̄△ ̄*)

(´・ω・`) 好吧,大概enom郵件系統是殘廢的。

那就手工電郵給enom好了。

下午發出了郵件,enom終於在第二天的凌晨回覆了我(說好的7×24技術支援呢?)。

( ̄o ̄) 噢,讓我回復郵件回答安全問題啊。

( ̄、 ̄) 那我回咯。

當我回答好傳送出去之後,回頭看了眼發過來的郵件,發現了這麼一句話:

My Support Hours: 6:30am - 3:30pm (Pacific Time), Monday through Friday
Out of the office Saturday and Sunday

(|| ̄□ ̄) 你怎麼不去死啊!我急著重設ns呢!

緩了口氣,看了看垃圾郵件。

( ̄ε ̄;) 原來… 新密碼發了給我了啊。

( ̄ー ̄〃) 不過也是凌晨才發過來的,果然enom的郵件系統是殘廢…

之後,我就愉快的修改了DNS,終於將NS恢復了。

你以為這就完了?

沒有!!

當我開啟我的網站的時候,上面赫然寫著五個字母。

hello

Hello 個鬼啊!這是什麼東西啊!(°□°;)

然後在我傻逼一樣的折騰到晚上之後,我終於發現了問題。

我的域名A記錄寫錯了一個數字。

( 。⊿。) 當時我的表情就是這樣的。

好吧,那我就改回來咯…

可是它還是在那兒Hello。

然後我就覺得奇怪了,dig了一下自己的域名。

然後就發現了,它有一個1周的TTL。(; 。。)

無奈,暫時把域名ns切換到Linode NS,然後靜靜的等了十幾分鍾。

( 。 ▽ 。) 它它它它出來啦!我的網站回來啦!

然後終於結束了IP遷移的大工程。(也成功被自己蠢哭