ページの先頭です

ページ内移動用のリンクです

ホーム
IIJの技術
セキュリティ・技術レポート
Internet Infrastructure Review（IIR）
Vol.66
2. フォーカス・リサーチ（1）リモートアクセスサービスの開発〜IDゲートウェイの変遷〜

Internet Infrastructure Review（IIR）Vol.66
2025年3月

目次

2. フォーカス・リサーチ

リモートアクセスサービスの開発
〜IDゲートウェイの変遷〜

2.1 はじめに

2024年9月末日、約26年間提供し続けてきた「IDゲートウェイサービス」がついに終了しました。1998年12月に開始^（注1）し、IIJ史上最も長期に提供していたサービスの1つとなりました。

「IDゲートウェイサービス」は「リモートアクセス」を提供するサービスです。リモートアクセスは遠隔地のコンピュータに接続する技術で、今や広く普及しているリモートワークに必須の技術です。現在では、リモートアクセスにはVPN技術が必須と考えられていますが、1998年のサービスリリース当初のIDゲートウェイサービスは、VPN技術を用いていませんでした。当時は拠点間のVPNでさえまだ普及の途上にあり、端末でVPNを行う実装は存在していましたが、実用的とはとても言えない代物でした。このような時代から、社会にとって必須の技術と言えるようになった現代に至るまで、IDゲートウェイサービスの歴史とともに振り返っていきたいと思います。

2.2 リモートアクセスサービスの始まり

IIJが「IDゲートウェイサービス」を開始した1998年ごろ、リモートアクセスといえば、Ascend MAXなどのダイアルアップ用のネットワーク機器を組織に設置し、そこに電話をかけ、PPPでIP接続することを意味していました。この場合のダイアルアップルータの意義ですが、インターネットに接続したいのならISPに接続することができるのですから、「内部につながる」ことが求められます。しかし、当時そういった機器は、ファイアウォールのようなアクセス制御ルールを書くことはできず、ほとんどなんの制限もなく内部のネットワークにつながっていたこともあったようです。

一方で、IIJは当時より内部ネットワークとインターネットは分離し、その境界にファイアウォールを置くことをユーザに推奨していたので、その裏口となるようなリモートアクセスは脆弱性そのものであり、IIJがサービスとして提供する場合には、リモートアクセスもまた、ファイアウォールと同様のアクセス制御ポリシーの中に収めるのが良いと考えました。また、ダイアルアップルータをユーザのネットワークに設置するのではなく、IIJのダイアルアップサービスを利用するよう設計しました。つまり、リモートアクセスのアクセス手段には既存のインターネットを用い、内部ネットワークへのアクセスにはファイアウォールのようなアクセス制御が必須であるという設計で、「IDゲートウェイ 1.0」は開発されました。

2.3 IDゲートウェイ 1.0

IDゲートウェイ 1.0は、アプリケーションレベルゲートウェイ型のファイアウォールをベースとして開発されました。ベースOSはBSD/OS 3.1でした。アプリケーションレベルゲートウェイ型のファイアウォールは、ファイアウォールを通過するすべての通信をプロキシが中断し、アクセス制御ルールに従い、許可する場合に限り以降の通信を中継するという動作をします。アプリケーションレベルで中継を行うため、HTTPやSMTPといったプロトコルを解釈して中継されます。このようなアプリケーションレベルゲートウェイ型のファイアウォールのアクセス制御部分を拡張し、PPPアカウントのユーザ名によって、宛先ごとに許可または禁止することを可能としました（図-1）。

図-1 IDゲートウェイ1.0の全体構成

このとき「ユーザを認証したのだから宛先はネットワーク全体に許可」というような大雑把なルールとならず、宛先ごとに許可することも多いと想定しました。それは、守るべき対象は接続ユーザだけでなく、宛先である組織内のサービスも守る必要があると、設計レビューや社内のβテストを通じて指摘されるようになったからです。きめの細かいアクセス制御を目指すことになりました。

もう少し詳細を見てみます。図-2の左下からのユーザのアクセス要求は、オペレーティングシステムを通じて「中継プログラム」（プロキシ）に伝えられます。このときプログラムにはユーザのソースIPアドレス、宛先のIPアドレスとポート番号が伝わり、中継プログラムはその通信がアクセス制御ルールにより許可されているものかを「ID認証デーモン」に問い合わせます。アクセス制御ルールはLink-ID（PPPアカウントのユーザID）で記述されているため、ID認証デーモンは、ソースIPアドレスからLink-IDへの変換が必要となります。ID認証デーモンは、前回の問い合わせがキャッシュとして存在すればそれを用いて直ちにソースIPアドレスからLink-IDへの変換を完了します。キャッシュに存在しない場合、「IDサーバ」と呼ばれるIIJのサーバに問い合わせを行います。ID認証デーモンとIDサーバ間の通信には「Link-IDプロトコル」というIIJで開発した独自プロトコルが利用されました。

図-2 IDゲートウェイ1.0のアクセス制御

Link-IDを得たID認証デーモンは、アクセス制御ルールと照らし合わせ、当該ユーザに対してアクセスが許可されているかどうかを判定し、許可/不許可を中継プログラムに返却します。これにより、アクセス制御ルールで許可されたリモートアクセスのみを許可することを実現しました。

2.4 IDゲートウェイ 2.0

2000年9月にリリースした「IDゲートウェイ 2.0」では、コンソールアプリケーションだった設定ユーザインタフェースを、「IDゲートウェイポリシーマネジャー」というグラフィカルユーザインタフェース（GUI）に一新しました。アクセス制御ルールを設定するためのアクセス制御ルールパネルは、アクセス制御ルールを分かりやすく設定してもらうにはどうしたら良いか議論を重ねた結果、最終的に図-3のように、スプレッドシートに○×を付けていくユニークなものとなりました。また、ベースOSもNetBSD1.4に変更されています。

図-3 IDゲートウェイ2.0のポリシーマネジャー

2.5 IDゲートウェイ 3.0

2002年4月にリリースした「IDゲートウェイ3.0」では、ついにL2TP/IPsec、PPTPといったPPPをベースとしたVPN接続をサポートします。しかし、当時この実現にはいくつもの壁を乗り越える必要がありました。

まずL2TPやPPTPといったトンネリングプロトコルを実装する必要がありました。当時、既存のオープンソースの実装は1トンネルごとに1プロセスを用いるプロセスフォーク型の実装で、この場合IDゲートウェイサービスの想定する規模ではプロセス数が数百となり、メモリを逼迫して利用することができません。IDゲートウェイ上のデーモンは1.0当初よりイベントドリブン型で実装していましたが、トンネリングプロトコルもイベントドリブン型で実装する必要がありました。実装はC++で、ゼロから行いました。

続いてL2TP/IPsecのIPsecの部分ですが、WIDEのKAMEプロジェクト^（注2）のIKEやIPsecの実装がNetBSDに取り込まれ、それを用いることができました。ただし1つ問題がありました。NAT越しにIPsecを利用するためにはIPsec NAT-Tを実装する必要があるのですが、NetBSD 1.4に取り込まれたバージョンにはその実装はありませんでした。IPsec NAT-Tを実装しない場合、まずUDPチェックサムが一致せず、それを回避してもNAT配下の1ホストしか接続できない問題が発生します。IDゲートウェイサービスでは、それを「先着一名問題」と呼んでいました。IDゲートウェイ 3.0では、先着一名問題は制限事項とし、UDPチェックサムが一致しない問題のみを解決することとしました。UDPチェックサムの問題は、受信時はESPのHMACによる確認があるのでUDPチェックサムの確認はスキップできるとして、スキップするようにしました。一方、送信時はオプショナルであるUDPのchecksumフィールドを0にして利用しないこととし、対向ホストでもチェックサムの確認がスキップされるようにしました。

PPTPについても、NAT越えで問題が発生する可能性があります。PPTPは、コントロール部分はTCPを、データ部分はGREを用います。コントロール部分はTCPであるためNAT越えの問題は発生しませんが、データ部分のGREはL2TP/IPsec同様に問題が発生する可能性がありました。ただし、GREヘッダのCall-IDを用いてNATマスカレードを行う実装が、コンシューマルータを中心に普及し始めていました。このため、L2TP/IPsecよりもPPTPの方が「先着一名問題」が起こりづらいと考えました。また、PPTPではパケットの暗号化にMPPEを用いることが事実上必須で、MPPEはプロプライエタリな暗号アルゴリズムであるRC4を利用します。このため、RSA Data Security社とのライセンス契約を行って使用許諾を得ました。

PPP部分の実装はiij-ppp^（注3）をベースとしたFreeBSDのpppが、Multi-PPPという複数の回線に複数のPPPを確立させるための拡張を行った結果、1プロセスで複数のPPPを終端できるようになっていたため、元々IIJが開発していたものでもあり、これを利用しました。

また、VPNの認証はどうするのかという課題もありました。通常のVPNサービスならば、まずはユーザのディレクトリサービスに接続して認証することを考えますが、IDゲートウェイの場合、2.0まではダイアルアップ接続をしていたのですから、既存のユーザはIIJのダイアルアップサービスを契約しており、接続ユーザにはPPPアカウントを発行済みで、アクセス制御ルールもそのアカウントで設定しています。VPNの認証もそのアカウントで行うことにすれば、既存のいろいろな部分が共通で利用できると考え、そのように実装しました。IDゲートウェイ上のPPPデーモンの認証リクエストは、ID認証デーモンによりプロキシされ、IIJのIDサーバ上のRADIUSサーバにて認証が行われる仕組みとしました。これにより、利用ユーザは同一のPPPアカウントを、ダイアルアップにも、VPNのL2TP/IPsecやPPTPのエントリにも、同じように設定することができました。アクセス制御の仕組みも図-4のように、従来とほとんど変わらない仕組みで実装することが可能になりました。このように従来のダイアルアップと同じようにVPNを扱えるようにしたため、IDゲートウェイサービスの中ではこれを「仮想ダイアルアップ」（VDIP）と呼び、従来のダイアルアップを「実ダイアルアップ」と呼ぶことにしました。

図-4 ダイアルアップ方法とアクセス制御

2.6 IDゲートウェイ 4

2005年7月にリリースした「IDゲートウェイ 4.00」では、「認証サーバ連携」機能を追加し、仮想ダイアルアップの認証サーバとして、Active Directoryなどのユーザ側ネットワークのRADIUSサーバやLDAPサーバを利用できるようにしました。また、リポートシステムを一新し、ルールビューア機能も追加しました。

2006年4月にリリースした「IDゲートウェイ 4.02」では、「SSLダイアルアップ」（SSLDIP）という新しいVPNプロトコルを実装しました。L2TP/IPsecやPPTPは、既に触れたようにNAT越しに利用した場合に問題が発生することがあります。また、制限された組織内のネットワークや海外のホテルなどからはHTTP、HTTPS、DNSなどの限られたポートしか許可されていないために、まったく利用できない場合もあります。一方で当時、SSL-VPN製品が市場に出始めており、SSLをトランスポートとするSSL-VPN製品はこういった問題がまったく発生しないため、IDゲートウェイにも同等の機能の実装が求められました。

SSLDIPはSSL（現在のTLS）をトランスポートにし、クライアントとIDゲートウェイ間でL2トンネルを作成し、その上でPPTPを行う設計としました。この狙いは、最終的なトンネルをPPPベースに揃えることで、その他の仕組み、認証やアクセス制御は従来と同一の仕組みが使えるようにすることでした。L2トンネルはオープンソースのOpenVPNを利用することにし、設定や接続管理を容易にするWindows用のクライアントも開発しました。

この他、IDゲートウェイ 4.02では、L2TP/IPsec、PPTPサーバ機能の実装をゼロから書き直して新しいデーモンにしました。元の実装は、VPNのトンネル処理部分がCではなく、C++で書かれており、SEIL（IIJ独自開発の企業向け高機能ルータ）シリーズ^（注4）など組み込みの環境への移植に問題がありました。また、従来はPPP部分は別のプログラムでしたが、これも必要最小限のシンプルなものに書き直し、それをVPNと同じプログラムに組み込んでしまうことで、性能向上や保守性の向上を狙いました。このプログラムがnpppd^（注5）で、後にOpenBSDに取り込まれるものです。また、RADIUS部分は元々IDサーバで利用していたコードを流用したものでしたが、それが現在のOpenBSDのRADIUSライブラリ^（注6）の原型となりました。

2.7 IDゲートウェイ 5

2008年3月にリリースした「IDゲートウェイ 5.00」では、「端末認証」機能を追加しました。VPN接続時の認証の他に追加の認証を行うもので、現在は「多要素認証」と呼ばれているものに相当します。「接続端末を限定したい」「パスワード漏えいに備えたい」といった要望に応える機能でした。IDゲートウェイの「端末認証」機能は、VPN接続後、端末認証を実施するまでは、DNSと認証ページにしかアクセスできないよう制限され、端末認証が成功すると、本来のアクセス制御ルールに切り替わる仕組みで、ID認証デーモン及び中継プログラムを機能拡張しました。このアクセス制限の仕方は、現在「キャプティブポータル」と呼ばれるものに相当します。認証の仕組みは、クライアントからのWebアクセスを認証ページに誘導した上で、認証ページ内のアプレットによりクライアント端末のMACアドレスをIDゲートウェイに送信させ、IDゲートウェイ上のデータベースにより、あらかじめ登録済みのMACアドレスと一致するのかを照合することで、VPNの認証ユーザが所有する正規の端末からの接続であることを確認する仕組みとしました。

この他、ホットスタンバイを実現するVRRP機能をSEILから移植する形で追加しました。また認証サーバ連携機能でEAP認証の利用をサポートしまた。

2009年12月にリリースした「IDゲートウェイ 5.02」では、オペレーティングシステムのソースコードをSEIL/Xシリーズのソースコードとコードベースを統一しました。これにより、IPsec NAT-Tが有効となり、長年の課題であったNAT配下で複数のユーザがL2TP/IPsecを利用できなかった問題が解消されました。ベースOSは NetBSD 3.1に変更されました。

2.8 IDゲートウェイ 6

2011年11月にリリースされた「IDゲートウェイ 6.00」では、新しいトンネリングプロトコルとしてSSTPをサポートしました。SSTPはMicrosoftが開発したTLS上で動作するプロトコルで、L2TP/IPsecなどと同様に、PPPフレームをトンネリングします。TLSベースであるためNAT配下からの接続時の問題もなく、クライアントもWindows標準に含まれるため、IIJ独自のクライアントを配布する必要がありません。また、PPPベースであるために認証部分やアクセス制御部分はそのまま流用することができます。SSTPは公開プロトコルであるものの、商用利用にはMicrosoftの使用許諾が必要で、契約を結びました。

2.9 IDゲートウェイ開発の終息と課題

仮想ダイアルアップを開始した当初の技術課題であったNAT配下からの接続時の問題も、5.02のIPsec NAT-Tのサポートと、6.00のSSTPのサポートをもって解消しました。しかし一方で、ユーザ1人当たり負荷は年々増加傾向で、要求される性能を1台では処理できないという状況が発生してきました。

まず要因として挙げられるのは、IDゲートウェイは当初よりアプリケーションゲートウェイのソフトウェアでありルータではなく、すべての通信はアプリケーションレイヤーで中継しており、基本的にIP転送は行っていないことです。IPレベルで転送する場合と比べ、どうしても負荷は高くなるのです。ケースバイケースでIPレベルでの転送にオフロードするような仕組みを持つべきでした。

次に要因として挙げられるのは、アプリケーションゲートウェイを提供する中継プログラムのソフトウェアがシングルプロセスで動作する設計であるため、CPUが複数あっても活用できない問題、マルチコア対応に問題がありました。

最後に要因として挙げるのは、ベースOSのカーネルです。IDゲートウェイの最後のバージョンのベースOSはNetBSD 3.1 ですが、ネットワークスタックのマルチコア対応は未着手で、中継プログラム同様、CPUが複数あっても活用できない問題、マルチコア対応に問題がありました。

これらの問題は個別の問題のようでいて、実はソフトウェアの陳腐化の表れに過ぎないと考えています。現在のソフトウェアはインターネットを通じてグローバルに進化を続けるものなので、放っておけば常に陳腐化していく宿命にあります。IDゲートウェイのソフトウェアの問題は、このようなソフトウェアの陳腐化について無策であったことだと振り返っています。

これらの課題をIDゲートウェイの延長として解決することは、様々な面で困難であると判断し、後継サービスである「IIJ GIO リモートアクセスサービス」と、「Tornado」という新たなIIJ内製のゲートウェイOSに役目を引き継ぎ、IDゲートウェイのソフトウェア開発は終息することにしました。

2.10 IIJ GIOリモートアクセスサービスとTornado

2013年2月、IIJ GIO リモートアクセスサービス（GAM）という新たなリモートアクセスサービスを開始しました。GAMはクラウド型のサービスで、VPNのゲートウェイはIIJのクラウド上で動作しています。VPNゲートウェイには、IDゲートウェイに代わり新たにIIJ内で開発していたTornadoを利用しています。

TornadoはIIJ内のネットワーク系のソフトウェアを機能統合するIIJ内製のゲートウェイソフトウェアで、OpenBSDをベースに開発しています。IDゲートウェイの後継となるような製品を作るためにベースOSに求められるのは、企業のファイアウォールとして利用可能なレベルのパケットフィルタ機能、透過プロキシのためのカーネル拡張が行えることですが、OpenBSDは開発開始当初の2011年時点でこれらすべてを実現可能でした。むしろ、アプリケーションでの中継処理からカーネル内の処理に戻すソケットスプライス機能や、ポリシールーティングなどを実現するVRF機能など、IDゲートウェイにも欲しかった機能が最初から利用可能でした。また、IDゲートウェイ由来のnpppdも取り込まれていました。

Tornadoでは、中継プログラムはマルチコア対応の新しいデーモンに差し替えました。また、アクセス制御ルールにおいて、アプリケーションレベルで中継するか、パケットフィルタによりIPレベルで転送するかは、単に1つの設定項目として切り替え可能としました。

IDゲートウェイとTornadoの大きな違いとしては、IDゲートウェイはIDゲートウェイサービス専用のソフトウェアだったのに対し、Tornadoは汎用のソフトウェアである点です。サービス固有で共通化できない機能は、オプショナルなパッケージとして開発する設計となっています。サービス固有の機能は、比較的代謝が激しく、常に新しいものが求められ、古いものは廃れていく傾向があります。こういったものを取捨しやすい設計としました。

2024年12月、GAMでは、新たなVPNプロトコルIKEv2による接続をサポートしました。IKEv2はPPPベースのプロトコルではないため、当時のOpenBSDのIKEv2のデーモンでは認証やアクセス制御の仕組みが他のプロトコルのものを流用できませんでした。この問題を解決する際、PPPベースのものとまったく別の仕組みを作ってしまうと、2つの別々の方法を管理保守していくことになります。Tornadoでは、IKEv2のデーモンにRADIUS認証及びアカウンティング対応を機能追加することで、仕組みを共通化することにしました。認証をRADIUSにして一元化し、それだけでなく、図-5のようにローカルのRADIUSデーモンがVPNに払い出すIPアドレスを一括して管理することにより、PPPベースのVPNもIKEv2も同じようにアクセス制御の仕組みが動作するように実装しました。

図-5 IKEv2を用いた接続の全体構成

内部ではTornadoバージョン 4.5が利用されますが、これは約1年前にリリースされたOpenBSDをベースOSとしており、比較的新しいバージョンを利用できていると言えます。IDゲートウェイの反省から、継続的インテグレーションとして、定期的にベースOSのバージョンを更新し続けているため、ベースOSが古いバージョンで停滞することはなくなりました。

2.11 まとめ

振り返ってみると、IDゲートウェイは当初より単なるリモートアクセスを提供するサービスではなく、PPPアカウントにより認証し、その認証IDに対してアクセス制御ルールで許可された通信だけが行える、といったセキュリティ機能を提供していました。また、IDゲートウェイ 5でデバイスレベルの認証を加えました。これらは、現在でいうZero trust architecture（ZTA）の考え方そのものです。

IDゲートウェイからIIJ GIOリモートアクセスサービスへの歴史は、IIJ内製のソフトウェアの開発の歴史でもありました。TornadoはIDゲートウェイを引き継ぐ現在進行形のIIJの基盤ソフトウェアです。今後も新たな技術に取り組んでいくことはもちろん、ユーザのニーズの変化、社会情勢の変化にも対応してより良いサービスを提供できるよう尽力していきます。

（注1）「IDゲートウェイサービスを開始」、iij.ad.jp、IIJ（参照1998-10-02）（https://www.iij.ad.jp/news/pressrelease/1998/pdf/gateway.pdf）。
（注2）KAMEプロジェクト（https://www.kame.net/index.html）。
（注3）IIJの大野らが開発したオープンソースのPPP実装。1990年代後半から2000年代前半にはBSDユーザを中心に広く利用された。
（注4）SEIL（https://www.seil.jp/）。
（注5）src/usr.sbin/npppd/、github.com、GitHub（https://github.com/openbsd/src/tree/8b2d863473/usr.sbin/npppd/）。
（注6）src/lib/libradius/、github.com、GitHub（https://github.com/openbsd/src/tree/8b2d863473/lib/libradius/）。