OpenVPN の LAN アクセスが不通？ゾーン・ルート・戻り経路を確認

トンネルは接続成功を報告し、ルーター自身のページも開くのに、その先のマシンへのドライブ割り当ては依然としてタイムアウトします。この組み合わせに矛盾はありません。ルーターは自分自身として応答しており、その先の何かに届くかどうかは別の場所で決まる別の判断です。以下の確認を順番に行い、最初の失敗で止めてください。どれも前の確認の上に成り立っています。四つすべてが通れば、障害はトンネルの中ではなく上にあります。

LAN 宛てのパケットをどのフィルタが見るか

ルーター宛てのパケットはローカルで消費され、その先のホスト宛てのパケットは転送されなければなりません。ファイアウォールはこの二つを別々に判定します。したがって、ルーターに届く許可は、ルーターを越える許可について何も語りません。ルール群を隠すファームウェアでも両方を実装しており、通常は LAN、インターネット、またはその両方を選ぶセレクタとして提供します。セレクタが LAN を外していれば、後の確認はどれも意味を持ちません。

OpenWrt ではこの分割を検査でき、その区別は一度読む価値があります。トンネルを終端するゾーンには LAN ゾーンを指す転送ルールが必要で、入力ルールはルーター自身のサービスだけを統制します。管理ページが開くのに LAN が死んでいるのは、この転送ルールの欠落によるよくある結果です。

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

トンネルを運ぶゾーンの転送先を見てください。accept がこの手順に必要な値で、reject は以下のタイムアウトすべてを説明します。隣接する二つの設定が同じ症状を生むので、ここで一緒に除外しておきます。無線の分離は有線ホストを無線クライアントから隠し、アイドル状態の LAN ホストをオフラインとみなすルーターは、転送が機能した後でも応答を捨てることがあります。

分割トンネルにプレフィックスの push が必要な理由

すべての通信をトンネル経由で送るクライアントは、デフォルトルートを通じてすでに LAN プレフィックスを持っているので、追加するものはありません。分割トンネルこそがプレフィックスを明示する必要があるケースで、設定のどこにもそれが出てこないからです。サーバー設定にディレクティブを追加し、サービスを再読み込みします。

push "route 192.168.50.0 255.255.255.0"

次を含むプロファイルは route-nopull push されたルートを無視するため、同じプレフィックスはクライアントファイルに入れるべきです。いずれにせよ、エントリが届いたと仮定せず確認してください。静かな上書きはファイアウォールの問題とまったく同じに見えます。

ip route show | grep 192.168.50

サイト間ピアは push 以上のものを要求します。サーバーはそのピアの背後にどのプレフィックスがあるかを学習する必要があり、それは client-config-dir ファイルの iroute 行が行います。またサーバー自身のテーブルにもトンネルへ向かう対応ルートが必要です。

応答には到達できるアドレスが必要

要求を転送するだけでは交換の半分にすぎません。LAN のホストはトンネルプール内のアドレスに応答しなければならないからです。小型ルーターは通常、トンネルゾーンで送信元を変換することでこれを処理するため、応答はルーター宛てになり、他の場所に設定は要りません。その変換を外すと、ホストはプールへの独自ルートを必要とし、ルーターがデフォルトゲートウェイであれば無料で得られます。アドレスを手動設定し別のゲートウェイを持つホストはそのゲートウェイ経由で応答し、クライアントにはセッションが開いてから止まるように見えます。

tcpdump -ni tun0 host 192.168.50.20

クライアントが要求を繰り返す間にこれをルーターで実行し、要求そのものではなく応答の宛先を読んでください。プール宛ての応答は戻り経路が機能しており、障害がさらに内側にあることを意味します。応答がまったくなければホストがパケットを受け取っていないので、ルール群に戻ることになります。

正しい場所で終わる手順

四つの確認で層を特定でき、どれも判断ではなく単一のコマンドです。順番に実行し、最初の失敗で止めてください。順序はコマンド以上に重要で、後の手順が通ると前の失敗の理由が隠れます。

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

名前は手順の最後に置き、決して最初には置きません。192.168.50.20 としては応答するが nas.local としては応答しない共有は、名前解決か検索サフィックスを示しており、ファイアウォールの編集ではどちらも変えられません。

最初に失敗した手順を記録し、次にサービスポートに独自の確認を割り当ててください。リスナーとホスト側の許可は別々の要件だからです。ファイル共有、リモートデスクトップ、カメラのストリームはいずれも両方を必要とし、LAN サブネットは信頼するがトンネルプールは信頼しないホストファイアウォールは、ping が通っていてもクライアントを落とします。すべての確認が通り、それでもアプリケーションが失敗するなら、障害はトンネルの上にあります。一つのインターフェースに束縛されたサービスか、クライアントに設定されたプロキシです。