はじめに

タイトルだけ読んでもピンとこない人のほうが大半だと思われるので、まずは今回行った実験の簡単な構成図を見せる。

構成図

上の図では、クライアント側が電話線を経由して、サーバー上にあるWebコンテンツを受け取るという仕組みになっている。
例えば一般のご家庭（~~逸般の誤家庭~~）にて、LAN内で一台Webサーバーを構築して、それをLAN内の端末と接続しようと考えた際に、通常であればLANケーブルを用いて接続する。
しかし今回の研究ではLANケーブルを使わずに、電話線で接続するという手法を用いて接続した。

なぜ電話線で接続できるのか？

結論から述べると、ネットワークインターフェイス層にPPPを用いれば電話線でエンドツーエンド通信ができ、さらにTCP/IPの階層モデルにてそれぞれのレイヤーが独立しているという特徴があるので、PPPを採用しながらアプリケーション層でQUICが使えるからである。

まずは復習も兼ねて、TCP/IPの階層モデルを見ていこう。

第1層：ネットワークインターフェイス層（Ethernet、PPPなど）
第2層：インターネット層（IP、ARP、ICMPなど）
第3層：トランスポート層（QUIC、TCP、UDPなど）
第4層：アプリケーション層（HTTP、SSH、SMTPなど）

以上4層がTCP/IPの階層モデルを構成するレイヤーである。
これらのレイヤーはそれぞれ独立して構成されているので、それぞれのレイヤーごとにプロトコルを定めることができる。
例えばトランスポート層にQUICを使った際に、現代では第1層にはほぼEthernetが選ばれる。Ethernetでは主にツイストペアケーブル（LANケーブルが代表例）が採用されている。しかし、それぞれのレイヤーがそれぞれ独立して構成しているという特徴から、第1層でPPPという別のプロトコルを用いても、トランスポート層では変わらずQUICを採用することができるのだ。

ところでインターネットネイティブ世代（かくいう筆者も）にとってPPPというプロトコルはあまり馴染みがないだろう。
PPPとは簡単に説明すると以下の通りである。

1対1でコンピュータを接続するプロトコル
主にダイヤルアップ接続などで用いられていた
- 電話回線レベルのコネクションを確立させたあとに、PPPのコネクション確立
物理層で使うものは定められていない
- 電話回線、ISDN、ATM回線、専用線など

以上の説明のうち、今回の実験で注目してほしいのが、最後の物理層で使うものについてである。PPPでは物理層で使うものは特段定められていないが、一般的に用いられているものはいくつか存在している。その中の一つとして「電話線」が挙げられる。つまりPPPを採用すれば、電話線でエンドツーエンド通信をすることができるのである。

以上の特徴から、ネットワークインターフェイス層でPPPを採用することで、物理層で電話線を採用しつつ、アプリケーション層でQUICを採用できるがゆえに、電話線を使ってQUICで通信できるのである。

実装

構成図1

今回はUSB接続型のモデムを使用することで、デジタルデータをアナログデータに変換をして、電話線でデータのやり取りができるようにした。

構成図2

クライアント、サーバーそれぞれにIPv6を割り当て、ルーターにはそれぞれ電話の内線番号である*1と*2を割り当てた。

PPP接続の設定

mgettyの設定

アナログモデムを接続したデバイスを常時監視
着信があった際にpppd（PPPを管理するデーモン）を起動

mgettyの起動設定（/etc/systemd/system/mgetty.service）

mgettyの設定（/etc/mgetty/mgetty.config）

PPPPの自動設定スクリプト（/etc/mgetty/mgetty.login）

pppdの設定

PPPを管理するデーモン

設定オプション（/etc/ppp/options）

PAP認証設定（/etc/ppp/pap-secrets）

Linuxのユーザー認証（/etc/pam.d/ppp）

なおPAP認証を用いた際、パスワードが平文で渡されてしまうセキュリティ上のリスクが存在するが、今回はLAN内での通信であること、実験で受け渡すWebコンテンツに機密情報が含まれないこと、今回の実験でのみ用いるシステムであることなどといった理由から、特段考慮するリスクではないと判断したため、PAP認証を採用した。

Nginxの構築

QUICに対応した1.25.0以上のものをインストールした。

Nginxの設定（/etc/nginx/conf.d/default.conf）

実行手順

Systemdに新しいサービスとしてmgetty、Nginxを追加して起動
Windows側からPAPで設定したユーザー名とパスワード、内線番号を使ってPPP接続を確立させる
クライアント側からサーバー側にブラウザを使ってHTTP接続をする
- Hostsを使って”myserver.com”でアクセスできるようにした
- 自己署名証明書を発行したうえでTLS接続を行った

PAPで設定したユーザー名とパスワード、内線番号を使ってPPP接続

実行結果

サーバーから返されたWebコンテンツ

通信情報1

通信情報2

実行結果より、通信においてアプリケーション層でHTTP/3、TLSv1.3が使われていることから、QUICでの通信に成功していることがわかる。

おわりに

いかがだっただろうか。
インターネット黎明期に普及していたPPPと、令和以降に普及し始めたQUICを組み合わせた通信というなんとも奇妙なものであったが、TCP/IPプロトコルにおいて、レイヤーごとの機能が独立している恩恵を肌身で感じることができる、良い経験になったと思った。
ただPPPに関して説明しているサイトがかなり限られていたことから、PPPの設定には一番労力を費やした（ダメ元でChatGPTにもPPPの設定について聞いてみたところ、想像以上に精度の高い回答を得ることができ、構築するうえではかなりの助けになった）。
またNginxを用いてQUICサーバーを構築する知見を得ることができたのも、個人的にはかなり大きな学びであった。