仕事柄、あちこちへ出かけることが多かったのですが、コロナがはやりかけてからはトンと国外へ出かけることはなくなりました。政府もインバウンドの受け入れを積極的に再開したようなので、アウトバウンドもすぐに元に戻るかもしれません。以前は海外のホテルでの娯楽といえば、テレビの日本語放送一択でしたが、コロナ少し前からよく出会うようになった状況として、テレビで NetFlix などのストリーミングサービスの利用を行うようになっている状況によく出くわすようになりました。アイデアとしては好きな時に好きな映像を見ることができるので OK なのですが、私たちのように外国から来た宿泊客には問題があります。例えば、日本のサービスを日本語の環境で快適に利用しようとすると、海外からは接続できません 🙁 と怒られます。著作権か放映権かわかりませんが、基本怒られます。勿論デンマーク語で現地のワイドショー的な番組を見ていてもリラックスできると言う方には不要なのですが、私のような根っからの日本人には VPN の利用が不可欠でした。デンマークから会社の日本の VPN ゲートウェイに接続して、日本の Firewall 経由でいつものサービスを視聴せざるおえないようになりました。コンテンツプロバイダにとっては日本の IP アドレスからの接続に見えるので、拒否する理由がありません。この方法で普通に国内のサービスを視聴することができます。
前回はプライマリの KDC のみをセットアップして動作確認を行いました。その結果として次のようなファイルが /var/heimdal ディレクトリにあると思います。そして、DNS のサービスレコードで KDC のロケーションが得られると思います。
今回は KDC のバックアップを設定して、プライマリーセカンダリ間でデータベースをレプリケーションします。まず、セカンダリの package さんの /var/heimdal ディレクトリが空であることを確認します。
KDC として稼働させるためにデータベースを初期化します。勿論プライマリと同じ動きをしないといけないので、全く同じレルムとオプションを使用します。
さらに、同一のマスターキーを使用できるようにしないとバックアップとして機能しません。ですので、安全な方法でプライマリの /var/heimdal/m-key ファイルをコピーしてきます。以下一例です。私しか見ることができないディレクトリを作成して、そこにファイルをコピーします。cp コマンドを使用するとファイルパーミッションもコピーされてしまうので、そうならないように新しいファイルを作成して、中身だけをコピーします。
そして、package さんで sftp などを使用してファイルをコピーして、root でしか読み書きできないようにします。
これで package さんにはまっさらな KDC のファイルが準備できました。続いて、レプリケーションの準備をします。 現在の keytab ファイルには host プリンシパルが保持されています。
レプリケーションに使用する iprop のマニュアルを見てみると、使用するプリンシパルは iprop/host@realm を使用すると書かれています ( man iprop 参照 ) 。ですので、プライマリ用とバックアップ用にそれらのプリンシパルを作成します。
続いて作成したプリンシパルを keytab ファイルに取り込みます。まず、プライマリの dhcp さん。
そして、バックアップの package さん。
最後に、ログ関係を /var/heimdal ディレクトリのファイルから syslog に変更するための手順を踏みます。プライマリと同じ方法で同じようにログの出力先が変更できます。
自動で必要なサービスが起動するように sysrc で必要な変数を定義してゆきます。iprop のマニュアルを見る限り ipropd_master は引数なしでも起動するはずです。ただし、/var/heimdal/slaves ファイルにバックアップサーバのプリンシパルが書かれている必要があります。しかし slaves ファイルにバックアップのプリンシパルを書き込んで、ipropd_master_slaves 変数をセットせずに起動スクリプトを実行すると、この変数がセットされていないと怒られて動かないようなので、ipropd_master_slaves にバックアップの情報を定義します。そして、この定義した変数が毎度起動時に /var/heimdal/slaves ファイルにコピーされるようなので、定義すべき内容はバックアップのプリンシパルにする必要があります。こんな感じです。
/var/heimdal ディレクトリを確認します。’s’ で始まるファイルが３つ増えていると思います。slaves ファイルはバックアップ KDC のプリンシパルが格納されています。slaves-stats には最後に接続されたのがいつであるかの情報が書き込まれます。この段階ではバックアップからの接続は一度も行われていないので、時間情報は書き込まれていないはずです。
続いてバックアップサーバで KDC が自動起動するようにして、KDC を立ち上げます。そして、iprop の slave サーバを起動します。man iprop から引数にはプライマリサーバのマシン名を引数に取ると書かれていますので、/etc/rc.conf ファイルの変数としてとしてプライマリサーバのホスト名を指定します。
これで準備完了のはずなので、バックアップサーバを起動してみます。接続が成功すると、このようなログが記録されます。数字が順に増えていますが、これはプライマリサーバの KDC のデータベースのバージョンまで増加してゆき、同じになったら次の変更があるまで待機します。
さて、これで冗長性が確保されたはずなので、動作確認してみましょう。まずすべて動いている状況で krb5 さんで kinit を実行してみます。当然プライマリサーバからチケットを取得することができます。
では、障害をシミュレートしてみます。まず KDC が全く利用できない場合どのようになるか見てみるために、プライマリとバックアップの KDC を停止します。
この状態で持っているチケットを破棄して、新たに取得してみます。
エラーから KDC が利用できなかったとわかります。では、バックアップの package さんの KDC だけを起動します。dhcp さんの KDC は止まったままです。
この状態で kinit をもう一度実行してみると、バックアップサーバからチケットを得ることができました。
当然、このチケットはプライマリからのチケット同様に他のサーバでも有効であるはずです。ssh で確認してみます。
今回の実験ではバックアップでの読み出しのみの実験しかしていません。kadmind や kpasswdd を動かしていません。DNS の設定からこれらのロケーションもサービスレコードで知ることができるようになっています。ですので、DNS を適切に設定してバックアップサーバのサービスレコードを定義するとこれらのサービスの冗長性も保てるのかもしれません。man iprop を見る限りこの辺りの説明はありませんでした。もしこれが可能だとした場合、一番の不明点はプライマリがダウンしている間にバックアップでアップデートされた情報を iprop 間でスレーブからマスターにアップデートすることができるのかということころにあります。因みに Windows Active Directory のレプリケーションは双方向なので、どの KDC をアップデートしてもその変更は全ての KDC で利用できるようになります。今すぐには情報を持ち合わせておりませんので、わかりましたら別記事でご紹介できればと思います。
さて、もう一つ困ったのが中国出張中に個人的に日本の行政サービスについて調べようとしたのですが、中国からの接続はできませんの一点張り 🙂 これも同様に VPN 接続して日本の IP アドレスからの接続にして必要なことを調べる必要がありました。VPN といえば、社外から社内のリソースを使用するときに必要と思われがちですが、社外から社外のリソースを使用する時にも威力を発揮します。特に海外にいる時にはほぼつなぎっぱなしにしていた記憶があります。インバウンドの受け入れ再開とともにアウトバウンドも多くなり、VPN が必要な状況が個人でも起こるようになるんだろうと思います。そのようなときに会社の Firewall を使ったりするのもはばかられるでしょうし、VPN を受け付けるようにしていない会社もあると思います。嫁さんや子供たちに会社の Firewall への VPN を提供するかといえば、これはほとんどの組織で NO となります。特に最近はロシアーウクライナの戦争に端を発して、明示的に危険な国からの IP 接続を受け付けないように Firewall を設定変更したりして、ますますことような状況が加速していると思います。
そんな海外から帰国して国内の空港でスタバを飲みながら乗り継ぎの電車の時間を調べようと、Free WiFi に接続しました。この Free WiFI、これも危険が一杯なのをご存じでしょうか？仕事柄 SSID を騙って情報を不正に取得することなど簡単にできてしまいます。関空に到着して KIX-Free-WiFi などという SSID が iPhone 上に見えたら使ってしまうんじゃないですか？この Free WiFi、ほとんどが暗号化されていない状況で接続されます。もしパケットを見ることができる状況が発生すると、ネットワーク上の全ての情報が筒抜けになります。勿論私はそんなことはしませんが、ネットワークの知識がある人全てが善人とは限りません。
サイバーセキュリティの重要性が官民挙げて声を大にしている状況で、我々一般人も無知のままではすまなくなってきています。例えるならば、銃弾飛び交う戦場でヘルメットも防弾ベストもなくのんきに観光しているような状況です。わかりますか？弾がいつ何時あたるかわからないのです 🙂 しかも質の悪いことに、普通の銃弾なら血が出て痛いから病院となるのですが、これは銃弾が貫通していても気づかず、何週間も後に、多額の請求書が届いて即死してしまいます。あるいは、毎月抜かれる血の量はごく少量なので、気づかずにいつまでも寄生を許してしまうこともあります。このような状況を許す理由はなく、全てのネットワーク接続を暗号化して守る必要があります。
サーバーとの接続を暗号化する方法として広く使われている方法として、通信販売のサイトなどで、https://xxx と最初が https になっているサイトがあります。これはそのサイトとの通信だけを暗号化してくれます。でも、考えてみてください。それ以外の通信は殆ど丸裸です。この裸の王様に服を着せてくれるのが VPN です。我々ネットワーク管理者は自分で VPN を作ることができますが、普通の人には難しいと思います。そこでお勧めするのが市販の VPN 接続サービスです。VPN 接続サービスは世界各国で提供されていると思いますが、VPN を利用するシーンを考えると国内にあるサービスを利用する必要があります。海外のサービスを使うにしても国内に接続先のあるプロバイダの使用が重要となります。デンマークにいて、中国の VPN サービスを使用していると、Facebook が開けられないとか、google 検索できないなどの問題が起こります。ですのでセオリーは母国の VPN サービスを使用することです。以前 iPhone のバックアップを iCloud へとっていない状況で、ポケットに入れていた iPhone に適当な PIN が何度か入ったようで、きれいさっぱり内容がなくなったことがあります。月数百円程度のストレージ料金をケチったばかりにあちこちに散らばった情報をかき集めて復旧しなければならなくなったことがあります。たまたま Google Chrome を使っていて、パソコンと同期させていたので時間がかかりましたがパスワードも復旧することができましたが、これが無ければお手上げでした。VPN もそんなに高いサービスじゃありません。転ばぬ先の杖です。
以下広告
コメント