Erebus: ルートレスなユーザースペースVPNプロキシ
Erebusは制限された環境でのルートレスなVPN接続を可能にします
Erebusは、ルート権限を必要としたりホストのネットワークスタックを変更したりすることなく、ユーザーがVPN接続を確立できるようにするユーザースペースVPNプロキシです。OpenVPNプロトコルとTCP/IPスタックを完全に単一のプロセス内で実装することで、Erebusはカーネルの tun/tap インターフェースやルーティングテーブルの変更の必要性を回避します。これにより、CIランナー、サンドボックス、権限のないコンテナなど、sudo アクセスが利用できない環境に最適です。
アーキテクチャ: VPNスタックをユーザースペースへ移動する
Erebusは、従来のカーネルベースのルーティングとTCP処理を独自の内部ロジックに置き換えます。このツールが必要とする唯一のシステム権限は、標準的なネットワークソケットを開く能力です。
データフロー
リクエストが行われると、データは以下のパスを辿ります:
- Local HTTP Client: クライアントアプリケーションがローカルのErebusプロキシを指します。
- HTTP Proxy: Erebusはリクエストを受け取り、中継します。
- User-Space TCP/IP Stack: プロセスはIPv4、TCP、およびICMPパケットを手動で構築および解析します。
- Encryption: パケットはOpenVPNの静的キー(wire format v1)プロトコルを使用して暗号化され、HMACとパケットIDが適用されます。
- Transport: 暗号化されたデータは、UDPデータグラムまたはTCPフレームとしてOpenVPNサーバーに送信されます。
主な機能と能力
ルートレス動作
Erebusは sudo 権限を必要とせず、セットアップスクリプトも不要で、ホストのインターフェース、ルート、またはDNS設定にも触れません。標準的なユーザープロセスとして開始および停止できます。
オプトイン形式のトラフィックルーティング
接続性はシステム全体ではなく、明示的です。ユーザーは、VPN経由でトラフィックをルーティングするために、特定のアプリケーションをローカルプロキシに向ける必要があります。
- Outbound: ローカルのHTTP/1.xプロキシがVPN上のリソースへのリクエストを転送します。
- Inbound: ポートフォワードにより、ローカルサービスをVPNピアに双方向で公開します。
プロトコルサポート
- OpenVPN: UDPまたはTCP経由の静的キーモード(事前共有鍵)をサポートします。CBC暗号(AES, ARIA, Camellia)および各種HMACダイジェストをサポートします。
- IPsec: strongSwanと相互運用可能なIKEv2コントロールプレーンとESPデータプレーンを含みます。ルートレスプロセスは生のESPを送信できないため、すべてのトラフィックは事前共有鍵を使用したUDPカプセル化(NAT-T)が行われます。
使用方法とインストール
ErebusはCommon Lisp (SBCL) で書かれており、Debian/Ubuntu派生版用のDebianパッケージとして配布されています。
クイックスタート設定
Ausbound UDPプロキシの最小構成は、INIファイルで定義されます:
[erebus]
client-ip = 10.8.0.2
[openvpn-server]
proto = udp
host = vpn.example.com
port = 1194
secret = /etc/erebus/static.key
cipher = AES-256-CBC
auth = SHA256
[proxy-out]
address = 127.0.0.1
port = 11023
プロキシを使用するには、コマンドライン経由でトラフィックをルーティングできます:
http_proxy=http://127.0.0.1:11023 curl http://10.8.0.1/
パフォーマンスと制限事項
Erebusは、パフォーマンスよりも正確性と明快さを優先する初期段階の実験的なプロジェクトです。
ユースケースの適合性
| Ideal For | Not Ideal For |
|---|---|
| 権限のないコンテナ内の内部HTTPサービス | システム全体のVPNルーティング |
| プライベートエンドポイントを必要とするCIジョブ | 大量データの転送 |
| サンドボックス化された、またはマルチテナントのホスト | TLSモードのOpenVPN (証明書) |
| 単一のローカルポートをVPNピアに公開する | HTTPS CONNECT トンネリングまたはSOCKS |
パフォーマンスのトレードオフ
実装がデータを一度に1つずつ送信し、次の送信の前に確認を待機するため、大きなダウンロードは標準的なプロキシよりも大幅に遅くなります。この設計上の選択は、コードの簡潔さと相互運用性を確保するためのものです。