IPv6のみの接続、IPv4のサービス：SOCKSプロキシに橋渡しさせよう

宛先のアドレスファミリーのアドレスがなくても、経路上の何かが中継を引き受けてくれれば宛先に到達できます。アプリケーションはプロキシに接続し、プロキシは宛先への二つ目の接続を開きます。これは独立したアドレスファミリーを持つ二つのソケットであり、どちらのプロトコルもそれらが一致することを要求しません。これはアプリケーション層の中継であり、ネイティブなIPv4経路ではなく、この区別が何が機能し何が機能しないかを決めます。両者を混同すると、実際にはプロキシしかないのに、ノートPCがIPv4接続性を持つと説明されることになります。

二つのソケット、二つのアドレスファミリー

SOCKS5の要求は宛先を三つの形式のいずれかで指定します。リテラルのv4アドレス、リテラルのv6アドレス、またはプロキシに解決させる名前です。要求が示すのはプロキシがどこへ接続すべきかであり、クライアントからプロキシへの接続がどう見えるかではありません。

これらのアドレス種別を、一つのメッセージ内の三つの独立した選択として読んでください。IPv6で到達できるプロキシは、動作するIPv4の出口があり、ポリシーが要求を許可していれば、IPv4宛先のソケットを開けます。SOCKS5仕様は、クライアントのトランスポートに一切触れずにこれらを定義しています。

制御されたSSHの例

使用を許可されたSSHホストで、IPv6で応答し、それ自体がv4にしか存在しないHTTPSサービスに到達できるものを用意します。OpenSSHの動的転送は、ログインセッションがv6を経由する間に、ローカルのSOCKSリスナーをあなたのマシンに置きます。

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

上記のホストとアカウントは例であり、ループバックバインドはリスナーをこのコンピューターに留めます。オフィスが認証なしのプロキシを共有できるように、ワイルドカードバインドに置き換えないでください。ExitOnForwardFailure=yes は、転送が失敗したときにセッションを終了させ、バックグラウンドで無言のコマンドを走らせたままにしないために存在します。

セッションが動作しているとき、要求は次のようになります。

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

ループバック接続はIPv4のインターネット経路ではありません。あなたのマシンから出るのはv6経由のログインセッションであり、宛先のソケットを開くのは向こう側です。socks5h の形式は名前解決もその側に委ねるので、クライアント自身にIPv4のリゾルバ経路がない場合に重要になります。

宛先が実際に見るもの

宛先が見るのは中継の出口アドレスです。あなたのノートPCに属するアドレスはそこに現れません。そのサービス側の送信元許可リストには中継を記載しなければなりません。そのログもトラフィックを中継に帰属させます。監査の前にこれを変更記録に書いてください。クライアントのアドレスを中心に作られた許可リストは最初の要求で失敗するからです。

中継は、会話の両半分が見える場所でもあり、診断時には有用な性質で、ポリシーなしで共有されると負債になります。

これはDNS64でもNAT64でもありません

DNS64はv4の宛先を代替する合成レコードで応答し、NAT64は設定された経路に沿ってパケットを書き換えます。どちらもここで起きていること、つまり一方のトランスポートの会話が終わり別の会話が始まり、合成されたアドレスでは結果を説明できないことを記述していません。したがって、要求が成功しても、あなたのプロバイダーがどの変換サービスを運用しているかは何もわかりません。またプロキシは自身の出口で通常のNATを実行している可能性があります。

どちらの仕組みも同じネットワークに存在しうるので、最も近く聞こえるものではなく、実際に検証したものを説明してください。

約束する前に範囲を知る

OpenSSHの動的転送はTCP接続を運び、任意のIPトラフィックは運ばないため、UDP、ICMP、およびプロキシを無視するあらゆるプロトコルには、別のサポートされた設計が必要です。SSHホスト鍵の検証、サーバーの転送制限、HTTPS証明書の検証を維持してください。プロキシは追加の信頼された参加者であり、身元確認を弱める理由ではありません。目的がVPNの外側のトランスポートをプロキシ経由で運ぶことなら、どのSOCKSリスナーでも中継できると仮定するのではなく、両端がそのトランスポートをサポートしていることを検証してください。

これらのどれもクライアントをデュアルスタックにするものではなく、その必要もありません。一つのアプリケーションが一つの中継を通じて一つのサービスに到達するようにするだけで、これはより小さな主張であり、はるかに検証しやすいものです。