本記事は、同一ネットワークにないと使えないライセンスサーバを、外から使うにはどう考えるとよいかを述べているものになります。
ネットワークに詳しい人ならば、言うまでもなく秒でソリューションがわかるはずです。
対象は、外部に丸投げしていない企業のIT運用技術者、大学の研究室のネットワーク担当者向けで、めっちゃ詳しい！ではない方むけと思います。（詳しくない人が担当者なのか問題はおいておく）
背景
計算科学シミュレーションをするようなソフトウェア(著者の分野から見ているだけで、もちろんそれに限らない。)は、ネットワーク経由で使うフローティングライセンスが用意されていることが多いです。
これらのソフトウェアのライセンス管理には、FLEXlmというライセンス管理ソフトウェアがかなり広く利用されています。
一般的なコンシューマソフトウェアのように、シリアル番号やアカウント経由を認証する使い方ではなく、ベンダーに直接、利用するコンピュータの固有の情報を提供して、ライセンスファイルを発行してもらいます。
ちなみに、1本あたり、1M円~するようなお高いソフトです。個人で買うことはあまりないと思われますが、研究や業務で利用されている方は多いかと思います。
※ 技術的にできるできないの話が主眼ですので、契約上の法律問題は慎重に。
ライセンス認証の種類
一般にエンタプライズソフトウェアの提供形態として、以下の2種類があります。
企業経営的に考えると、実際に使うコンピュータが固定されてしまうと、壊れたときに面倒、設備更新したときに面倒、使うユーザが複数いるかも？などの理由で、フローティングライセンスを入れたくなります。実際に著者も、そのような経営判断を行うと思います。
フローティングライセンス （ネットワークライセンスとも）
利用するコンピュータを限定せずに、ユーザが起動する度にライセンスサーバに問い合わせにいき、ライセンスをチェックアウトすることで、クライアントコンピュータでの利用数を管理しています。
※ 2個同時起動できるライセンスのとき、2台までチェックアウトできる。
なお、ライセンスサーバ自体を複数用意されることを防ぐために、ライセンスサーバとなるサーバのMACアドレスをベンダーに伝えて、ライセンスファイルを発行してもらいます。
※ ここで、回避策が思いつく方はいらっしゃるかと思いますが、それはたぶん契約違反の可能性が高いです。
ノードロックライセンス （スタンドアロンライセンスとも）
利用するコンピュータを限定して、同時利用を防いでいます。特にネットワークカードのMACアドレスを、その認証に使うことが多いです。
※ 上記同 (略)
ソフトウェアの利用場面
近年、我が国においては働き方改革が推奨されており…、（その事実や、是非はともかく）、事業所外で勤務するような事例などもあるのでしょうか。
実際のところ、改革されてなかったり、最初からそうだよという声もあるかもしれませんが、リモートワークに限らなくても、客先に行っている間もリモートです。
つまり、業務アプリケーションは、事業所内のローカルで使うだけだと魅力も半減ではないでしょうか？
大学での研究室なら、当然来ないでも研究がしたいと思いますし、ニーズはより強いかと思います。
リモートで使う場合に困る点
フローティングライセンスだと、ライセンスサーバとクライアント間で、ネットワークでの疎通が出来ないと、ライセンスのチェックアウトが出来ないので、ソフトウェアを起動することができません。
つまり、リモートで使いたいという前提としたとき、どのようにライセンスサーバとの疎通をして図るかが重要になります。
FLEXlmの簡単な構造と利用する通信
FLEXlmでは、FLEXlmデーモンと、ベンダーデーモンの二種類のプログラムで構成されます。
FLEXlmデーモンを経由してベンダーデーモンを制御して認証を行います。
ベンダーから送られてきた *.licファイルを見てみますと、以下のような記述になっているかと思います。(参考)
SERVER [Hostname] 0011223344
VENDOR [VendorDaemon]
SERVER行は、lmgrd(FLEXlm)そのもののの、VENDOR行はベンダーデーモンについての記述です。
lmgrdは、ポート番号の変化は通常ありませんが、ベンダーデーモンのポート番号はデフォルトだとランダムに決定されます。
ランダムだと、何かと面倒なので、以下のように固定化してしまいましょう。
SERVER [Hostname] 0011223344 [Port#11]
VENDOR [VendorDaemon] port=[Port#2]
[Hostname]は、ライセンスサーバのhostnameに一致させ、lmgrd自体のポート番号を[Port#1]に書きます。
[Port#1]は、27000がデフォルトですが、書いておくと確実に固定化出来ます。
ベンダーデーモンは、port=[Port#2]の記述で固定化することができます。
ポートへの疎通の方法
上記の状況で、ライセンスサーバへ、[Port#1],[Port#2]のへのTCP通信ができればよいわけです。
ここでは、sshポートフォワーディングを使う方法を強く推奨しています。
他にもグローバルに公開する方法、VPNを使う方法も考えられるので記載しています。
sshポートフォワーディングを使う。
極めて簡単に、わりと安全に使える方法がこちらです。SSHのローカルポートフォワードを使います。
クライアントのローカルのポートを、ライセンスサーバと同じネットワークにあるSSHサーバを経由して、ライセンスサーバのポートに転送します。
ssh -L 27000:[192.168.0.XX]:27000 -L 27001:[192.168.0.XX]:27001 [ssh.abc.co.jp]
これだけで、クライアントのローカルの27000,27001はライセンスサーバの27000,27001と同じものを指しています。
従いまして、ライセンスサーバは自分自身というふうに考えればよいわけです。
@127.0.0.1
sshサーバが、一つあれば出来ますし、当然SSHサーバは公開鍵認証でやるのが当たり前ですので、そうやられているかと思います。
記事も豊富でかつ、VPN等より理解が簡単でかつセキュリティホールになりにくいのでオススメしています。
グローバルに開放する
ライセンスサーバをNATするか、グローバルIPをもたせてしまい、[Port#1],[Port#2]をインターネットに公開する方法です。
クライアントからは最も簡単に使うことが出来ますが、一方で誰でも使えてしまうというあまりよろしくない方法です。
見方をかえれば、同一ネットワークをインターネット(0.0.0.0/0.0.0.0)とみなしたことと同じですね。
クライアント側は、そのままサーバのIPアドレスかFQDNを指定すれば良いだけです。
@licence.test.co.jp
VPNを使う
ライセンスサーバがあるネットワークに、VPNで繋ぎます。L2でもL3でも良いです。
パスワードで認証するのは良くないので、最低限、クライアント証明書での認証は必須でしょう。
（セキュリティに色々いっておられる大手企業さんでもやってるかもですが、まともなネットワーク技術者なら避けたいです。）
ものによっては、通信をカプセルするために、TCPでもUDPでもないIPプロトコルを使います。IPSecなら、AH、ESP、IKEは理解しなければならないでしょう。色々と特殊なので、一般的にネットワーク技術者の中でもわかる人は限られるはず。
OpenVPNなどを使えばUDPで比較的容易に、OSSでも構築できますが、VPNサーバ自体運用の知識、証明書の管理ができるのなら問題ありませんが、運用は素人にはあまりおすすめできませんね。
ライセンスサーバのローカルIPないしはドメイン名を指定します。
@192.168.0.XX
OSS原理主義者なので、OSSのみで運用する方法を、そのうち記事公開するかもしれません。