OpenWrt on WZR-HP-AG300H: VPN サーバー
VPN は tun モードでセットアップした(が、それとは別に tap モードでもセットアップし、両立させた)。基本的には OpenWrt 公式のガイド(👉 OpenVPN Basic)に従ったが、必ずしも公式ガイドその通りに uci コマンドを使ってセットアップせずとも、コンフィグファイルを直接編集したり、一部の操作は LuCI でも代用できると思う。
PKI の準備
PKI をセットアップ(= Easy-RSA をインストール)し、必要な証明書等を生成する。これはガイドの通りにそのまま。 👉 OpenVPN Basic: PKI
VPN 用の仮想の物理インターフェースの作成と、論理インターフェースの作成
仮想の物理インターフェース tun0 を紐付けた論理インターフェース vpn_router を作成する。プロトコルは none(LuCI 上では Unmanaged と表示される)👉 OpenVPN Basic: Network
また、これは独自にやり方を見出したが、tap モードでセットアップすることもでき、物理インターフェース tap0 を作った場合は、論理インターフェースを新設せず、論理インターフェース lan の物理インターフェースの一つとして tap0 を追加するだけで良い(上のスクリーンショット。論理的に lan の一部として存在するので、tun モードの場合のように、Firewall の設定をする必要はない)。
OpenVPN Services
OpenVPN サービスをセットアップ(= openvpn-openssl をインストール)し、設定する。ガイドでは uci コマンドを使っているが、luci-app-openvpn をインストールすれば、LuCI の GUI でも代用できないことはないと思う。ガイドの uci コマンドでは環境変数を使って自動化している部分があり、何らかの理由で不具合がある場合には、あとで適宜設定を修正する必要があるかもしれない。また、VPN 用のネットワークアドレスも、自分で使いたいものに修正する。👉 OpenVPN Basic: VPN-Service
ポート番号が重複しないようにすれば、同時に、tun と tap のサーバー(上のスクリーンショットの router_server と bridge_server がそれぞれ該当する)を立ち上げることも可能。
Firewall
公式ガイドでは Firewall の設定を行っているが、当該機がルーターでセットアップ・運用されている場合に wan からの通信を vpn_router に通すためのものであり、ブリッジでセットアップ・運用されている OpenWrt 機の場合は wan ゾーン自体が削除されているため、関係ないだろう。
ゾーンとして vpn を定義し、lan ゾーンとの間でのトラフィックを全許可する。さらに Masquerading を設定するのが肝(下のスクリーンショットと次節参照)。👉 OpenVPN Basic: Firewall
Masquerading
当初は接続先ネットワークのゲートウェイルーターの静的ルーティング設定で強引に(?)VPN 専用ネットワークへのルーティングを可能にしていたため気付かなかったが、後に接続先ネットワークのゲートウェイルーターを静的ルーティング設定ができないもの(Aterm WG1200HP)に置換したことで、突如 VPN サーバー以外の接続先の LAN 側ネットワークに接続できなくなった。OpenWrt の Masquerading の設定なども試したものの打開できず、「ゲートウェイルーターが静的ルーティングすらできない安物だから(どうしようもないのか)」と一度本気で諦めたほどである。
しかし翌日ふと閃いて、Masquerading を、VPN 側ではなく、LAN 側で設定したところ、嘘のように問題が解消した。理論上からしても、Masquerading できれば静的ルーティングの必要性はまったくなかったわけだし、むしろ静的ルーティングしない方がセキュリティ上好ましいくらいである。
スクリーンショットに表示されているチェックこそが、tun モードでの VPN における重要で決定的な魔法だった。
追記(2019-03-10):proto 'tcp' にすべし!
これは OpenWrt での OpenVPN 特有の話ではないのだが、デフォルトの話として使用プロトコルは UDP ではなくて TCP にすべきである。何かどうしても TCP では嫌で UDP で高速化を図りたい人のみ、意図して UDP にすべきで、デフォルトでは OpenVPN というものは TCP を使うことにしておくべき。
当初、WiMAX 回線からの VPN サーバーへの接続で完全に全く問題がなかったので気付かなかったのだが、公衆 Wi-Fi を使ってみた時に、急に接続できなくなって一日ほどずっといじくり回して悩んでいた。プライベートネットワークアドレスの競合なのかなと悩んだり。公衆 Wi-Fi 側で VPN をフィルタリングしてブロックしている可能性も頭をよぎった(こういう邪推をする人はチラホラいるようである。だが、これは全くの大間違い、冤罪もいいところである)。
UDP が諸悪の根源であった。寝る前に海外の掲示板情報で「TCP にすべし」という情報をチラッと目にし、「ああ、昔 DD-WRT で初めて OpenVPN に取り組んだ時もそういう話を聞いたことがあったな、明日試してみよう」と思って眠り、翌日 TCP にした途端、嘘のように超絶安定化してサクサクと繋がるようになった。何てことだ。
世間では、VPN は「デフォルトが UDP で、問題があれば TCP」みたいな扱いだが、これ、逆だろう。
(※LuCI では、proto 'tcp'/'udp' の設定オプションは存在せず、/etc/config/openvpn を直接編集する必要があった)
ハマり所についての考察
サーバー側のセットアップとしては、以上で、特に問題がなければ、難しい設定をする必要もなく上手く動いてしまう。動かない場合には、OpenWrt 機のネットワークやファイアーウォールの設定がおかしかったり、ネットワークのゲートウェイにおける、ポートマップが適切でなかったり、ルーティングが適切でなかったり、またOpenVPN クライアント側の設定が適切でなかったりである。自分の場合も当初は一発で上手く動かなかったので、できるだけ単純なネットワーク環境にして一つ一つセットアップし直してみたりしたが、最終的には、OpenWrt 機における上記の OpenVPN サーバー自体の設定に起因するミスではなく、ファイアーウォールの設定や、ネットワークのゲートウェイ側の設定、クライアント側の設定などが原因だった。OpenVPN 自体は、サーバーとクライアントで OpenVPN アプリが稼動している限り、同じ設定内容の設定ファイル(.ovpn)を使えば、通信できるようになっているので、暗号化方式のせいだとか、そういうところで失敗することは意外とないと思う。それ以前に、ネットワーク(ファイヤーウォール等)やルーティングが上手く機能していない可能性が高い。
VPN サーバーがセットアップ作業の一つの区切り
以上、VPN サーバー化によって、遠隔でも OpenWrt 機でのセットアップ作業を継続できるようになるのは大きい。
コメント
コメントを投稿