IPv6 互聯網中的隱私保護和網路管理器

通過 IPv6 方式連接的主機的特性

啟用了 IPv6 的節點（LCTT 譯註：節點在網路中指一個聯網的設備）並不需要類似 IPv4 網路中 DHCP 伺服器的中央機構來配置他們的地址。它們 發現 （ discover ） 自己所在的網路，然後通過生成主機部分來自主生成地址。這種方式使得網路配置更加簡單，並且能夠更好的擴展到更大規模的網路。然而，這種方式也有一些缺點。首先，這個節點需要確保它的地址不會和網路上其他節點衝突。其次，如果這個節點在進入的每一個網路中使用相同的主機部分，它的運動就可以被追蹤，如此一來，隱私便處於危險之中。

負責制定網際網路標準的組織 Internet 工程任務組 （ Internet Engineering Task Force ） （IETF）意識到了這個問題，這個組織建議取消使用硬體序列號來識別網路上的節點。

但實際的實施情況是怎樣的呢？

地址唯一性問題可以通過 重複地址檢測 （ Duplicate Address Detection ） （DAD）機制來解決。當節點為自身創建地址的時候，它首先通過 鄰居發現協議 （ Neighbor Discovery Protocol ） （一種不同於 IPv4 ARP 協議的機制）來檢查另一個節點是否使用了相同的地址。當它發現地址已經被使用，它必須拋棄掉這個地址。

解決另一個問題——隱私問題，有一點困難。一個 IP 地址（無論 IPv4 或 IPv6）由網路部分和主機部分組成（LCTT 譯註：網路部分用來劃分子網，主機部分用來從相應子網中找到具體的主機）。主機查找出相關的地址的網路部分，並且生成地址的主機部分。傳統上它只使用了源自網路硬體（MAC）地址的 介面識別器 （ Interface Identifier ） 。MAC 地址在硬體製造的時候就被設置好了，它可以唯一的識別機器。這樣就確保了地址的穩定性和唯一性。這對避免地址衝突來說是件好事，但是對隱私來說一點也不好。主機部分在不同網路下保持恆定意味著機器在進入不同網路時可以被唯一的識別。這在協議制定的時候看起來無可非議，但是隨著 IPv6 的流行，人們對於隱私問題的擔憂也愈演愈烈。幸運的是，解決辦法還是有的。

使用 隱私擴展 （ privacy extensions ）

IPv4 的最大問題——地址枯竭，已經不是什麼秘密。對 IPv6 來說，這一點不再成立，事實上，使用 IPv6 的主機能夠相當大方的利用地址。多個 IPv6 地址對應一塊網卡絕對沒有任何不合適，正好相反，這是一種標準情形。最起碼每個節點都有一個「 本地連接 （ link-local ） 地址」，它被用來與同一物理鏈路的節點聯絡。當網路包含了一個連接其他網路的路由器，這個網路中的每個節點都有一個與每個直接連接的網路相聯絡的地址。如果主機在同一個網路有更多的地址，該節點（LCTT 譯註：指路由器）將接受它們全部的傳入流量。對於外發連接，它會把地址顯示給遠程主機，內核會挑選最適合的地址。但到底是哪一個呢？

啟用了隱私擴展，就像 RFC4941 定義的那樣，時常會生成帶有隨機主機部分的新地址。最新的那個被用於最新的外發連接，與此同時，那些不被使用了的舊地址將被丟棄。這是一個極好的策略——主機不會對外暴露其固定地址，因為它不用於外發連接，但它仍然會接受知道其固定地址的主機連接。

但這也存在美中不足之處——某些應用會把地址與用戶識別綁定在一起。讓我們來考慮一下這種情形，一個 web 應用在用戶認證的時候生成一個 HTTP Cookie，但它只接受實施認證的地址的連接。當內核生成了一個新的臨時地址，伺服器會拒絕使用這個地址的請求，實際上相當於用戶登出了。地址是不是建立用戶認證的合適機制值得商榷，但這確實是現實中應用程序正在做的。

解救之道—— 隱私固定定址 （ Privacy stable addressing ）

解決這個問題可能需要另闢蹊徑。唯一的（當然咯）地址確實有必要，對於特定網路來說是穩定的，但當用戶進入了另一個網路後仍然會變，這樣的話追蹤就變得幾乎不可能。RFC7217 介紹了一種如上所述的機制。

創建隱私固定地址依賴於偽隨機值，這個隨機值只被主機本身知曉，它不會暴露給網路上的其他主機。這個隨機值隨後被一個密碼安全演算法加密，一起被加密的還有一些與網路連接的特定值。這些值包含：用以標識網卡的名稱；網路地址；對於這個網路來說有可能的其他特殊值，例如無線網路的 SSID。使用這個安全密鑰使其他主機很難預測結果地址，與此同時，當進入不同的網路時，網路的特殊數據會讓地址變得不同。

這也巧妙的解決了地址重複問題。因為有隨機值的存在，衝突也不太可能發生。萬一發生了衝突，結果地址會得到重複地址檢測失敗的記錄，這時會生成一個不同的地址而不會斷開網路連接。看，這種方式很聰明吧。

使用隱私固定地址一點兒也不會妨礙隱私擴展。你可以在使用 RFC4941 所描述的臨時地址的同時使用 RFC7217中的固定地址。

網路管理器 （ NetworkManager ） 處於什麼樣的狀況？

我們已經在網路管理器1.0.4版本中實現了 隱私擴展 （ privacy extensions ） 。在這個版本中，隱私擴展默認開啟。你可以用 ipv6.ip6-privacy 參數來控制它。

在網路管理器1.2版本中，我們將會加入 固定隱私定址 （ stable privacy addressing ） 。應該指出的是，目前的隱私擴展還不符合這種需求。我們可以使用 ipv6.addr-gen-mode 參數來控制這個特性。如果它被設置成固定隱私，那麼將會使用固定隱私定址。設置成「eui64」或者乾脆不設置它將會保持傳統的默認定址方式。

敬請期待2016年年初網路管理器1.2版本的發布吧！如果你想嘗試一下最新的版本，不妨試試 Fedora Rawhide，它最終會變成 Fedora 24。

我想感謝 Hannes Frederic Sowa，他給了我很有價值的反饋。如果沒有他的幫助，這篇文章的作用將會遜色很多。另外，Hannes 也是 RFC7217 所描述機制的內核實現者，當網路管理器不起作用的時候，它將發揮作用。

via: https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/

作者：Lubomir Rintel 譯者：itsang 校對：wxy

本文由 LCTT 原創翻譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive