SSHでVPNを張れるらしい

こんにちわ、久しぶりの投稿です。

仕事でL2TP/IPsecなVPNを構築しているのですが、インストールや設定などの手間がそこそこ掛かるので、良い感じにお手軽なVPNは無いか調べていました。

すると、我らがSSH大先生でVPNまで張れちゃうとの情報を入手したので、早速試してみることにしました。

SSH万能すぎん？🤔

# 解説
- [SSH Tunneling - ssh.com](https://www.ssh.com/academy/ssh/tunneling)

SSHには **SSH Tunneling** という仕組があり、それを利用することでVPNを構築できます。

重要なのは「ベースはSSHだが独立した仕様」ではなく「SSH本体機能の一部」なので、普通に `ssh` コマンドを叩いてトンネリング有効化のオプションを付与すれば、ポートも認証方式も暗号化も、そっくりそのままVPNを張れるのです。

通常のシェル接続で使用するコネクションやチャネルをそのままトンネリング接続へ転用しているため、技術的には全く同じものとなります。

### 接続までの流れ
実際に行っている処理は、だいたい下記のようになります。

1. ローカル・リモート間でコネクションを確立
2. コネクション内でチャネル0をオープン (シェル用)
3. ローカルとリモートへそれぞれVNICを生成
5. コネクション内でチャネル1をオープン (トンネリング用)
6. チャネル1の両端をVNICで終端
7. トンネル開通

```text:イメージ図
     [Terminal]  [VNIC]  [Shell]
           ||      ||      ||
{ -------- SSH Client -------- }
       |   ||      ||   |
       |   Connection   |
       | <Ch:0>  <Ch:1> |
       |   ||      ||   |
{ -------- SSH Server -------- }
           ||      ||
        [Shell]  [VNIC]
```

このうち (2) までは、シェル接続とトンネリング接続で同じ挙動となります。
普通にSSH接続する場合はチャネル0を使用してリモートのシェルを操作するだけで事足りるためです。

そして (3) からが、トンネリング接続でのみ行われる処理となります。
と言っても難しい話ではなく、SSHクライアントがローカル (直接) とリモート (チャネル0経由) のシェルへ接続してコマンドを叩き、VNICを生成しているだけです。
VNIC生成の時点で新たにチャネル1が開かれ、チャネル1の両端がVNICで終端されることで、晴れてローカルとリモートを結ぶトンネルが完成となります。

### プロトコル
VNIC (仮想ネットワークデバイス) として **Tun** / **Tap** を利用することから、トンネル内のプロトコルは **PPP** もしくは **Ethernet** のどちらを使用するか選択できます。

なおパケット構造については、ローカル・リモート間を往来するのはあくまでSSHパケットなため、データ本体が格納されるエリア (ペイロード) へEthernetやIPのフレームが丸ごと乗っかり、カプセル化されます。

そのため、L2TP/IPsecやOpenVPNなどの専用プロトコルと比較した場合、オーバーヘッドは大きい傾向にあります。
まぁ何より、環境を選ばず手軽に扱えるのがウリなので、効率を求めるなら専用プロトコルを使えば良いだけの話です。

```text:イメージ図
-----------------------------------------------
|                 SSH Packet                  |
|   HEADERS   |    Payload(Data)    | PADDING |
-----------------------------------------------
              |   Ethernet Frame    |
              | HEADERS |  Payload  |
              -----------------------
```

# 注意事項
非常に使い勝手の良さそうなSSH Tunnelingですが、1点だけ注意が必要です。

ローカルとリモートの双方でVNICを操作するため、ローカルとリモートのどちらも、ルート権限での実行が必須となります。

SSHサーバーの初期設定値を見てみると、ルートアカウントへのログインはパスワード認証以外で可能、つまり公開鍵認証や証明書認証などの非対称でセキュアな認証方法でのみ可能となっています。
その制限を緩めてパスワード認証でルートログインを許すことは無いと思いますが、公開鍵認証を使用する際も注意を払う必要があります。

例えば公開鍵認証の場合は、使用する暗号アルゴリズムを **ED25519** / **X25519** などの強固な物のみ使用すうよう明示的に設定したり、それらの暗号アルゴリズムが実際にどう振る舞うのかをよく調べてから使用するようにしましょう。

(この辺の暗号技術については元気があったら別途記事にしようと思います)

```ssh:sshd_config
PermitRootLogin prohibit-password
```

# 実際に接続してみる
ざっくり解説も済んだところで、早速繋いでみたいと思います。

まずSSH Tunnelingを使用するにあたり、そこまで大掛かりではありませんが、いくつかの設定変更が必要となります。

なお、ポート開放やファイアウォール制御については、繰り返しになりますが、あくまで往来するのはSSHパケットそのものなので、既にSSHが接続できる環境であれば変更は不要です。

### サーバー設定
サーバー側は `sshd_config` の **\<`PermitTunnel`\>** を変更するだけです。

**\<`PermitTunnel`\>**
クライアントからのトンネリング接続要求を制御します。

1. `yes` ... クライアント側でPPPまたはEthernetを選択可能
2. `point-to-point` ... PPPのみ許可
3. `ethernet` ... Ethernetのみ許可
4. `no` ... トンネリングを拒否 (デフォルト値)

```ssh:sshd_config
PermitTunnel yes
```

設定を変更したら、デーモンを再起動して準備完了です。

```sh
systemctl restart sshd
```

### クライアント設定
クライアント側は `ssh` コマンドを叩くときにオプションとして全ての設定を指定できます。

しかし、設定項目が多く毎回入力は面倒なので、トンネリング接続用のプロファイルを `~/.ssh/config` に作っておくと便利です。

```ssh:~/.ssh/config
Host (name)
    HostName (host)
    Port (port)
    User (user)
    PubkeyAuthentication yes
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    PreferredAuthentications publickey
    Ciphers chacha20-poly1305@openssh.com
    KexAlgorithms curve25519-sha256@libssh.org
    MACs hmac-sha2-512-etm@openssh.com
    HostKeyAlgorithms ssh-ed25519
    StrictHostKeyChecking no
    Compression yes
    IdentitiesOnly yes
    IdentityFile (~/.ssh/key)
    Tunnel ethernet
    TunnelDevice 0:0
    PermitLocalCommand yes
    LocalCommand ifconfig tap0 10.0.0.2 netmask 255.255.255.0
    RemoteCommand ifconfig tap0 10.0.0.1 netmask 255.255.255.0
```

これは私の使い回し用テンプレです。

暗号アルゴリズム周りは、狙った物へ誘導するために1種類へ絞っています。
「誘導」と言ったのは、SSHで実際に使用される暗号アルゴリズムは、クライアント側とサーバー側がそれぞれ持っている複数の候補の中からネゴシエートされるためです。
クライアント側から候補を1個しか提示しなければ、サーバー側はそれを使わざるを得ません。

そして、トンネリング接続に関係する項目は下記となります。

**\<`Tunnel`\>**
VNICとしてTunまたはTapのどちらを使用するか指定します。

1. `ethernet` ... Tapを使用
2. `point-to-point` ... Tunを使用

なお、サーバー側の **\<`PermitTunnel`\>** をどちらかへ制限している場合、クライアント側の **\<`Tunnel`\>** と合致しない場合、接続要求は拒否されます。

**\<`TunnelDevice`\>**
VNICを生成する際のデバイス番号を指定します。

`0:0` のように記述し、左値はクライアント側で右値はサーバー側のデバイス番号となります。

**\<`PermitLocalCommand`\>**
接続完了後に、後述の **\<`LocalCommand`\>** で記述したコマンドの実行を許可するかを選択します。

1. `yes` ... 実行を許可
2. `no` ... 実行を拒否

**\<`LocalCommand`\>**
**\<`RemoteCommand`\>**
接続完了後にローカルまたはリモートのシェルで実行するコマンドを記述します。

ここでは、接続時に生成されたVNICへIPアドレスを割り当てています。
他にも、IPマスカレードやルーティングなどもここへ記述できるため、活用の幅が広がります。

### 鍵生成
この辺は既出情報が豊富なため、本記事に必要か迷いましたが、使用する暗号アルゴリズムについて少し触れたので、ついでに載せておきます。

```sh:ssh-keygen
ssh-keygen -q -t ed25519 -N "" -f ./(key)
```

これも私の使いまわし用テンプレです。

2021年現在、公開鍵はとりあえずED25519/X25519を使用しておけば、まず間違いは無いと思います。

### 接続
さて、いよいよ接続です。

`ssh` コマンドをルート権限で実行しますが、ここで注意したいのは、ルート権限で実行した場合にデフォルトで読み込むコンフィグファイルは `~/.ssh/config` ではなく `/etc/ssh/ssh_config` となります。

そして `sudo` コンテキスト内では `~` が指し示すディレクトリは置き換わるので、ホームディレクトリ配下にアクセスしたい場合はフルパス指定が必須となります。

そのため `-F` オプションを付与し、コンフィグファイルの読み込み先をフルパスで指定する必要があります。
プロファイルの **\<`IdentityFile`\>** がフルパスで指定されているのも同じ理由です。

```sh
sudo ssh -Nq -F /home/(user)/.ssh/config (profile)
```

コマンドを入力し、何も応答が返らなかったら接続成功です。

応答が返らない間は、常にトンネリング状態となります。
トンネリング状態を解除 (切断) したい場合は `CTRL+C` で切断できます。
なお、VNICは切断時に自動で削除されるため、切断後の手動削除は不要です。

`ifconfig` や `nmcli connection show` などでネットワークインターフェースを確認すると、IPアドレス付与済のVNICが生成されていると思います。

もしインターフェースが見当たらなかったら、どこかで接続が失敗しています。
`-vvv` オプションを付与し、ログを確認してみてください。

# おわりに
今回はVNICを使ったVPNでしたが、思ったより簡単に動いて驚きました。
SSHは他にも **ポートフォワード** というVPN機能があるので、今度はそちらも試してみたいと思います。
ポートフォワードはVNICを使用せずルート権限が不要なため、敷居も下がるかと思います。

いやSSH万能すぎん？？？🤔🤔🤔

# 参考 - 公開鍵暗号の強度
参考として、各種公開鍵暗号の強度について載せておきます。

複数の暗号アルゴリズムを組み合わせた場合の最終的なセキュリティ強度は、その中で最低強度のアルゴリズムへ依存します。

例えばRSA-2048 (112bit) とAES-256 (256bit) を組み合わせた場合、総合的な強度は112bitとなります。

|公開鍵|種類|強度 (bits)|備考|
|:--|:--|:--|:--|
|RSA-2048|RSA|112|や め と け|
|RSA-3072|RSA|128|演算が非効率的 (遅い)<br>古代遺産にも対応<br>ECCが使えないとき用|
|NIST-P256|ECC|128|演算効率重視のパラメータ<br>NISTを信頼できるか否か|
|NIST-P521|ECC|260|`2^521-1`なので超高速<br>(P256より速いらしい)<br>AES-256の強度が損なわれない<br>NISTを以下略|
|ED25519<br>X25519|ECC|128|2021年現在のトレンド<br>脆弱性を回避した設計<br>鍵長が短い割に高強度|
|ED448<br>X448<br>(Goldilocks)|ECC|224|25519の上位互換<br>2021年現在まだ普及していない|

RSAは鍵長が長い割に強度が低いうえ、鍵長を増やすと演算負荷も極端に増えるため、最近ではあまり使われなくなってきています。

NIST系は演算効率に特化しているのが特徴ですが、過去NISTはバッグドア疑惑など色々とグレーな問題を起こしてきたようで、その点において信頼できるか否かは、皆さんの判断によると思います。

ED25519はツイストエドワーズ曲線、X25519はモンゴメリ曲線という異なる楕円曲線を利用していますが、この2曲線は、あるパラメータ (下記) の時に同値となる双有理同値という性質を持っています。