OpenVPN のパラメータ調整をする

　つい先日にやっとこさで導入した VPN 環境だが、サーバーやクライアント接続ログを眺めているとちらほらと WARNING なんて表記が目に付いてきた。
　極力こう言った不安定要素を削るべく、サーバーとクライアント接続で良い結果の出るパラメータ調整をする事とした。

発生しやすい WARNING

　先ずは MTU の不一致による WARNING。
　そのログを抜粋すると次の様な物が出る。

WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1378)

　これは mssfix と fragment の片方若しくは両方とも使用している場合、tun-mtu が 1378 になっている物を 1500 にしてね。という注意となる。別にエラーではないので接続して通信する事は可能だが、MTU にズレがあれば通信速度に影響が出てくるのでなんとか解消したい。
　個々のネットワークで設定されている MTU 次第では最適とされる値は変わるかも知れないが、どう言った設定で解消出来たかというと……

tun-mtu 1500
fragment 1280
mssfix

　と、サーバー/クライアント共に同じ設定を行ったら件の WARNING は出なくなった。
　tun-mtu でも link-mtu でもそうだが、大きすぎず小さすぎずと言った具合で結構調整が面倒臭い。サーバーとクライアントの設定を合わせる必要も有るから尚更だ。

　調整中にはこんなエラーがダラダラと結構な勢いで垂れ流れたりも。

FRAG_IN error flags=0xfb00003d: bad fragment size
FRAG_IN error flags=0xfb000037: FRAG_TEST not implemented
FRAG_IN error flags=0xfb00003c: spurrious FRAG_WHOLE flags

暗号方式の WARNING

　OpenVPN で接続が成功した当初は良く出た物で、Android 版 OpenVPN クライアント側で cipher の指定は手動で行うかプロファイルに予め記述しておく必要があった事が原因で、これは後から気がついた。

WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-256-GCM'
WARNING: 'auth' is used inconsistently, local='auth SHA1', remote='auth [null-digest]'
WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'

　サーバー側では AES-256-GCM なんて指定しておきつつ、Android 側では指定がないとデフォルトでは BF-CBC で暗号化しようとする。
　すると WARNING が出たあとにフォールバックが発生して最終的にはサーバー側指定の AES-256-GCM が使われるようになる。この間にフォールバックする分だけ接続完了までの時間が掛かるのでサーバー側はまだしもクライアント側の設定はしっかり確認しておこう。
　とは言えこれはログを見れば直ぐに対処可能なレベルだった。そもそも最初からちゃんと確認しておけという話しで。

その他調整項目

パケット圧縮アルゴリズム

　通信するときのデータを送出するときにパケットを圧縮し、データ総出量を削減することが出来る。
　色々なサイトを参考にしてみた限りでは comp-lzo を指定するケースが多かったので当初はそうしていたが、lz4 の方が高圧縮率という訳ではないにしろ圧縮する処理が圧倒的に早いアルゴリズムらしいとの事で切り替えた。
　標準でも lz4-v2 という記述がコメントアウトされていたが、こちらではちょっと不安定というか希に Warning が出たので使用は見送っている。

compress lz4
push "compress lz4"

# For compression compatible with older clients use comp-lzo                          
# If you enable it here, you must also                                                
# enable it in the client config file.                                                
;comp-lzo

クライアント同士の通信

　サーバー側の設定で client-to-client を有効にする。

# Uncomment this directive to allow different                                         
# clients to be able to "see" each other.                                             
# By default, clients will only see the server.                                       
# To force clients to only see the server, you                                        
# will also need to appropriately firewall the                                        
# server's TUN/TAP interface.                                                         
client-to-client

　次にルーター側でスタティックルーティングをして上げる。
　10.8.0.0/16 宛のパケットは 192.168～ に示される OpenVPN が動いているサーバーのアドレスに回すようにする。
　これをやらないと 10.8.0.0/16 宛のパケットをインターネットに向かって投げちゃうので、結局は経路的に最寄りの ISP 内サーバー辺りで消失する事になってしまう。よって出て行こうとする物を捕まえて LAN 内にぶん投げると言う事で。

　これをやったら Windows マシンからでも Android 端末に ping が通るし traceroute も出来た。別に Android 端末で何かやろうかって予定も無いのだが、脳内が OpenVPN に対してホットな時期にやっておいた方がいいかなというノリで。

OpenVPN の使い心地

　早速コンビニ等々、公衆無線 LAN の電波が飛んでいる所に行ってセキュリティ設定の無いオープンネットワークに繋ぎ、VPN クライアントから自宅内のネットワークへ接続が完了させる事を確認した。
　元々動作確認はキャリア回線でのみしか出来なかったので、無線 LAN 接続時にはどういう事になるかは未検証だった。問題無いようで一安心。

　セキュリティの確保されていない無線 LAN に接続して平文で通信するのはなんだか気持ちが悪いと思っていたから、今後は VPN で何の気兼ねなくオープンネットワークに繋ぐことが出来るようになったと。めでたしめでたし。

　速度的な物も特に気にするような遅延は感じられない。と言うよりも違和感を感じないのでかなり快適である。

おわりに

　今後はもう面倒臭いのでトラブルが起きないことを祈りつつ、外出先でもバリバリに使って活用して行こうかと思う。
　外からでも自室で動いているサーバー内や Windows マシンの共有フォルダへアクセス出来てしまうのは何かと便利である。