国产精品秘,国产精品一二三区,五月丁香六月婷婷免费视频,天天综合~91入口,青青91视频,无码狠狠躁久久久久久久网址,久久色成人电影,98成人视频

來源：InfoQ、作者 | Mathew Duggan

翻譯 | 核子可樂、編輯 | Tina

目前的情況實在糟糕。我們要么向云服務商付更多的錢，要么坐視自己的網絡服務崩潰。

最近一段時間，新聞頭條總會時不時提起 IP 地址。AWS 宣布要對每個 IPv4 地址每小時收費 0.005 美元，其他云服務商也紛紛行動，宣稱要對公共 IPv4 這種“奢侈品”開價。Google Cloud Platform 開出的價格是 0.004 美元，跟 Azure 和 Hetzner 的每小時 0.001 歐元基本相當。很明顯，云服務商自己掏錢購買 IPv4 地址空間的時代即將結束。隨著時間推移，當這些地址越來越有價值，想要免費使用自然也就不可能了。

面對這樣的壓力，我們當然應該趕快切換到 IPv6。其實我第一次聽說 IPv6 這東西，是在高中的第一堂思科技術課上。而現(xiàn)在我已經 36 歲了，大家可以想象當時老師說的“即將到來”究竟來得有多慢。到目前為止，我在 IPv6 方面還沒做過多少實際工作，畢竟市場對此類技能的需求實在不旺。而且從業(yè)經歷也還算豐富的我可以證明，沒有任何一家雇主會認真強調 IPv6 方面的技能需求。所以我壓根就沒學，只能說很遺憾錯過了這場網絡領域的巨大變革和進步。

種一棵樹最好的時間是十年前，其次是現(xiàn)在。學習 IPv6 當然也是如此，所以我打算試著把自己的博客遷移到 IPv6。我會繼續(xù)把它放在 CDN 后面來處理 IPv4 流量，但無論如何，這個重要的歷史時刻終于來臨了！但我驚恐地發(fā)現(xiàn)，關于 IPv6 的一切幾乎都沒法開箱即用。主要依賴項會立即停止運行，而解決方案也很難稱得上“生產就緒”。即使是人員充足的技術團隊，在處理 IPv6 遷移過程時也是異常艱難，畢竟幾乎沒人在這方面的實踐經驗。我們多年來都忽略了這個問題，而現(xiàn)在是時候付出代價了。

有必要折騰 IPv6 嗎？

當然有，但受篇幅所限，本文就不具體論述 IPv4 和 IPv6 的優(yōu)劣了。網上這類文章很多，大家酌情參考。下面，我簡要介紹一下為什么要轉向 IPv6。

IPv6 數(shù)據包標頭示例

地址空間
標頭字段數(shù)量較少（僅占為 8 個，IPv4 上是 13 個）

處理速度更快：不再需要校驗和，所以路由器不必對每個數(shù)據包進行重新計算。
路由速度更快：包含更多匯總路由和分層路由。（看不懂？沒關系，匯總路由 = 將多個 IP 組合起來，這樣就不需要處理所有地址，而僅僅只要根據地址開頭部分的大致方向前進就行。路由也是如此，畢竟 IPv6 是我們唯一能夠使用的小型、高效主干路由。）
QoS：Traffic Class 和 Flow Label 兩個字段，讓 QoS 更輕松。
自動尋址。允許 IPv6 主機在局域網上無需路由器或 DHCP 服務器即可實現(xiàn)連接。
可以使用 Authentication 標頭和封裝安全負載將 IPsec 添加至 IPv6。

最后，也是最重要的一點：IPv6 地址是免費的，但 IPv4 地址卻要付錢。

設置僅支持 IPv6 的服務器

其實具體設置過程非常簡單。我配置了一臺 Debian 設備并選擇了“IPv6”，接下來第一個“驚喜”就出現(xiàn)了。這臺設備沒能獲得 IPv6 地址。我只得到了一條 /64 地址，也就是 18,446,744,073,709,551,616。但好消息是，我的小型 ARM 服務器可以通過擴展，在所有公共地址上運行我之前工作過的每家公司的網絡基礎設施。

這看似有點浪費，但理解了 IPv6 的工作原理之后，大家會發(fā)現(xiàn)事實并非如此。因為 IPv6 比 IPv4 多得多，所以就算在網絡上設置 1 萬臺主機也沒問題。所以哪怕乍看上去有點浪費，保留所有 IPv6 空間也有其實際意義。所以，用不著考慮有多少地址被發(fā)送給了每臺設備。

重要提示：控制住自己優(yōu)化地址利用率的沖動。在跟經驗豐富的網絡專家交流時，我發(fā)現(xiàn)很多人都容易掉進優(yōu)化地址的坑里。我們都花過很多時間考慮 IPv4 地址塊里還剩多少空間，并圍繞這個問題搞設計。但在 IPv6 中這個問題根本就不存在，/64 前綴就是我們應在接口上配置的最小前綴。

如果非要使用較小的前綴（有人確實嘗試過），比如用 /68 或者 /96，可能會破壞無狀態(tài)地址的自動配置。在心態(tài)上，我們應當將各個站點配置為 /48，這也是地區(qū)互聯(lián)網注冊管理機構在分配 IPv6 時的默認設定。而在設計網絡組織時，則應考慮半字節(jié)邊界——這可不是胡說八道，簡單來講，這就是一種讓 IPv6 更易于閱讀的形式。

假設我們要使用 2402:9400:10::/48，如果希望每臺設備只使用 /64 作為平面網絡結構，則可按如下方式進行劃分：

而 /52 的情況也差不多。

這樣，我們就能一目了然看到自己正在查看哪個子網。

好了，現(xiàn)在設備已經準備就緒，接下來做點常規(guī)服務器設置操作。

問題 1：我沒法通過 SSH 登錄

其實這個問題完全可以預見。我的工作或家庭 ISP 都不支持 IPv6，所以我才需要設置自己的服務器，但現(xiàn)在卻完全不起作用。好吧，我只能附加一個 IPv4 地址，通過 SSH 登錄，再設置 cloudflared 來運行隧道。想必系統(tǒng)會自行處理其中的轉換工作。

但 Cloudflare 顯然沒考慮到這種用法。所以當我刪除 IPv4 地址時，隧道意外崩潰了。默認情況下，cloudflared 實用程序使用的是 IPv4，我們需要單獨編輯 systemd 服務文件以添加：-edge-ip-version 6。完成之后隧道才能正常啟動，我也可以通過 SSH 順利登錄了。

問題 2：沒法使用 GitHub

現(xiàn)在我的小服務器已經開始運行，接下來該做具體設置了。我運行了自己的服務器設置腳本，但立馬就報錯了。它會嘗試訪問 history 的安裝腳本，這是款很棒的 shell 歷史記錄實用程序，我在自己的所有計算設備上都會用它。它嘗試從 GitHub 提取安裝文件，但失敗了?！斑@不對吧，GitHub 難道不支持 IPv6 嗎？”

確實不支持。這簡直讓人心態(tài)爆炸，支撐整個互聯(lián)網的軟件發(fā)布服務居然不能兼容 IPv6……但也難怪，現(xiàn)在微軟的心思全都放在人工智能身上，哪有功夫管你什么 GitHub 和 IPv6。最終，我選擇使用 TransIP GitHub 代理，效果很好?，F(xiàn)在我可以正常訪問 GitHub 了。但隨后 Python 也報錯，顯示 urllib.error.URLError: 。好吧，我選擇放棄。我猜是 Debian 中的 Python 3 版本不兼容 IPv6，但我現(xiàn)在實在沒那個心情做故障排查。

問題 3：無法設置 Datadog

接下來是一些基本操作。我想設置 Datadog 來監(jiān)控這臺服務器的運行，其實關注的指標并不多，只是一些歷史負載數(shù)字。我轉向 Datadog，登錄并開始執(zhí)行設置，但它立刻就崩潰了。我運行 curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh 來實現(xiàn)這個簡單設置，而且人家 S3 已經支持 IPv6 了，這到底是哪出的錯？

     
      curl -v https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh*   Trying [64:ff9b::34d9:8430]:443...*   Trying 52.216.133.245:443...* Immediate connect fail for 52.216.133.245: Network is unreachable*   Trying 54.231.138.48:443...* Immediate connect fail for 54.231.138.48: Network is unreachable*   Trying 52.217.96.222:443...* Immediate connect fail for 52.217.96.222: Network is unreachable*   Trying 52.216.152.62:443...* Immediate connect fail for 52.216.152.62: Network is unreachable*   Trying 54.231.229.16:443...* Immediate connect fail for 54.231.229.16: Network is unreachable*   Trying 52.216.210.200:443...* Immediate connect fail for 52.216.210.200: Network is unreachable*   Trying 52.217.89.94:443...* Immediate connect fail for 52.217.89.94: Network is unreachable*   Trying 52.216.205.173:443...* Immediate connect fail for 52.216.205.173: Network is unreachable

問題不在 S3 或者我的服務器上，因為我可以正常使用 AWS 提供的 S3 存儲桶連接測試。

      
       curl -v  http://s3.dualstack.us-west-2.amazonaws.com/*   Trying [2600:1fa0:40bf:a809:345c:d3f8::]:80...* Connected to s3.dualstack.us-west-2.amazonaws.com (2600:1fa0:40bf:a809:345c:d3f8::) port 80 (#0)> GET / HTTP/1.1> Host: s3.dualstack.us-west-2.amazonaws.com> User-Agent: curl/7.88.1> Accept: */*>< HTTP/1.1 307 Temporary Redirect< x-amz-id-2: r1WAG/NYpaggrPl3Oja4SG1CrcBZ+1RIpYKivAiIhiICtfwiItTgLfm6McPXXJpKWeM848YWvOQ=< x-amz-request-id: BPCVA8T6SZMTB3EF< Date: Tue, 01 Aug 2023 10:31:27 GMT< Location: https://aws.amazon.com/s3/< Server: AmazonS3< Content-Length: 0<* Connection #0 to host s3.dualstack.us-west-2.amazonaws.com left intact

好吧，我打算通過 apt 手動進行設置。

     
      0% [Connecting to apt.datadoghq.com (18.66.192.22)]

他奶奶的……行，Datadog 你滾吧。到這個時候，我終于意識到純使用 IPv6 根本沒有前途。如果不上代理和技術補丁，那原本簡單的幾乎一切組件都會跟我鬧別扭。所以接下來我會盡可能使用 IPv6，但同樣輔以 IPv4。

NAT64

為了從 IPv6 訪問 IPv4 資源，我們需要借助 NAT64 服務。我最終用的是 https://nat64.net/。漂亮！所有問題幾乎立刻消失，我能夠正常訪問各種資源了。我其實有點擔心，畢竟這只是個業(yè)余項目，靠它來接入所有關鍵互聯(lián)網資源到底行不行??？但 IPv6 的兼容性問題實在太多，可行的選項又相當有限，所以我只能祈禱 NAT64 別耍流氓了。

我甚至驚訝于目前能夠選擇的方案居然如此有限。以下就是我能找到的最佳工具列表：

其中大多數(shù)工具似乎已經失效了。Dresel 鏈接無法工作，Trex 在測試中出現(xiàn)了問題，August Internet 徹底消失，大多數(shù) Go5lab 測試設備離線。Tuxis 倒是可以工作，但在 2019 年推出之后似乎就沒升級過?；旧希琄asper Dupont 似乎是互聯(lián)網上唯一愿意繼續(xù)支持 IPv6 的技術人。抱拳了，Kasper～

更直白地講，Kasper 相當于是在用一臂之力支撐整個 IPv6 互聯(lián)網。

Kasper Dupont

到時這里，我對 Kasper 不禁心生好奇，并給他發(fā)郵件提了幾個問題。這位老兄也熱心給出了回復。

我：我發(fā)現(xiàn)公共 NAT64 服務非常有用，你為什么會一直堅持維護這個項目呢？

Kasper：我這么做，主要是想推動 Ipv6 繼續(xù)發(fā)展。有那么幾年，我打算在家里搭建純 IPv6 網絡，并發(fā)現(xiàn) DNS64 加 NAT64 的實際表現(xiàn)相當出色。我想讓更多人也能有機會用上。在發(fā)布第一個 NAT64 網關時，它只是推廣 NAT64 擴展的概念驗證項目。NAT64 就這樣延續(xù)了下來，沒有太多復雜的故事。

幾個月前，我終于在家里用上了原生 IPv6。所以現(xiàn)在，我可以用更類似自己當初的方式幫助目標用戶解決問題。

我：NAT64 幾乎是互聯(lián)網上僅存的少數(shù)此類免費公共服務之一。能不能聊聊你為什么堅持了下來，這服務的運行成本是多少，總之多跟我說說具體情況吧。

Kasper：這是款個人產品，所以我在不同的地方一共用到七家虛擬機托管服務商。有些是從 Hetzner 購買的，價格是每月 4.51 歐元：https://hetzner.cloud/?ref=fFum6YUDlpJz 其他虛擬機要貴一點，但貴得不多。

在這些虛擬機中，有 4 個用于 NAT64 服務，其他則用于別的 IPv6 過渡相關服務。比如我自己也在其中一個虛擬機上運行這項服務：http://v4-frontend.netiter.com/

我希望以后能跟托管商達成協(xié)議，提高服務容量并把它變成能賺錢的業(yè)務，這樣我就可以全職從事 IPv6 相關工作了。但目前我僅僅是拿出點個人時間鼓搗。我的目標是讓純 IPv4 內容提供商以傳輸帶寬成本的方式支付這部分費用。

我：有沒有愿意分享的其他技術細節(jié)呢？

Kasper：當然可以，只是這些技術細節(jié)可能有點復雜。

我覺得自己這項服務跟其他服務的主要區(qū)別，在于我的每個 DNS64 服務器都會自動根據所有網關的健康檢查通過 NAT64 前綴進行更新。也就是說，任何單一 NAT64 網關的中斷，基本都不會對用戶體驗造成影響。這對維護也有幫助。在我看來，這可能是 NAT64 服務在同類公共服務中獲得認可的核心原因。

NAT64 服務的代碼也完全由我自己開發(fā)而成，目前作為 Linux 上用戶模式的守護進程。我正在考慮把大部分性能關鍵部分移植成內核模塊。

我的網站

好了，到這里我已經介紹完畢、網站也開始運行了。為了通過 IPv6 拉取 docker 容器，我們需要在鏡像名稱前添加 registry.ipv6.docker.com/library/ 。例如：image: mysql:8.0 會變成 image: registry.ipv6.docker.com/library/mysql:8.0

Docker 會警告說此設置尚未達到生產就緒狀態(tài)。我不太確定 Docker 想提醒什么，畢竟如果它停止運行，拉取操作照常執(zhí)行也就可以了吧？

完成之后，我把自己這個網站設置為 AAA DNS 記錄，并允許 Cloudflare 進行代理。也就是說，它們會處理 IPv6 的廣告并將流量引向這里。我還做了另一項修改：之前我使用的是 Caddy Web 服務器，但因為現(xiàn)在大部分流量都轉移到了 Cloudflare 這邊來，所以我決定改用 Nginx。畢竟當主要流量都來自 Cloudflare，那自然得相應調整 SSL 的工作方式。

現(xiàn)在，我已經把 Cloudflare 的原始證書硬加載到了 Nginx 當中，同時設置了經過身份驗證的源拉取，這樣就可以確定所有流量均通過 Cloudflare 運行。該證書的簽名有效期為 15 年，所以我可以放心把它保留在自己的 secret 管理系統(tǒng)當中、不再分心打理。好了，現(xiàn)在我的網站已經重新上線并正常運行。是的，你眼前看到的這篇內容，就是系統(tǒng)能夠順暢工作的最好證明。

尚未解決的問題

我的容器仍無法與 IPv4 資源通信，就算位于具有 IPv6 網橋的 IPv6 網絡上也不行。DNS64 解析能正常工作，而且我已經把 fixed-cidr-v6 添加到了 Docker 當中。我可以跟 IPv6 資源正常通信，但 NAT64 轉換過程卻不起作用。之后我會繼續(xù)研究可行的辦法。

有些朋友可能想 ping 一下試試，但我在添加 NAT 時用到了 ip6tables。

SMTP 服務器問題。我還沒找到擁有 AAAA 記錄的商用 SMTP 服務。Mailgun 和 SES 都不行，我試過的其他一些小服務也宣告失敗。即使 Fastmail 也幫不上忙。

為什么不繼續(xù)使用 IPv4？

這里咱們先不扯地址不夠用之類的閑話。如果能早一點嘗試推廣 IPv6，那我們的網絡基礎設施建設方式可能將完全不同。企業(yè)之所以經常用到負載均衡器和隧道等技術，并不是真的有什么硬性功能需求，而是希望在私有 IP 范圍和公共 IP 地址之間做出某種邏輯劃分，并將其保留在 DNS A 記錄當中。

如果具體把負載均衡器拆開來看，它其實只負責兩項工作。首先將傳入的數(shù)據包分發(fā)到后端服務器上，之后檢查這些服務器的運行狀態(tài)并將不健康的服務器從輪換中剔除。當然，現(xiàn)在很多人也在用負載均衡器處理 SSL 終止和指標等事務，但這些并不是負載均衡器設計上的必要功能。負載均衡有多種實現(xiàn)方式，最常見的包括：

連接請求輪詢。
不同服務器的加權輪詢。
最少連接原則，即連接數(shù)最少的服務器會收到更多請求。
加權最少連接，跟上一條類似，但也可以設置更多傾向性。

大家應該注意到了，跟公共 IP 地址相比，私有 IP 地址完全用不上這些功能。從計算角度看，將主機配置為僅接受某一個來源（負載均衡器）的流量只是更簡單也相對更便宜。但出于這個目標，我們被迫在基礎設施層面做出大量設計，例如 VPC、NAT 網關、公共子網和私有子網等等，其實這些原本都沒必要、至少不用像現(xiàn)在這么重要。

更諷刺的是，IP 白名單目前是種并不完善的安全實踐。它最大的問題就是浪費時間，因為我們使用的都是云服務商所擁有的 IP 地址。但面向未來，IP 的名單的存在仍然意義重大，因為企業(yè)會隨需求增加而自行購買 /44，包括從美國互聯(lián)網號碼注冊機構（ARIN）、Réseaux IP Européens 歐洲網絡協(xié)調中心（RIPE）或者亞太網絡信息中心（APNIC）購買一組 IP。

這樣，我們就永遠不需要擔心“谷歌會不會再多買點 IP 地址”或者“我得關注 GitHub 的支持頁面，確保他們不會添加更多 IP 地址”。未來我們將擁有自己的 IP 地址塊，在使用期限之內隨意用于整個業(yè)務體系。容器系統(tǒng)不需要在每個主機上分配內部 IP 地址，因為有公共 IP 地址塊可供使用，需要時還能通過標準公共 DNS 輕松發(fā)布通告。

當然，我不是說專用網絡不好。我的意思是，我們采用的很多網絡設計并非出于硬性需求，反而是被“綁架”的設計產物。我猜測未來的應用程序會更多對接開放互聯(lián)網，而不再完全依賴于私有 VPC 的安全保障。考慮到安全漏洞的基本原理，這樣的設計可能更有益于整體安全。

所以，即使大家根本不關心成本和可用性問題，那讓組織更多掌握網絡功能的所有權和控制權，也必將帶來可以量化的巨大價值。

這一切，會好起來嗎？

總之，目前的情況實在糟糕。我們要么向云服務商付更多的錢，要么坐視自己的網絡服務崩潰。希望那些不想付錢的朋友們能繼續(xù)推動 IPv6 的普及，但遺憾的是我們居然花了這么多年才達到如今的水平。所有這些問題本來可以逐步解決，但在掌握資源的團隊做出實際行動之前，很多朋友心里恐怕還是有個大大的問號。

我真心希望最終結果能更好一些，至少應該給那些希望永久掌握自己 IP 范圍的小公司一點機會。而且隨著 IPv6 逐步成為主流，也希望它的使用門檻能變得更低一些。反正目前的現(xiàn)狀就是兩個字：糟糕，出奇的糟糕。

如果你經營著一家小公司，又不想額外花錢使用 IP 地址，那當下唯一的辦法就是多留點時間：各位將有無數(shù)問題需要解決。

期待看到大家的意見 / 更正 / 駁斥~

最后，順手給大家推薦一個我們正在做的Chrome插件：Youtube中文配音，助你更高效的學習前沿知識！

原文鏈接：https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/

   ------
  

我們創(chuàng)建了一個高質量的技術交流群，與優(yōu)秀的人在一起，自己也會優(yōu)秀起來，趕緊點擊加群，享受一起成長的快樂。另外，如果你最近想跳槽的話，年前我花了2周時間收集了一波大廠面經，節(jié)后準備跳槽的可以點擊這里領取！

重要的歷史時刻來臨：IPv4 開始收費了！

推薦閱讀

重要的歷史時刻來臨：IPv4 開始收費了！

推薦閱讀

重要的歷史時刻來臨：IPv4 開始收費了！