Access Server のゲートウェイユーザー：クライアント拠点の LAN への経路

OpenVPN クライアントのトンネルアドレスに ping は通っても、その背後の LAN 上のホストには届かないことがあります。Access Server は VPN プールからアドレスを割り当てますが、プールのアドレスはサーバーが自分のものと知っている範囲にすぎません。拠点のプレフィックスは別途宣言すべき事実で、宣言後も拠点側の転送役と本社側の戻り経路が必要です。誤った場所に入れた経路は解決に見えて何も変えません。

二つのアドレス、二つの異なる所有の主張

クライアントが接続すると、Access Server は設定済みの VPN プールからアドレスを割り当てます（例：10.90.0.0/24）。それは一ホスト分の貸与です。同じクライアントが 10.60.0.0/24 の前にもいることを接続は伝えず、サーバーは推測しません。LAN プレフィックスは管理者が宣言したときに限り、特定のクライアント経由で到達可能になります。

そのため別のマシンに静的経路を足しても効きません。経路は 10.60.0.0/24 をこのアドレスへ送れと言いますが、そのアドレスがゲートウェイとして印を付けられていないクライアントのものなら、サーバーがそこへ配送する理由はなく、クライアント側のスタックが捨てることもあります。宣言と経路は一つの仕組みの両半分です。

ゲートウェイ設定が実際に何を入れるか

管理画面では宣言はユーザーの属性です。コネクターユーザーで Configure VPN gateway を有効にし、実際の拠点プレフィックスを Network on the VPN client side に入力します。そのユーザーも他と同じく認証されるため、無人端末向けの資格情報ポリシーが必要で、自動ログインプロファイルは利便のためのファイルではなく秘密です。

そのチェックボックスの背後で、サーバーはそのプレフィックスを当該クライアントのプールアドレス経由で到達可能とみなし、Access Controls 配下のルーティング設定が他のクライアントへの通知内容を決めます。通常クライアントへ配る経路と、本社のネットワークからクライアントのアドレスやサブネットへの通信を許可するアクセス規則です。拠点に届くべきネットワークだけ経路を有効にし、許可リストは短く保ちます。

生成ファイルに貼り付けた Community 風のディレクティブはこのモデルに参加しません。配布するルーティングテーブルは製品が所有し、手で編集した行は次回の生成で上書きされるか無視されます。

両ネットワークの戻り経路を完成させる

具体案：本社 10.40.0.0/24、拠点 10.60.0.0/24、VPN プール 10.90.0.0/24、Access Server は本社側のプライベートアドレスで到達可能とします。本社のルーターには拠点プレフィックスとプールへの経路が、いずれも Access Server 向きに必要です。無い場合、トンネルは要求を運びますが 応答は既定ゲートウェイから出て、典型的な半開接続になります。

拠点ではコネクターが自分宛てでないパケットを転送する必要があります。OS の IP 転送に加え、トンネルと LAN のインターフェースに限定した転送許可です。Linux では net.ipv4.ip_forward=1 と forward チェーンの規則、Windows では routing and remote access です。さらに拠点のホストには戻り経路が必要で、コネクターを既定ゲートウェイにするか、既存ゲートウェイに本社とプールのプレフィックス向けの経路を持たせます。

コネクター自身のルーティングテーブルは拠点 LAN の全ホストを再設定しません。ホストが別のルーターを向いているなら戻り経路はそちらに属し、そのルーターは自分が見る送信元がローカルサブネットの隣人でないことを受け入れる必要があります。

失敗は許可ではなく経路として読む

決まった順で試します。まず Access Server から拠点ホストへの許可済みサービス、次に本社の通常ホストから同じサービス、方針が許せば逆方向です。一つ目が通り二つ目が失敗するなら配布経路かアクセス規則が原因です。両方通るのに応答が来ないなら、拠点の転送と本社側の戻り経路を調べます。

次に疑うのはホストのファイアウォールです。経路化されたアクセスでは宛先が本社やプールのアドレスを送信元として見るため、ローカルサブネット向けの規則は一致せず、ルーティングが完璧に働いた後にパケットが捨てられます。

二つの設計には追加が要ります。拠点間でプレフィックスが重なると宛先が曖昧になり、再番号付けか変換が必要です。クラスター構成の Access Server では経路を一ノードが持つのではなく、全ノードが拠点コネクターへの経路を持つ必要があります。変更は製品の通常の保存と更新の手順で適用し、コネクターを再接続して両端から再確認します。全マシンの再起動は手順に含まれません。

Access Server の site-to-site チュートリアルは同じ設定を製品の順で並べています。設計を自分のプレフィックスに合わせる前に一度は従う価値があります。