WireGuard 経由のみの HTTPS サービス向け loopback 上の Dante SOCKS

専用の SOCKS リスナーを loopback にバインドし、TCP の宛先を一つだけ許可します。Dante の送信元、カーネルルート、DNS、トンネル喪失時の方針は分けて扱います。

この手順書は、VPN サーバーやインターネットにプロキシポートを公開せずに、プロキシ対応アプリケーションへ既存の WireGuard 経路へのアクセスを与えます。SOCKS デーモンがアプリケーションのインターフェースを提供し、WireGuard がすでに承認済みの IP 経路を提供し、どちらも利用者の認証を代行しません。以下の各手順は確認できる結果を生み、それぞれにロールバックがあります。インスタンスを停止する、ルールを削除する、アプリケーションのプロキシ設定を外す、のいずれかです。ここではホストのデフォルトルートを一切変更しません。

この例は、Dante 1.4.x が信頼できる Linux ワークステーション上に専用の管理対象インスタンスとして導入され、パッケージ提供のサービスアカウントとログ設定がそのまま残されていることを前提とします。ワークステーションは 10.77.0.2 を WireGuard インターフェース上に持ち、そのトンネル経由で 10.60.0.20:443 に到達し、サービスの正式名は app.corp.example です。

手順 1: リスナーを loopback だけにバインドする

ネットワーク、メソッド、ルールの各セクションをインスタンスの有効な設定に置き、例のアドレスを置き換えます。サーバー設定はすべてルールブロックより前に置きます:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

これは断片であり、パッケージのユーザー設定やログ設定の代替ではありません。未使用のローカルポートを選び、この専用インスタンスに他のリスナー、より広い通過ルール、契約を変える上流チェーン項目がないことを確認します。以前の設定が socks pass を宛先制約なしで残している場合は、何かをテストする前に削除してください。

この手順のロールバックはインスタンスの停止です。設定ファイルは、元に戻す間ディスクに残しておけます。

手順 2: ルールは一つではなく二つ書く

Dante の 設定リファレンス は、二種類のルールに別の役割を与えています。クライアントルールは loopback リスナーへの接続を許可し、その宛先はリスナー自身のアドレスです。SOCKS ルールは、要求された先の接続を承認済みのホストとポートへ許可します。一致しない要求は既定で遮断されるため、ルールの欠落は壊れたルートとまったく同じに見えます。

この設定が意図的に行わないことに注意してください。SOCKS パスワードを要求しません。これは信頼できるローカルホストには適しますが、利用者の認証ではありません。そのマシン上の他のプロセスも loopback を使えます。リモートアプリケーション自身の認証はそのまま残し、この認証なしの形を信頼できないローカル利用者や LAN 向けリスナーに再利用しないでください。

手順 3: 正しい送信元からルートを検証する

external は送信元アドレスを選ぶだけで、WireGuard ルートを導入しません。例の送信元と宛先に対する読み取り専用の照会:

ip -4 route get 10.60.0.20 from 10.77.0.2

これは Dante の実際のネットワーク名前空間で実行し、たまたま開いているシェルで実行しないでください。ルート、WireGuard ピアの選択、遠端側の許可、戻り経路のすべてがその送信元アドレスに合っていなければなりません。照会の成功は必要ですが十分ではなく、遠端が要求を受け入れるかどうかは何も語りません。

照会を通すためにデフォルトルートを足したくなる誘惑に抗ってください。プロキシポートはこのワークステーションにしか存在せず、それを作るためにホストのデフォルトルートを変えると設計全体が反転します。

手順 4: 想定された識別情報でテストする

所有者が導入済みの設定を検証し、サービスマネージャー経由でインスタンスを起動した後の例示的な要求は次のとおりです:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

次の設定では socks5h、Dante が宛先解決を行いますが、Dante はこのワークステーション上で動くため、この設定だけでは DNS をトンネルの遠端へ送りません。Dante が使う承認済みリゾルバーが、その名前に対して許可されたアドレスを返す必要があります。空の no-proxy リストは、継承された除外設定が SOCKS を静かに迂回するのを防ぎます。

テストでは HTTPS のホスト名と証明書の検証を保ち、そのうえで実際のリスナーを調べ、契約の両半分を確認します。許可された要求は成功し、除外された宛先は失敗することです。未対応の転送コマンドが拒否されたままであることも確認してください。この断片が許可するのは TCP 上の SOCKS CONNECT コマンドだけで、一般的な UDP や端末全体のトンネルに類するものは許可しません。

手順 5: トンネルが落ちたときの挙動を決める

これを本番と呼ぶ前に、トンネル喪失とインスタンス再起動をテストしてください。WireGuard の後に Dante を起動するスーパーバイザーは、フェイルクローズのルーティングもフェイルクローズの DNS も作りません。どちらもネットワークの所有者を通じて強制する必要があります。トンネルが落ちている間にアプリケーションがどう振る舞うかを見てください。きれいなエラーは良い結果で、公開リゾルバーへの静かなフォールバックはそうではありません。

バインドされたトンネルアドレスが変わったら更新を調整してください。external はそれに固定されているからです。この仕組みが不要になったら、このインスタンスとアプリケーションのプロキシ設定を一緒に退役させ、WireGuard 経路は所有者に委ねてください。

関連記事