HN 日本語サマリー

← 一覧へ戻る
プログラミング

誰もが独自のネットワークスタックを構築すべき

Everyone Should Build Their Own Network Stack (blog.lyc8503.net)

54 pointsby uneven943437 コメント

要約

この記事は、Linuxカーネルのネットワークスタックに脆弱性が発見された場合、インターネット全体が危機に瀕するという中央集権的なリスクを指摘しています。筆者は、分散ネットワークでは、各ユーザーが独自のネットワークスタックを実装することで、単一の欠陥がネットワーク全体に影響を与えるリスクを軽減できると主張しています。筆者は、自身のカスタムネットワークスタック「DNet」をDN42ネットワーク上で構築・運用した経験を共有しています。

全文翻訳

この記事は、現在実験的な機械翻訳であり、誤りが含まれている可能性があります。不明な点がある場合は、元の中国語版を参照してください。翻訳の改善に継続的に取り組んでいます。 これは「ISP@Home」シリーズのサイドエントリーであり、公式にミームの領域に入っています。一部の概念や背景が十分に説明されていないと感じる場合は、シリーズの前の投稿を参照することをお勧めします。 前置き 次のようなシナリオを想像してみてください。ある日、謎の人物(あるいはLLM)が、主流のLinuxカーネルのネットワークスタックにRCE脆弱性を発見しました。Linuxは広く使用されているため、この単一の欠陥は瞬時にインターネット全体を崩壊の危機に瀕させるでしょう—すべてのネットワークホストが大規模なリスクにさらされます。 それはあまりにも中央集権的すぎます。 したがって、真に分散化されたネットワークでは、誰もが独自のネットワークスタックを実装し、それを使用してインターネットにアクセスすべきだと私は信じています。そうすれば、たとえ1つの実装にバグや脆弱性があったとしても、ネットワーク全体をダウンさせることはありません。 さて、もう真顔を保てません。真実は、私がNJUでコンピュータネットワーキングを学んでいた頃、遊びで独自のネットワークスタックを書きたいという衝動に突然駆られたことです。DN42に十分なカオスが見つからなかったので、レベルを上げて、カスタムスタックをDN42にデプロイすることにしました—そしておそらくいつかはIANAにも—実際のサービスを提供します。 DNet 当時、このプロジェクト(DNet)についていくつかブログ記事を書きましたが、長くは続けませんでした:https://github.com/lyc8503/DNet-core 当時、それは多かれ少なかれ以下のことを達成しました: Linux上にTAPデバイスを作成し、イーサネットフレームを送受信する イーサネットフレームを解析し、ARPルックアップと応答を処理する IPv4パケットを解析し、ICMPエコー要求に応答する UDPパケットを送受信する 最近、4年間の放棄の後、プロジェクトを再開し、いくつかのバグを修正し、私のDN42ドメイン42420167.xyzの権威DNSとして機能する、かろうじて機能するDNSサーバーをまとめました。 今、インターネットに接続されたどのマシンからでもdig TXT sgp1.dn42.42420167.xyzを実行すると、私の手作りのネットワークスタックから直接提供されるDNS応答が得られます: ``` 1234567891011121314151617181920212223242526# dig TXT sgp1.dn42.42420167.xyz ; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> TXT sgp1.dn42.42420167.xyz ;; global options: +cmd ;; ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21546 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; ;; QUESTION SECTION: ;sgp1.dn42.42420167.xyz. IN TXT ;; ;; ANSWER SECTION: sgp1.dn42.42420167.xyz. 20 IN TXT "IPv6 LLA: fe80::167" sgp1.dn42.42420167.xyz. 20 IN TXT "PubKey: 8BKrEUrqba9mCzYHqWD2uTNtvrcYcKAls3vBQrY6dxE=" sgp1.dn42.42420167.xyz. 20 IN TXT "MP-BGP: enabled" sgp1.dn42.42420167.xyz. 20 IN TXT "Extended Next Hop: enabled" sgp1.dn42.42420167.xyz. 20 IN TXT "Looking Glass: http://sgp1.dn42.42420167.xyz:5000/" sgp1.dn42.42420167.xyz. 20 IN TXT "ASN: 4242420167" sgp1.dn42.42420167.xyz. 20 IN TXT "Endpoint: sgp1.dn42.42420167.xyz:2xxxx (xxxx is the last 4 digits of your ASN)" ;; ;; Query time: 11 msec ;; SERVER: 223.5.5.5#53(223.5.5.5) (UDP) ;; WHEN: Sat Jun 13 22:22:39 CST 2026 ;; MSG SIZE rcvd: 397 ``` そして、DN42内であれば、IP 172.20.42.224に直接何かを送信できます。例えば: ``` ping 172.20.42.224 ``` 私の最後のブログ記事では、すべてのVPSインスタンスをNixOSに移行し、ピュアなバイブコーディングで構築しました。しかし、実際にはNixを知らなかったため、すぐに維持不能な混乱状態になり、デプロイ中にランダムに壊れるようになりました。 一瞬の躊躇の後、すべてを消去してDebianに戻ることにしました。今回は、pyinfra(Pythonベースのインフラストラクチャツール)を使用しています:lyc8503/infra。 Debian上では、Docker Compose(こちらを参照)ですべてのDN42サービスを管理しています。これにより、Dockerのネットワーク名前空間を使用してサービスを分離できます—各コンテナは「クリーンな」環境で起動し、繰り返しデプロイによる設定ドリフトの通常の混乱を回避できます。 後記 さて、これで終わりです—この記事は始まったときと同じくらい唐突に終わります。今回はコードの詳細な分析はなく、最新のトロルプロジェクトの簡単な紹介です。 最近、DN42の参加者が少なすぎると感じています。ネットワークのトラフィックは主にICMPとBGPであり、実際のアプリケーションは実行されておらず、新しいいたずらの余地はあまりありません。後で新しいインスピレーションが得られない限り、DN42シリーズはおそらくここで終了します~ この記事はCC BY-NC-SA 4.0ライセンスの下でライセンスされています。 著者:lyc8503、記事リンク:https://blog.lyc8503.net/en/post/dn42-2-dnet/ この記事が役に立ったり面白かったりした場合は、コーヒーを買うことを検討してください¬_¬ 以下に英語で自由にコメントしてください o/