OpenVPNクライアント同士を、プールを開かずにSSHでつなぐ

client-to-client は切ったままにし、カーネルに1本のフローを転送させ、プールの残りは閉じておきます。サーバー側2ルールと宛先側1ルールです。

一方のクライアントがもう一方のクライアントの SSH サービスに到達する必要があり、プールの残りは今と同じ隔離状態を保つべきです。魅力的なスイッチは client-to-client で、これは全員のピア間アクセスを一括で有効にし、判断をカーネルではなく OpenVPN に渡します。より狭い答えはそのスイッチを切ったままにし、サーバー自身のルーティングとファイアウォールにちょうど一本のフローを運ばせます。

仕組みはルールの文言より重要です。二つの方法はパケットを別の場所に置くからです。どちらを選んだかを知っていれば、何もしていないように見えるルールと、それなしで接続するピアの両方を説明できます。

client-to-client がパケットをどこへ移すか

client-to-client が有効なとき、サーバーはピアのパケットをトンネルデバイスから送り返さず内部で中継するため、パケットはカーネルの転送経路に決して到達しません。これは便利であり、ファイアウォールが本来監視すべきフローを決して見ないことも意味します。オプションを切ったままにすると、サーバーはパケットを同じインターフェースから外へ再びルーティングし、netfilter の前に置きます。同じインターフェースで入り、同じで出て、FORWARD チェーンが発言権を持ちます。

交換条件は明快で、ポリシーの一点を得る代わりに、近道が代行していたルーティングと転送を引き受けます。その作業は一本のフローには小さく、例外を足すたびに増えます。例外を今数えてください。ピア間ポリシーが実際に住んでいるのはルールセットだからです。

ピアのパケットが実際にたどる経路

Linux Community の OpenVPN 2.6 サービス、DCO ではなくユーザー空間の TUN 処理、サブネットトポロジー、tun0、そしてクライアント A が 10.44.0.21、クライアント B が 10.44.0.37 にいる 10.44.0.0/24 のプールを想定します。サブネットトポロジーでは A が受け取ったアドレスとネットマスクがすでにプールを覆うため、A は追加でプッシュされた経路なしにトンネルデバイスへパケットを送ります。A の実効経路を仮定せず確認してください。

サーバーではパケットが B 宛てに届きますが、これはローカルアドレスではないため転送されます。IPv4 転送が有効でなければそもそも起こらず、経路検索はパケットを tun0 から外へ再度送る必要があります。したがってファイアウォールは両側が同じインターフェースの転送フローを見ます。これがほとんどのルールセットが見落とす点です。ここでは送信元変換は不要で、A のアドレスをそのまま保つことが B 自身の送信元ベースのルールを適用させます。

サーバー側の二ルールを、この順で

許可全体は、転送、ペアの例外、トンネルペアの既定ドロップという三つのルールが担います。許可ルールはペアとサービスを名指しするので、プールが増えても許可は生き残り、トンネル間トラフィックの包括的な拒否より前に置いてください。最初の一致が勝つからです。

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

これらのコマンドは例示であり、ホストがルールを永続化する仕組みに属します。実行時の挿入は次の起動で消えます。B の応答と TCP ハンドシェイクが、二つ目の鏡像的な許可なしに戻れるようにするのはステートフルなルールです。

あとで確認するのはルール一覧ではなくカウンターです。決して一致しないルールは機能するルールと見分けがつかないからです。カウンターがゼロのままなら、パケットはあなたが思う経路を通っていません。

B がなお許可すべきもの

SSH サービスを動かすのは B なので、トンネルアドレスで何かが待ち受けているか、ホスト自身のファイアウォールが送信元を受け入れるかを決めるのは B です。サーバー側のネットワーク許可は B のどのアカウントの許可でもなく、ホスト鍵の検証とユーザー認証は他のどこからと同じく適用されます。

まず正常系として、A から B のトンネルアドレスへの新しい SSH 接続が期待どおりのホスト鍵で受け入れられることを試します。次に別のピアや別のポートを試し、拒否されることを確認します。黙って何でも許す許可は、重要になるまで機能する許可と区別できないからです。このテストの両半分が必要で、二つ目が人が飛ばすほうです。

割り当てられたアドレス、両クライアントの実効経路、サーバーと B の正確なルールを記録します。ゲートウェイへの ping 成功やサーバーの開いたポートはどれもこれを証明しません。ピア間転送がまだ遮断されていても両方は真になり得るからです。再接続後のアドレスが別のものかもしれないので、数値はトンネルが上がっているうちに書いてください。

関連記事