iOS Traceroute 実装技術サマリー
iOS Traceroute 実装技術サマリー
本書は、ルート権限(Root Privileges)を持たないiOS環境において、標準規格に準拠した堅牢なTracerouteを実現するために実装された技術的な課題と解決策をまとめたものです。
課題 (Challenge)
iOSの厳格なサンドボックス制限下でのTraceroute実装には、以下の困難が伴います。
解決策 (Solutions)
以下の4層のアーキテクチャを実装することで、これらの課題を解決しました。
1. Persistent Socket(ソケットの永続化によるフロー安定化)
問題: プローブ(TTL試行)ごとに新しいソケットを作成すると、送信元ポート(Identifier)が毎回変わってしまいます。これはファイアウォールやNATから見ると「ポートスキャン」や「無関係な通信」に見え、パケットが破棄される原因となります。 解決策:
2. Explicit Binding & ID Synchronization(チェックサム整合性の確保)
問題: アプリ側でランダムなIDを設定しても、sendto 時にカーネルが自身の割り当てたポート番号でIDを上書きします。この際、チェックサムの再計算が正しく行われない(あるいはアプリ側が古いIDで計算してしまう)ケースがあり、不正なチェックサムを持つパケットとしてルーターに破棄されます。 解決策:
3. Sequence Scanning(ロバストなパケット解析)
問題: ルーターから返される Time Exceeded には、我々が送ったパケットのコピーが含まれています。しかし、ルーターがIPヘッダー長(IHL)を変えたりIPオプションを追加したりすると、我々のシーケンス番号が格納されている位置(オフセット)がずれます。固定位置(例: 48バイト目)のチェックでは失敗します。 解決策:
4. Relaxed Validation & Compatibility(互換性の向上)
最終アルゴリズム
- IP_TTL を設定。
- ICMP Echo Request を構築 (ID = SessionID, Seq = N)。
- sendto() 送信。
- recvfrom() 受信待機。
- ペイロード内を スキャン して Seq = N を検索。
- 発見した場合: Hopとして記録。
この実装により、標準的なmacOSの traceroute コマンドと区別がつかないレベルの結果が得られるようになりました。
← Go home