OpenVPN に接続できたのに ping も SMB 共有も通らない？三つの関門を確認する

遠隔 LAN 上の何も応答しないのに、トンネルは確立してクライアントはアドレスを取得します。ping は失敗し、共有も開かず、VPN のログはきれいに見えますが、VPN 側から見ればセッションは正常だからです。そのセッションとサーバー上のファイルの間には、転送ポリシー、サービスが必要とするポート、アドレスの代わりに入力した名前という三つの独立した関門があります。

各関門はそれぞれ違う症状で失敗し、VPN サーバー側にあるのは最初の一つだけです。

転送は FORWARD チェーンのポリシーです

OpenVPN のリスナーの受け入れは INPUT で行われるため、LAN 宛てのパケットがすべて破棄されていてもトンネルは接続できます。LAN 宛ての通信が tun0 に入って LAN インターフェイスから出るものは FORWARD を通り、そこで既定の DROP ポリシーを持つホストはそれを黙って捨てます。ほかの何かに触る前に、sysctl とチェーンの両方を確認してください sysctl net.ipv4.ip_forward と iptables -L FORWARD -v -n。

意図する方向とそれに属する応答を許可します（たとえばトンネルインターフェイスから LAN インターフェイスへの accept ルールと、established および related 通信のための stateful ルールです）。LAN が別のルーターの背後にある場合、そのルーターにはクライアントプールへの戻りルートか、VPN サーバー上の source NAT が必要です。ルールを増やす前に、到達できないルールはカウンターに決して現れないため、一度の ping でその経路を確認してください。

SMB には一つのポートでは足りません

ファイル共有は TCP 445 の一本の会話ではありません。検出には UDP 137 と 138 を使い、古い NetBIOS セッションは TCP 139、現代の SMB セッションは TCP 445 を使います。445 だけを開けるルールは、マップしたドライブは動くのにネットワークの参照は動かない、あるいはその逆という厄介な状況を生みます。

トンネル経由の大きな転送は、共有が壊れたように見える MSS 問題にも当たります。LAN の完全なセグメントサイズを宣言する SYN は、トンネルのより小さな MTU によって破棄され、ハンドシェイクの後に接続が止まります。転送経路で MSS をクランプすること iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu が、その種の停止を取り除きます。ディレクトリ一覧ではなく、小さな応答は大きな転送が通らないときでも通るため、数メガバイトのコピーで検証してください。

トンネルアダプターは新しいネットワークプロファイルとして現れます

Windows は各アダプターをネットワークプロファイルに分類し、新しいトンネルアダプターは通常、ファイルとプリンターの共有ルールがブロックされる Public に入ります。これはファイルサーバー上のホストファイアウォールの判断であり、VPN サーバー上のルーティング問題ではありません。ポリシーが許すことを確認したうえで、カテゴリが適用される受信ルールも変えるため、意図的に Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private でカテゴリを変えてください。

同じプロファイルが、Public では既定でエコー要求が破棄されるために TCP 445 は成功するのに ping が失敗する理由を説明します。

名前はルーティングされたトンネルを勝手には越えません

NetBIOS の名前解決とローカル検出は、ルーティングされたトンネルが運ばないブロードキャストに依存します。そのためサーバーの短い名前を入力しても失敗し、アドレスなら機能します。参照だけが壊れているのに共有が壊れて見えるため、トンネルが配布するリゾルバーにサーバーの DNS レコードを追加するか、ショートカットにアドレスを使ってください。

導入がまだ WINS に依存しているなら、ブロードキャスト通信が現れることを期待せず、クライアント側で設定してください。名前の失敗をファイアウォールの失敗と取り違えないよう、まずアドレスで試してください。

一度に一つの層を試し、最初の失敗を読む

下から上へ進み、トンネルのゲートウェイに ping し、アドレスで LAN ホストに ping し、次に Test-NetConnection -ComputerName 10.8.0.5 -Port 445 でサービスのポートを開き、その後にだけ共有へ認証します。最初に失敗した手順が直すべき層であり、それ以降の手順はそれが通るまで雑音です。ポートが閉じたままなのに ping が返る場合はファイルサーバー自身のファイアウォールを示し、ping が沈黙していてもポートが開く場合は ICMP フィルタリングを示します。二回目の変更が一回目の結果を隠すため、何かを変える前に最初に失敗した手順を書き留めてください。

VPN サーバーが LAN のルーターでない場合は、そのルーターの戻り経路を確認してからサーバーにルールを追加してください。それがなければ要求はホストに届いて応答は既定ルートでインターネット側へ出るため、クライアント側から見るとファイアウォールによる破棄とまったく同じに見えます。

成功したトンネルはファイルの権限については何も語らないので、メモでは共有アカウントを VPN のログインから分けてください。足りないルールを避けるために SMB をインターネットへ公開するのは解決策ではありません。