AWS Client VPN の一つのセッションの向こう側にある LAN：何が転送されるか

ホスト上で動くセッションは、それだけでは LAN に広がりません。クライアントの対応、転送、変換、戻り経路の順に確認します。

ノート PC は AWS Client VPN エンドポイントに接続し、プライベートサブネットに到達し、すべて健全に見えます。同じ LAN 上のデスクトップは何にも届きません。Linux ホストにもブリッジインターフェースがあり、二台は同じケーブルにつながっているのにです。トンネルに設定の誤りはなく、足りないのはルーティングであり、ブリッジは誤った手がかりです。

Client VPN セッションを LAN に広げるのはゲートウェイの役割です。マネージドサービスの中に引き伸ばした Ethernet セグメントではありません。

ホストは動くが LAN は動かない

Linux マシンのトンネルインターフェースには Client VPN クライアント CIDR 内のアドレスがあり、エンドポイントは VPC の範囲へのルートを配布しています。そのマシン上で行う要求はローカルに生成されたトラフィックです。ルートを選び、トンネルから出て、応答を受け取ります。この経路は転送コード、LAN インターフェース、通過を司るファイアウォール規則のいずれにも触れません。

別の LAN 機器からのトラフィックは別のフローです。LAN インターフェースに到着し、トンネルを指すルートが必要で、転送が有効である必要があり、それを許可するファイアウォールが必要で、応答が同じホストを通って戻る必要があります。四つの条件があり、動いているノート PC のテストはそのどれも証明していません。デスクトップから見ると障害は奇妙です。トンネルは上がり、資格情報は有効で、宛先がただ応答しないのです。欠陥はゲートウェイの転送経路に局所的にあり、サービス側ではありません。

すべてのクライアントがゲートウェイになるわけではない

AWS は、自社の Client VPN デスクトップアプリが IP 転送をサポートせず、他のクライアントはサポートしうると述べています。この制約は、コマンドを一つ入力する前にアーキテクチャを決めます。利用できるクライアントが公式のデスクトップアプリだけなら、LAN のために転送する Linux ゲートウェイは完成できる構成ではなく、どれだけ masquerading をしても変わりません。

代替クライアントは、エンドポイントの認証方式と適用しようとするポリシーにも合致しなければなりません。証明書ベース、ディレクトリベース、SAML ベースのエンドポイントは同じクライアント構成を受け入れず、認証はするが配布されたルートを無視するサードパーティ製クライアントは改善ではありません。

クライアントの選択は設計レビューの一部として扱います。LAN 転送のパターンがそもそも使えるかどうか、そしてゲートウェイの背後の各機器に対してエンドポイントがどの ID を見るかが決まります。クライアントと、試験したエンドポイント構成を記録します。半年後のクライアント差し替えは、設計が前提とした能力を静かに削ることがあります。

LAN をトンネルへ向けて変換する

対応クライアントがあれば、残りは普通のゲートウェイ作業です。LAN の機器には VPC の範囲に対する Linux ホスト向きのルートが必要で、ホストには転送の有効化が必要です。VPC に、任意の LAN アドレスとしてではなく接続クライアントとしてトラフィックを見せたいなら、出口で送信元を変換します。

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

規則は上のようにトンネルインターフェースと VPC の範囲に限定し、ホストが転送するすべてを masquerade しないようにします。狭い規則のほうが筋道を立てやすく、元の送信元アドレスを保つべきトラフィックを静かに変えることもありません。

できれば LAN のルートは自動で届くようにします。DHCP オプション、ルーター広告、あるいは LAN を管理する何かが配布する静的ルートです。試験機一台にしか存在しないルートは、他の誰かが試した瞬間に設計を壊れて見せます。

戻りの応答にも経路が要る

要求が VPC に届くと、応答は同じ変換状態を通って戻り、ゲートウェイ上の LAN ルートを見つける必要があります。この部分は masquerade 規則があれば通常は機能します。対応表がそれを実行したホスト上にあるからです。VPC 側に応答を別の場所へ送るルートがあると壊れます。だからこそクライアント CIDR のルートとエンドポイントのサブネット関連付けの両方が重要です。

ping だけでなくカウンターを見ます。パケット数がゼロの masquerade 規則は、要求がトンネルインターフェースに届いていないことを示し、LAN ルートかクライアント自身のルーティングテーブルを指します。パケットはあるが応答がない規則は、VPC 側、認可規則、または変換後の送信元を受け入れないセキュリティグループを指します。何かを変える前に両方向を読みます。片側だけ増えるカウントは遅い経路ではなく片方向の経路です。

エンドポイントはマネージドサービスであることを忘れないでください。編集するサーバー設定ファイルも、追加する client-config ディレクティブもないため、クライアントサブネットの独自ルートを持つ自己管理の OpenVPN サーバー向けに書かれた手順はそのままでは移せません。AWS では、サブネットの関連付け、認可規則、VPC のルートテーブルがレバーになります。

共有 ID はポリシーが答えなければならない部分

ゲートウェイの背後のすべての機器はゲートウェイの VPN セッションを使います。エンドポイントの認可規則はユーザーまたはグループにアクセスを与え、サービスの視点ではそのセッションにちょうど一人のユーザーがいます。ローカル転送はその ID を機器ごとの認証に増やしませんし、機器のポスチャチェックを隅のプリンターまで広げることもありません。

それが許容できる場合もあれば、設計が却下される理由になる場合もあります。VPC のリソースが、誰が呼び出しているかについて何を前提とするかによります。認可モデルに合う共有 ID は問題ありません。認証済みの単一セッションを静かに LAN 全体のアクセスに変えるものは、書かれるのを待つ指摘です。

要件が本当に拠点全体を VPC につなぐことなら、リモートアクセスクライアントを広げる前に、対応するサイト間設計を比較してください。意味論は異なり、VPC が LAN への接続を開始する必要がある場合、NAT されたクライアントセッションは拠点リンクの代わりとしては貧弱です。

クライアント、ルート、変換、ID の筋書きをこの順に決めます。それぞれが次を制約し、この順序が、ホストは動くのに LAN は動かない理由を説明します。

関連記事