前回セットアップした OpenConnect VPNサーバへ Ubuntu から接続するにあたり、その適切なローカルサブネットの ルーティング 処理についてまとめておきます。
Ubuntu 18.04LTS Desktop版では、Network ManagerにOpenConnect VPNプラグインが用意されているので、これをインストールします。
1 |
S sudo apt install network-manager-openconnect network-manager-openconnect-gnome |
1. 単一なローカルサブネットから接続する
まずは単純に上図のように、一般的なケースを考えてみましょう。Network Manager からVPNを追加します。適当な名前を付けて、Gateway欄にVPNサーバを登録のみで適用とします。
作成したVPN接続先のトグルスイッチを押して接続を試みます。証明書の確認ポップは初回のみですが、DDNSを使う場合などでIPアドレスが変わると、このポップアップが再出されます。
続いてユーザID、パスワードを入力。これらはSave passwordsにチェックをしておくと、次回以降入力は省略されます。また、Log部分を開くとデバッグメッセージを確認することが出来るので、うまく接続出来ない時のトラブルシューティングに便利。
接続中はNetwork ManagerのVPNが点灯します。このVPNリストは画面上のIndicatorからアクセス可能なので、普段VPNをよく使う場合には、CLIよりも視覚的で便利です。
VPN有無でのルーティングテーブルの違いを見てみましょう。VPNを繋げることで、既存のデフォルトルートの上にトンネル行きのルートがごっそり乗っかって来るのがわかります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
## VPN OFF $ route カーネルIP経路テーブル 受信先サイト ゲートウェイ ネットマスク フラグ Metric Ref 使用数 インタフェース default _gateway 0.0.0.0 UG 600 0 0 wlp2s0 link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0 192.168.26.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0 ## VPN ON $ route カーネルIP経路テーブル 受信先サイト ゲートウェイ ネットマスク フラグ Metric Ref 使用数 インタフェース default 0.0.0.0 0.0.0.0 U 50 0 0 vpn0 default _gateway 0.0.0.0 UG 600 0 0 wlp2s0 link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0 192.168.26.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0 _gateway 0.0.0.0 255.255.255.255 UH 600 0 0 wlp2s0 192.168.100.0 0.0.0.0 255.255.255.0 U 50 0 0 vpn0 n21*********8.n _gateway 255.255.255.255 UGH 600 0 0 wlp2s0 |
2. 複数のローカルサブネットを有するLANから接続する
次に図08のような ローカル側に複数のサブネットが有る場合を考えてみます。この時、先程と同じように単にVPNするだけでは、トンネルがデフォルトルートになるので、ローカルLAN側に存在する自分以外のサブネットへのトラフィックも、トンネルへ放り込まれてしまいます。もちろんトンネルをデフォルトルートとせず、リモートLANへのアクセスのみに使用するようにすれば良いのですが、そうすると外向きトラフィックもトンネルを通らくなってしまいます。
この問題を解決するにはまずVPNではなく、ベースとなるネットワークインターフェイスに対し、ローカルLAN上に存在する自分以外のサブネットを全て明示的にルーティングします。要するに、トンネルに通したくないサブネットを列記するわけです。Network Manager上で設定するとこのように。
この上でVPNを接続してrouteコマンドでルーティングを見てみましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
## VPN OFF $ route カーネルIP経路テーブル 受信先サイト ゲートウェイ ネットマスク フラグ Metric Ref 使用数 インタフェース default _gateway 0.0.0.0 UG 600 0 0 wlp2s0 10.96.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 10.255.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0 172.16.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 192.168.0.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.2.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.21.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.22.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.26.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0 192.168.28.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.30.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.31.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.32.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 ## VPN ON $ route カーネルIP経路テーブル 受信先サイト ゲートウェイ ネットマスク フラグ Metric Ref 使用数 インタフェース default 0.0.0.0 0.0.0.0 U 50 0 0 vpn0 default _gateway 0.0.0.0 UG 600 0 0 wlp2s0 10.96.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 10.255.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0 172.16.0.0 _gateway 255.255.0.0 UG 600 0 0 wlp2s0 192.168.0.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.2.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.21.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.22.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.26.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0 _gateway 0.0.0.0 255.255.255.255 UH 600 0 0 wlp2s0 192.168.28.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.30.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.31.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.32.0 _gateway 255.255.255.0 UG 600 0 0 wlp2s0 192.168.100.0 0.0.0.0 255.255.255.0 U 50 0 0 vpn0 n2**********8.n _gateway 255.255.255.255 UGH 600 0 0 wlp2s0 |
これでVPN接続時もローカルLANに存在する他のサブネットへのアクセスも維持することが出来ました。
3. Open Connect VPNスピードテスト
VPN速度計測の前にまずは図08の左側、HKBNの商用1G回線単独の速度計測を実施してみます。デスクトップPCのGbEから、いくつかのギガビットスイッチを通り、UTMルータを経て外へ出る構成です。
次に図08の右側の自宅回線、HKTの集合住宅向けFiber1000M回線ですが所詮家庭用。ノートPCのGbEからGL-iNet GL-AR750SのLANポートへ直接繋いで計測しました。
ここで興味本位でFiberモデムに直接PCを接続し、同様に計測してみました。すると、
ルータ経由との大きな差にびっくり、立派なFiberでした。ルータのパフォーマンス改善については別途調べてみることにし、ここではFiberモデムとルータを繋ぐCat6AフラットケーブルをCat6Aフレキシブルケーブルに替えてみました。
本来ならば太くてしっかりしたケーブルが電気的には良いのでしょうが、経年変化で被覆がカチカチになるとコネクタ部に物理的な力が加わり続け、接触不良を引き起こす例をサーバルームで何度か遭遇したことがあります。そのトラウマから最近はネットワーク機器の接続には軟らかいケーブルを使っています。ケーブル交換後の再計測でその改善効果が確認されました。
以上の条件のもと、両者をVPNで繋ぎ、そのトンネル経由での速度計測を実施します。まずは、Open Connectの結果です。
次にOpenVPN(TCP接続)の結果です。
何度かn増計測してみましたが、両者ほぼ同等の速度でした。体感速度も大差ありません。また、導入に際しOpenConnectは前回の通り、Basic認証であればとても簡単に実現出来るので大変魅力的です。
これまで使っていたOpenVPNに代わりOpenConnectを数日使ってみました。OpenVPNの時はトンネルトラフィックの量に関わらず、接続確立中はルータのCPUロードが常に1.0以上(経常的に2.0前後)であったの対し、OpenConnectでは接続確立中であっても大きなトラフィックが無い限りCPUロードは0付近に張り付き、転送中も概ね2.0未満と軽快でしたので、メインはOpenConnectにしようと思います。