VPNポートを開けてもクライアントはLANに届かない

トンネルは上がり、クライアントは認証を終えますが、ゲートウェイの背後のLANは見えないままです。これを直すはずだったルールはVPNポートを許可しており、書かれたとおりに動作しています。そのルールが扱うのは、ゲートウェイ自身宛てのパケットだからです。ゲートウェイの背後のホストへ向かうクライアントの通信は、宛先も見られる鎖も別です。ログインの成功は、カーネルがどちらの鎖を見るかを変えません。

二つの鎖、二つの宛先

パケットの運命はどこへ行くかで決まり、どう届いたかでは決まりません。ゲートウェイ上のアドレス宛ての通信はローカルに届けられ、入力ルールで評価されます。ゲートウェイが先へ転送する通信は、転送ルールで評価されます。同じトンネルのインターフェースから両方の種類のパケットが出るため、一つのルールで両方の仕事は覆えません。

神話は一行に尽きます。待ち受けを許可しても、その背後のネットワークを許可したことにはなりません。根拠の異なる二つの判断であり、両方に同じインターフェース名があっても一つにはなりません。

待ち受けのルールが実際に許すもの

待ち受けのパケットはVPNのプロセスで終わります。それがあるからこそトンネルを張れるのです。ゲートウェイの管理画面やローカルの診断応答もホスト自身の入力経路を使うため、ゲートウェイへの確認は成功し、その背後はすべて失敗します。どちらの結果も正しく、どちらもLANの話ではありません。

プロセスが別の宛先のためにクライアントの通信をカプセルから取り出すと、パケットは転送の経路に入り、そこでの許可が要ります。認証の成功はクライアントが誰かを決めますが、どこへ行けるかは決めません。二つの問いは、持ち主もログもエラーメッセージも違います。

クライアントから試し、ゲートウェイからは決して試さない

ゲートウェイで作った試験はホスト自身の出力経路を通るため、転送の経路が閉じていても通ってしまいます。試験はクライアントから始め、流れの両端を見ます。

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

要求が tun0 に現れ、宛先に何も届かないなら、パケットは到着後に捨てられています。転送ルールか宛先自身の絞り込みが原因です。tun0 に何も現れないなら、クライアントはトンネルにすら送っておらず、問題はゲートウェイのポリシーではなくクライアントの経路です。正しく出て何も戻らない要求と比べてください。それが戻り経路の事例です。

転送に必要なのは一つではなく三つ

カーネルの転送が有効で、絞り込みのルールが流れを受け入れ、宛先に届いて応答が戻る経路があること。三つのどれかが欠けると、クライアントから見た沈黙は同じです。

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

三つの出力を並べて読みます。一つ目がゼロなら残り二つは無意味です。二つ目が既定の破棄なら、ゲートウェイ自身の通信は動いたままクライアントのパケットだけが捨てられます。三つ目は、待ち受けのルールが最初から問題ではなかったことを示します。

文書では二組のルールを分けておく

待ち受けのルールと転送するサービスのルールは、別の行に、別の持ち主と理由で書きます。VPNポートが変わるときや新しいサービスを公開するとき、この分離が一方の変更で他方が黙って広がるのを防ぎます。

認証済みの相手をすべて信頼できるLANの一員とみなすのではなく、必要なクライアント範囲とサービスに狭いルールを使います。StrongSwanの転送の覚え書きは、同じ境界の戻り経路と変換の側を説明しており、これもまた三つ目の判断です。

最後に、利用者が拒否されたときは層を取り違えないことです。要求がホストに届き、アプリケーションがアカウントを拒むなら、その層でアプリケーションの権限を直します。転送を広げてもファイル共有の資格情報は得られず、接続に成功する他のすべての相手のアクセスまで広げてしまいます。