OpenWrt の OpenVPN（サーバー）についての包括的メモ

一応、公式に基本ガイド（👉 OpenVPN Basic）があるが、「OpenWrt の OpenVPN 基本ガイドの徹底解析」で先日述べたように何かと不満があるので、自分用を兼ねて包括的なメモを記しておくことにする。

情報の鮮度的には、古い方のルーター（OpenWrt v18.06.2）が OpenVPN v2.4.5、新しい方のルーター（OpenWrt v19.07-SNAPSHOT）が OpenVPN v2.4.7 である。

また、クライアント側は、macOS の Tunnelblick を使用している。

ソフトウェア

openvpn-openssl と openvpn-easy-rsa（と luci-app-openvpn）を LuCI からインストールした。

PKI

PKI については基本ガイドや巷の情報でほとんど十分だと思うので基本的に割愛する（👉 Easy-RSA 3 Quickstart、Easy-RSA 3）。PKI 用の easyrsa コマンドは /etc/easy-rsa で実行し、PKI のパスが /etc/easy-rsa/pki となりその以下に各ファイルが配置されている。ただし、openvpn コマンドで作成する tlscrypt.key のみ、/etc/openvpn に置いている。


cd /etc/easy-rsa
easyrsa init-pki
easyrsa build-ca nopass
easyrsa build-server-full openvpn-server nopass
easyrsa build-client-full openvpn-client nopass
easyrsa gen-dh
openvpn --genkey --secret /etc/openvpn/tlscrypt.key

TAP サーバーとして動かす場合

TAP サーバーとして設定するのは特に難しくなく、既存の情報で何か不足するようなこともない。

tap0 の準備

OpenVPN 自体の設定に一所懸命になっていると、この作業を思わず忘れてしまっていて動かずに原因がわからずに悩む場合があるが、仮想のものではあるとは言っても、まずは tap0 というインターフェースを用意してアサインしないことには、外部から何ら情報を受け取ることができない。

LuCI の Network > Interfaces から論理インターフェース「LAN」の編集画面に入り、Physical Settings タブで所属する物理インターフェースを設定できるので、（仮想ではあるが）物理インターフェースとして「tap0」を LAN にアサインする（存在しなければ Custom Interface で「tap0」とすればよい）。これによって、論理インターフェース「LAN」の 192.168.1.0/24 のネットワークに tap0 を参加させることができる。

Firewall の設定は不要である。LAN の参加する Firewall ゾーン「LAN」の設定の管理下に入るだけである。

※インターフェースに変更を行うと LuCI の Save & Apply では不十分で、インターフェース自体を再起動する必要がある。

サーバー側の設定（/etc/config/openvpn）
config openvpn 'bridge_server'
 option enabled '1'
 option dev 'tap0'
 option port '51194'
 option proto 'tcp-server'
 option compress 'lz4-v2'
 option dh        '/etc/easy-rsa/pki/dh.pem'
 option ca        '/etc/easy-rsa/pki/ca.crt'
 option cert      '/etc/easy-rsa/pki/issued/openvpn-server.crt'
 option key       '/etc/easy-rsa/pki/private/openvpn-server.key'
 option tls_crypt '/etc/openvpn/tlscrypt.key'
 option remote_cert_tls 'client'
 option key_direction '0'
 option keepalive '10 120'
 option persist_tun '1'
 option persist_key '1'
 option user 'nobody'
 option group 'nogroup'
 option verb '5'
 option server_bridge '192.168.1.1 255.255.255.0 192.168.1.250 192.168.1.254'
 list push 'redirect-gateway def1'
 list push 'dhcp-option DOMAIN myhomelan'
 list push 'dhcp-option DNS 192.168.1.1'
 list push 'persist-tun'
 list push 'persist-key'
  • OpenVPN サーバーのルーターが実際に所属するネットワーク（ここでは 192.168.1.0/24）に直接接続されることになるので、server-bridge（server_bridge）としてはルーター自体のアドレスとネットマスク、後ろの 2 つは同じネットワークの中からクライアントに割り当てる IP アドレスプールを範囲で示す。
  • dhcp-option DOMAIN は、ドメインを省略してホスト名だけで示した場合に自動補完されるべきローカルのドメイン名で、オマケ的もの。
  • dhcp-option DNS は必須。ここではゲートウェイを DNS サーバーとして示している。
  • tls-key を使っていないので、key-direction が本当に必要で実際に機能しているのかは不明。
  • proto 'tcp-server' なので mssfix を設定せずとも一応どうにかなると思う。理想的には、proto 'udp' にして且つ、適切な mssfix を ping の試行を繰り返して決定しておくことである。
  • compress 'lz4-v2' は、Mac 側の Tunnelblick との間で両方が対応していたので、これを選んで使っている。これにしなければというようなものでもない。
クライアント側の設定（.ovpn ファイル）
client
dev tap0
proto tcp-client
remote XXX.XXX.XXX.XXX 51194
resolv-retry infinite
nobind
remote-cert-tls server
key-direction 1
compress lz4-v2
verb 5
<ca>
-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
    Data:
（略）
    Signature Algorithm: sha256WithRSAEncryption
（略）
    Signature Algorithm: sha256WithRSAEncryption
（略）
-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
（略）
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
（略）
-----END OpenVPN Static key V1-----
</tls-crypt>
  • remote にはサーバーの WAN 側のグローバルアドレスを使う。
  • サーバー側の proto 'tcp-server' と、クライアント側の proto tcp-client が対になっている点に留意。udp の場合はサーバー・クライアントとも 'udp' になる。
  • ca と tls-crypt はサーバー・クライアント共通だが、cert ＋ key のセットはサーバーとクライアントのそれぞれのために作成して存在するものなので、一つの同じセットを使い回さないように注意すること。PKI の作業において、openvpn-server と、openvpn-client の 2 通りを作成するのは、そのためである。ここでは /etc/easy-rsa/pki/issued/openvpn-client.crt と /etc/easy-rsa/pki/private/openvpn-client.key の内容を .ovpn にコピー＆ペーストして使っている。また、ca と tls-crypt も、サーバーと同じものの内容を .ovpn にコピー＆ペーストして使っている。
  • proto の場合同様に、サーバー側の remote_cert_tls 'client' と、クライアント側の remote-cert-tls server が対になっている。これはセキュリティ的なオマケの設定なので（接続失敗の原因ともなるので）、最初は使わない方が良い。

TUN サーバーとして動かす場合

難しかったり、とりあえず動かすことに成功しても、細かいオプションなどで疑問が湧き、それに関する情報が見付けにくいのが TUP サーバーとして設定する場合で、自分用にもこのメモを記しておきたいと思った主な動機にもなっている。

tun0 の準備

結果論からすると、OpenVPN 自体の設定は実は TAP と比べて大きな違いはない。重要なのは、この tun0 の準備の方である。こちらをちゃんとやらないと、いくら OpenVPN の設定を色々といじくり回して試行錯誤しても、意味がないのである。

TUN の場合、VPN は専用のネットワーク空間（ここでは 192.168.255.0/24）を持つことになるので、TAP と違って論理インターフェース「LAN」（ここでは 192.168.1.0/24）に直接参加させることはできず、まずは論理インターフェース「VPN」を別途用意して、そこに tun0 をアサインする形になる。この辺りが、OpenVPN 自体というよりは、OpenWrt すなわち Linux のネットワークインターフェースとかファイアーウォールの設定の話なので、そこが良くわかっていないと、ネットで OpenVPN として検索して得られる情報だけでは「？？？」なので、大変だった。

Protocol は「Unmanaged」で設定すること。OpenVPN の server オプションで 192.168.255.0/24 を割り当てるからといって、論理インターフェース「VPN」側でも同じアドレスを律儀に設定してしまうと、競合が起こるのか、却って正常に動かなくなってしまう。次に TAP の場合と同じように Physical Interface として「tun0」をアサインする（存在しなければ Custom Interface で「tun0」とすればよい）。さらに、この新生した論理インターフェース「VPN」を、LAN と同じ Firewall ゾーン「LAN」に所属させる。これで準備 ok なはずである。

※インターフェースに変更を行うと LuCI の Save & Apply では不十分で、インターフェース自体を再起動する必要がある。

サーバー側の設定（/etc/config/openvpn）
config openvpn 'router_server'
 option enabled '1'
 option dev 'tun0'
 option port '1194'
 option proto 'tcp-server'
 option compress 'lz4-v2'
 option dh        '/etc/easy-rsa/pki/dh.pem'
 option ca        '/etc/easy-rsa/pki/ca.crt'
 option cert      '/etc/easy-rsa/pki/issued/openvpn-server.crt'
 option key       '/etc/easy-rsa/pki/private/openvpn-server.key'
 option tls_crypt '/etc/openvpn/tslcrypt.key'
 option remote_cert_tls 'client'
 option key_direction '0'
 option keepalive '10 120'
 option persist_tun '1'
 option persist_key '1'
 option user 'nobody'
 option group 'nogroup'
 option verb '5'
 option server '192.168.255.0 255.255.255.0'
 option topology 'subnet'
 list push 'redirect-gateway def1'
 list push 'dhcp-option DOMAIN myhomelan'
 list push 'dhcp-option DNS 192.168.1.1'
 list push 'persist-tun'
 list push 'persist-key'

TAP の場合の server-bridge に対して、TUN では server と topology のセットになっている部分が異なっており、あとは（当然ながら）dev と port のみ異なっている。

  • server-bridge の場合と違い、ルーター自身のネットワークアドレスを指定したりはしない。server オプションでは単に、VPN クライアント用に割り当てる専用のネットワーク空間（ここでは 192.168.255.0/24）を示すのみである。ゲートウェイを示す必要がないのは、自動的にそのネットワークの .1 が OpenVPN サーバーに割り当てられ、それをゲートウェイとしてクライアントが使用するように OpenVPN サーバーが処理するので、設定段階で設定する余地を与えるまでもないというだけの理由である。
  • topology を 'subnet' にセットし忘れると、互換性維持のための古いデフォルト設定（非推奨）の 'net30' が使われてしまい、意味不明の挙動に悩まされることになる。server 設定に必須のオプション。
クライアント側の設定（.ovpn ファイル）
client
dev tun0
proto tcp-client
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
remote-cert-tls server
key-direction 1
compress lz4-v2
verb 5
<ca>
-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
    Data:
（略）
    Signature Algorithm: sha256WithRSAEncryption
（略）
    Signature Algorithm: sha256WithRSAEncryption
（略）
-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
（略）
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
（略）
-----END OpenVPN Static key V1-----
</tls-crypt>

.ovpn については remote の port と dev の部分のみで、他は TAP の場合と違いはない。

作業上の注意点

  • ifconfig（macOS）で自分の VPN で割り当てられたアドレスをチェックする。
  • VPN の詳細ログを見て（Tunnelblick）、エラーの原因を細かく特定できるようにする。
  • nc -v [IP] [port] でネットワークインターフェースやファイアーウォールが適切に設定されてちゃんと接続自体ができているかチェックする。
  • scp [local path] root@[address]:/etc/config/openvpn (先に SSH を設定しておく) で設定ファイルをプッシュ更新する。LuCI（luci-app-openvpn）では対応していないオプションもあったりするので、scp で設定ファイルをプッシュして、ssh でログインし、service openvpn reload する（そして ssh を exit する）、それからクライアント側で OpenVPN を接続し直す、という繰り返しで設定を試した。
  • たとえ新しく仮想の論理インターフェースを追加するような場合であっても、インターフェース設定を変更する場合は要注意（カーネルモジュールドライバーが絡んでいるせいか？）。最悪、ネットが不通になる。設定をいじる直前にバックアップは必須。LuCI の Save & Apply では正常に変更が反映されず、Reboot が必要となることが多い。また、LuCI からソフトウェア的に Reboot しても Wi-Fi（のチップ）がちゃんと再起動されず、ハードウェアボタンを使って一旦完全に電源を切ってから、改めて起動し直す必要が生じたことすらあった。なのでインターフェース絡みの設定を変更する場合には、VPN を通じて遠隔から作業しようとしない方が良い（いつでもハードウェア的な電源のオフ・オンが可能なようにしておくのが安全）。
  • OpenVPN 2.4 の公式マニュアル

補遺：プロトコルの UDP 化

通常は UDP で運用されると考えられているのが OpenVPN だが、DIY で OpenWrt を扱うような一般人の場合は、まずは TCP をデフォルトに考えて OpenVPN の安定環境を確立することに専念した方がいい。そう考えて、上までの内容はすべて proto 'tcp-server'（クライアント側は proto tcp-client） での設定となっている。

しかしパフォーマンス面の有利性からすると、一旦 TCP での安定運用が確実となったならば、是非 UDP に切り替えておきたいところである。他に何の障害要因もなくなった状態で、初めて UDP 周りのオプションだけいじるのであれば、問題の特定は容易であり、精神生理的にリスクを最小限に抑えられる。

UDP の場合、MTU、MSS、フラグメントサイズのオプションを適切に設定しないと、デフォルトや自動算出に任せると問題が発生することがある。とはいえ、逆に言えば、MTU、MSS、フラグメントサイズの意味することをわかっていた上で、適切に設定していれば、問題なく UDP を使うことができるということになるわけである。

実は、今回、ちゃんと MTU サイズを ping コマンドで計測して最適な値を決めようとして、判明した事実なのだが、自分のサーバーのネットワーク環境（au ひかりのホームゲートウェイ）が WAN 側からの ping に応答しない（icmp を DROP する）仕様のため、OpenVPN の自動算出機能も機能しない、最悪のシチュエーションにバッチリ当て嵌っていたのである。それで昔から「TCP でないと安定運用できないじゃないか！」ということが、自分的には常識化していたわけである。──そんなこと（au ひかりの仕様と、OpenVPN が ping で自動算出しようとすること）を元から知っていたのなら、もちろん大した問題ではないわけだが、そんな知識だってやっていくうちにおいおい付くものだし、最初から何もかも情報が揃うわけでもない。なので、UDP よりもまずは TCP だろうというわけだ。

また、さらに状況が悪いことに、今、クライアント側の環境としては、楽天 UN-LIMIT を利用している。これが、調べてみると、MTU: 1340（MSS: 1300）という、かなり小さめの値で、OpenVPN のデフォルト値 MTU: 1500（MSS のデフォルト値は 1450）を下回っており、確実に断片化してしまう。つまりこのままでは、たとえ UDP にせず TCP のままでも効率的には悪い状況になっていたことになる。

ともかく、以上まで、色々と調べてやっと全貌が把握できたので、これで UDP 化を安全にできる状況になり、以下のような設定に至った（TCP と違っている部分についてのみ示す。他は同じ。TAP 用か TUP 用かということについてはサーバー・クライアントいずれの側でも設定に違いはない）：

サーバー側の設定（/etc/config/openvpn）
 option proto 'udp'
 option fragment '1460'
 option mssfix '1460'
クライアント側の設定（.ovpn ファイル）
proto udp
fragment 1300
mssfix 1300

※ mssfix を指定する場合、tun-mtu は指定せず（デフォルトの 1500 のまま）放置する（mssfix と fragment で直接制御するので、tun-mtu に頼らないのが正しい使い方ということのようだ）。

特に問題なく快調に VPN 通信できているように思う。例えば、TCP の時は FTP で NAS からファイルをダウンロードしながら、待つ間にヤフーニュースを見たりしていると、レスポンス・読み込み共にかなり重かった。UDP に変えると、そこがある程度改善したように思われる。

※ 楽天 UN-LIMIT のテザリング以外に、例えば公衆 Wi-Fi の tullys_Wi-Fi を使う場合は、MTU: 1118（MSS: 1078）なので fragment と mssfix を 1078 にして使えばよい……はずなのだが、公衆 Wi-Fi のせいか UDP ではどうも不安定で fragment/mssfix の設定では理論通り行かない（TLS ハンドシェイクの段階で失敗している）。こういう場合は無理に UDP にせず、元の TCP 設定で繋ぐことにした方が良い。

※ この後に続けて WireGuard もセットアップしたが、OpenVPN よりもずっと良い（決して OpenVPN が悪いというわけではないが、WireGuard が良すぎる）。どちらか迷っているのであれば、まずは WireGuard を先に試すことを推奨。

（以上）

コメント

コメントを投稿

このブログの人気の投稿

OpenWrt での Wi-Fi 設定

イメージ
OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi（Network > Wireless で該当デバイスの設定を Edit）。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC（Macbook）から作業できない、というのが個人的には決定的な理由。 設定自体は特に難しくはなく、大まかには 2.4G 帯と 5G 帯それぞれについて、暗号化キーを決め、SSID や周波数チャンネル、出力強度をカスタムしたりする程度。最後に Enable して Save & Apply する流れとなる。 以下では、最初に、作業用の古いノート PC（Linux）から有線 LAN でルーターに接続して設定を行い、5G 帯をアクセスポイント・モードで有効化し、Wi-Fi 経由で MacBook が接続できるようにしてから、（Linux マシンと LAN ケーブルを片付けて）残りの作業を行っている。 5G 帯のアクセスポイント設定 WZR-HP-AG300H の場合では radio1 が 5G 帯（802.11an）となっているので、この Wireless 設定を Edit する。 Device 設定（Advanced Settings） 上半分の Device 設定についてはまず Advanced Settings タブの国設定で「JP - Japan」を選ぶ。 Interface 設定（基本設定） 下半分の Interface 設定については上のスクリーンショットのように Mode を「Access Point」、ESSID を適当に設定する（ここでは「OpenWrt」としている）。 Device 設定（基本設定） 国設定を選んだので、基本設定のタブに戻る（下のスクリーンショット）。 チャンネルは auto にすると、PC（受信端末）側のアクセス可能範囲外のチャンネルが選ばれてしまう場合があるので、確実に接続できるであろうチャンネルを手動で選んでおいた方が無難だろう。出力パワーは最強にしておいた。帯域幅はデフォルトの 20 MHz 幅のまま（40 MHz にすると倍化するが、その分、他の Wi-Fi との干渉もし易くなるため）。 ...
続きを読む

シークエンスパパとも 本物の霊能力

イメージ
Ms Sarah Welch / CC-BY-SA-3.0 シークエンスはやともを知ったきっかけ TV を見ない僕がシークエンスはやとも（YouTuber。吉本興業所属）の存在を知ったのは、今年の春（3 月か 4 月）の頃だったと思うが、YouTube でふと宜保愛子の動画を探していて、彼が宜保愛子を称賛するものを見つけて以来だったと思う。 それ以来いくつかの彼の動画をちょくちょく観るようになって、彼の霊能力が父親（シークエンスパパとも）譲りであり、パパともも息子のはやともに勧められて（癌闘病の傍ら）YouTuber として活躍していたのだが、残念ながら今年 1 月末に逝去していた、ということなどを知るようになった。 シークエンスパパともを知ったきっかけ はやとも流れでパパともの動画を観るきっかけになったのは、画面脇のお勧めに出ていた親子対談の動画を見たのが切っ掛けだった。 そこでのパパともの宮本武蔵に関するコメント（「晩年の宮本武蔵は一生懸命仏像を彫ったりしていたが、（若い頃）子供の道場主を殺したりしていたことによる怨霊は除霊できなかった」）に少しシビれた。息子のはやともが、まだ若いせいもあって、ちょっと話がマクロな（思想論や社会論的な）方向に行くと、厨二病的な傾向があるのには食傷気味な感じがあった。一方で、パパともの宗教・倫理観的な考えの方がその点、人間的な深さを感じるものがあったので、それがパパともに興味を引かれたきっかけだった。 パパともの霊能力に衝撃を受けた理由 そこで、初めて、パパとものチャンネルの動画もいくつか観たりしたのだが、「未解決事件を霊視する」という中々に攻めた企画を初期にやっていて興味深かったのだが、中に、上野の不忍池での事件（僕自身はこの 2006 年の事件については知らなかった）を扱ったものがあった： 「あっ！」と思ったのが、奇しくも前日（2023-06-28）、全く別のチャンネルの別の動画で、霊媒師が同じ事件を霊視するという企画のものを観ていたのだった： 千原せいじの YouTube チャンネルで、彼がコラボをしている飯島唯という通称・ギャル霊媒師の方が霊視をしている。 パパともの動画は 2021-05-12 と 2021-05-15 に公開されたものであるのに対し、ギ...
続きを読む

シークエンスパパともの先見の明

イメージ
先日、シンクロニシティ的に、故・シークエンスパパともが 2 年前に行った未解決事件に対する霊視が、ギャル霊媒師・飯塚唯が最近行った霊視と、互いに補完し合うような内容であるということを ブログ に 認 したた めたばかりである。 ところで、さらにもう一つの、パパともの霊能力に関する（僕にとって）シンクロニシティ的なタイミングで到来した情報が発生した。 シークエンスはやとものチャンネルの動画などを観るようになったのがきっかけで、YouTube のお勧めに、オカルト系のチャンネルが多数表示されるようになってきたのだが、その一つに「都市ボーイズ」という都市伝説を中心としたオカルト系チャンネルがあった。こういうものを観だしたらキリがないので、基本はスルーしていたのだが、その都市ボーイズ（放送作家の岸本誠と早瀬康広のコンビ）がチャンネルにはやともがゲストで出演して生霊鑑定を行っていたのを観たので、そこから芋蔓式に都市ボーイズのチャンネルの動画も何本か観たりするようになった。 都市ボーイズはやせの黒魔術 当初は、はやせ（早瀬康広）に「黒い呪いのようなものがまとわりついている」という、はやともの生霊鑑定の結果を深掘りすべく、関連する動画を追った。はやせは、呪物コレクターであり、その上、最近（約 10 ヶ月前に公開された動画）、「呪いを飼い馴らして、黒魔術的な力を自分のものにする」という修行というか通過儀礼を行っていたというのである。 儀式を無事に終えて台湾系の呪術師に合格が認められたはやせは、「数年以内に自動的に能力が開花し、自分で自覚するだろう」と言われたという。 都市ボーイズはやせを怒らせた霊能者 そのようなはやせを擁する都市ボーイズだが、先日、「【テレビの闇】インチキ霊能力者にテレビ出演邪魔されました！【インチキ霊能者】」という刺激的なタイトルの動画が、たまたま僕が暇だった時、公開されたばかりのタイミングで見つけてしまったので、早速その動画を観た。 約 1 年前、とある霊能者の霊的な〝脅迫〟によって、はやせはテレビ出演を直前で降板させられてしまったそうである。 僕は、テレビは観なくなって久しい人間で、それこそ霊能者というとシークエンスはやともの言う「心霊第 3 世代」の宜保愛子で止まっていて、江原啓之ですら雑誌の見出しで名前を...
続きを読む