- ネットワークインフラはスイッチ、ブリッジ、ルーター、ロードバランサー、ファイアウォールなどで構成される
- OSはパケットを分類し、キューに配置し、ファイアウォールルールを適用するなど、ネットワーク通信を制御する
- では、存在しないトランスポート層プロトコルを使うとどうなるのか？
- OSは許可するのか？ パケットは実際に配送されるのか？ ファイアウォールに遮断されるのか？
- 実際に実験を行って確認した
インターネットプロトコルの概要
- インターネットは複数の階層のプロトコルがデータを伝送する仕組みで動作している
- アプリケーションがリクエストを送ると、OSがそれを複数のネットワーク層ヘッダーで包んで送信する
- トランスポート層(Transport Layer): TCP(6)、UDP(17)などのプロトコルが位置する
- IPヘッダーの
Protocolフィールドを変更して未使用の番号を入れると何が起こるのか？
実験 #1: 自分のPCで直接テスト
実験方法
- HDP(偽のプロトコル)を定義: 既存のプロトコルとはまったく異なる新しいトランスポート層プロトコルを設計
- サーバーとクライアントを実装: パケットを送受信するプログラムを開発
- ループバック(loopback)テスト: OSがパケットを内部的に処理する方式を観察
実行過程
$ sudo cargo run --bin server # サーバー起動
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1 # クライアント起動
結果
- OSがHDPパケットを正常に処理し、ループバックインターフェース経由で再び受信された
- IPプロトコル番号を変更して追加テストを実施
- 1 (ICMP), 2 (IGMP), 6 (TCP) → サーバーでは検出されない
- 50, 51 (IPSec関連プロトコル) → クライアント側で送信自体が遮断される
- 256 (IPプロトコル番号の範囲超過) →
socket()呼び出し段階でエラーが発生
原因分析
- OSが特定のプロトコル番号をシステム的に予約して遮断する場合がある
- Darwin(BSDベースのmacOS)では
socket()呼び出し時にprotocol=0を設定すると一部のパケットが自動的にフィルタリングされる
- IPSec関連プロトコルはセキュリティ上の理由で遮断される可能性が高い
- IPv4プロトコル番号は8ビットなので、0〜255のみ有効
実験 #2: インターネットでパケット送信
実験計画
- DigitalOcean VPSを設定: ドイツ・フランクフルトにあるクラウドサーバーに実験環境を構築
- HDPパケット送信: 自分のPC(サウジアラビア)からDigitalOceanサーバーへパケットを送信
- ネットワーク機器の反応を分析: パケットが到達するか、ファイアウォールに遮断されるかを確認
予想結果
- HDPパケットが正常に配送されるか、あるいは一部のISPまたはDigitalOceanのファイアウォールに遮断される可能性がある
実際の結果
- 最初のパケットだけが配送され、その後のパケットは遮断された
tcpdumpで確認した結果:
- 自分のPCからはパケットが正常に送信されている
- DigitalOceanサーバーでは最初のパケットだけが検出された
- 以降のパケットはどこかで遮断された (NAT、ファイアウォール、ISPなど)
原因分析
- DigitalOceanは非標準IPプロトコルをサポートしていない
- クラウド事業者のファイアウォールポリシーが主因である可能性が高い
- なぜ最初のパケットだけ到達したのかは不明
AWSで再実験
- AWSで2台のインスタンスを使って実験をやり直した
- 同じデータセンター内ではHDPパケットは正常に送受信された
- しかしインターネット経由で送信すると、DigitalOceanと同様に最初のパケットだけが到達する問題が発生
主な論点
- NAT(Network Address Translation): TCP/UDPポートベースで動作するため、HDPのような新規プロトコルを扱う方法がない
- ファイアウォール/ネットワークフィルタリング: ほとんどのISPとクラウド事業者は未承認のIPプロトコルを遮断する
- ネットワーク機器の最適化問題: 一部のネットワーク機器は非標準パケットを無条件で破棄する可能性がある
結論: TCPとUDPを使うのが最善
- OSごとにネットワークスタック実装が異なる
- Linux、macOS、Windowsでの
socket()の動作方式はそれぞれ異なる
- ファイアウォールやNAT機器が非標準プロトコルを遮断する
- 個人ネットワークでは動作しても、インターネット上ではほぼ不可能
- 性能改善の効果はない
- UDPベースで実装されたQUICなど、すでに検証済みの代替手段が存在する
- TCP/UDPを使おう
- 標準プロトコルを使えば、ポートベースのNAT、ファイアウォール、ルーティングなどが自動的にサポートされる
追加資料
5件のコメント
https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/を読んでみるのも参考になると思います。昔の『StarCraft』でHamachiを使ってマルチプレイしていたときにIPXがあって、その頃はこれが何なのか本当に気になっていた記憶があります。
考えてみると、NATがすべてを妨げてしまいますね……。IPv6が完全に定着してNATがなくなれば（そんなことはなさそうですが）、自分で作ったプロトコルで通信することも可能になるかもしれません。
おお、良い試みですね…
ネットワークの根幹を揺るがす試みは良かったものの、この世のすべてのネットワーク機器は TCP/UDT に特化した機器しかないので…
ネットワーク機器が金型で大量生産されるものだと知らないうちは…可能そうに見えるのですが…それを知ってしまうと、自分が成功して自分のプロトコルをみんなに使わせる、というのでなければ無理なのだと分かるんですよね…
Hacker Newsの意見