OpenVPNではまる (2)
恥ずかしながら、どこではまっていたのかという部分について書いてみる。
クライアントPCは、インターネット越しにWebサーバ(2xx.xxx.xxx.1)に対してFTPを行いたいのだが、FireWallのポリシーがそれを許可していない。そこで、Webサーバと同一セグメントに設置したOpenVPNサーバ(2xx.xxx.xxx.2)との間にVPNを張り、OpenVPNサーバ経由でWebサーバにFTPさせたい。当然、FireWallは外部からOpenVPNサーバへの1194(UDP)は許可しているものとする。
クライアントPCはVPNのセッションが確立すると10.8.0.0/24 のアドレス(10.8.0.5とか)を取得する。Webサーバとの間で通信を行うためには、相互に経路情報を持たせる必要がある(HOWTOにもそう書いてある）。
ところが、この構成ではWebサーバがインターネット上にあるのに対し、クライアントPCはプライベートネットワークにあるため、クライアントPCをOpenVPNサーバのIPアドレスにNAT変換して通信させる必要がある。当然、Webサーバ側は特別な経路情報を持つ必要はなく(OpenVPNサーバと同一セグメントにあるため)、クライアントPCだけがWebサーバへの経路情報を持てばよい。そこで、NATの設定をするとともに、何の疑問も持たずにHOWTOに書かれているとおりにサーバ設定ファイルに経路情報を追加した。
push “route 2xx.xxx.xxx.0 255.255.255.0″
結果的にこの設定が致命傷で、クライアントのすべての経路情報が死滅。VPNのゲートウェイである 10.8.0.1 にすら ping が通らないという事態が生じた（ここが振り出し）。冷静に考えれば経路情報が矛盾するのか、と思い至るが、これには最後まで気づかなかった。この経路設定をサーバ設定ファイルから消してやると ping が無事通るようになるが、今度は経路情報がないので Web サーバとは通信できない。どっちにしろダメじゃん。
回りくどい話になったが、この問題を解消するためには、すべてのトラフィックがVPN経由となるように設定してやればよい。すなわち、以下の項目をサーバの設定ファイルに追加する。
push “redirect-gateway def1″
あとは NAT の設定とか、フィルタリングとか、細かい設定を煮詰めていけばいい。これはHOWTOにも載っているので省略。ちなみに、この結論にたどり着いた時の環境はFreeBSDだったため、iptables ではなく ipfw でやる羽目になった。不慣れなため、これもそこそこ大変だった。ま、本題から外れるのでそれは各自頑張る、ということで。