2018年2月26日月曜日

無料で使えるサーバ証明書「Let's Encrypt」を使って、QNAP NASの接続をHTTPS化する

自宅で使っているQNAPのNASは、外出中にファイルを閲覧したい場合があるため、DDNSを使って、インターネットからのHTTPS通信を許可する設定を入れている。

HTTPS通信を行う場合、サーバー証明書の導入がWebサーバーに必要となるが、通常数万円以上の費用が発生することから、導入はせずに運用していた。

しかし、「Let's Encrypt」という無償で使えるサーバー証明書サービスがあり、QNAPでは簡単に導入できる仕組みが備わっていることがわかった。導入の際に特にデメリットはなさそうなので、今回「Let's Encrypt」のサーバー証明書を導入してみることにした。

Let's Encryptとは

Let's Encryptの動作概要は公式サイトにてまとめられている。

・Let's Encrypt の仕組み
https://letsencrypt.jp/technology/

さらにまとめると、以下のような特徴があるようだ。
  • 無料
  • 証明書管理エージェントをサーバーに導入して、自動的に証明書の発行・更新・失効を管理する
  • 証明書の有効期限は90日と短い。ただし、証明書の更新は自動で行うことができるため問題はなく、Let's Encryptではさらに短くすることも検討している
上記のように、今まで人の手で対応していた発行作業はすべて自動化できるようになっており、これが無料化を実現できているポイントのようだ。

QNAPでの導入方法

今回導入したQNAPのQTSのバージョンはとなる。
  • QTS : 4.3.3.0404 (2017/12/13)
  • CloudLink : 2.0.88 (2017/11/14)
設定は、QTS上のCloudLinkにて実施する。事前にmyQNAPcloudのDDNSを利用しドメインを取得していることが前提となる。

CloudLinkの「Overview」を開くと、以下画面のように、SSL証明書はインストールされていない状況となっているはず(当然、個人でお金を払ってサーバー証明書をインストールしている場合は別である)。


CloudLinkの「SSL証明書」を選択する。以前は、「myQNAPcloud SSL Certificate」しか選択肢がなかったが、現在は「Let's Encrypt」が表示されるので、「ダウンロードしてインストールする」を選択する。


ドメイン名はDDNSで登録済みのドメインが表示されるので、登録用のメールアドレスを入力する。myQNAPcloudで登録したメールアドレスと同じもので問題はないだろう。


登録処理が開始されるので、しばらく待機する。


完了すると、以下画面のようにSSL証明書の状態が「アクティブ」になる。有効期限は90日後で設定されている。


 CloudLinkの「Overview」を再度開くと、SSL証明書が有効になっていることが確認できる。


実際にブラウザでQNAPのアドレスに接続確認をしてみると、以下の通りhttpsで正常に接続できることが確認できた。証明書の詳細情報を確認すると、認証局がLet's Encryptとなっているサーバー証明書であることも確認できた。


前述したとおり、Let's Encryptの証明書は90日で期限が切れるため、実際に期限となった際の挙動についても別途確認してみたいと思う。

参考

・Let's Encrypt
https://letsencrypt.jp/



2018年2月17日土曜日

CyberPowerのUPS「CPJ500」を導入してQNAPのNASに接続した話

冬になると電子レンジなどの調理器具だけでなく、エアコンや電気ヒーターも同時に使用するようになるため、ブレーカーを落としてしまうことが何度かあった。自宅ではNASや検証用途に利用している常時稼働のPCがあり、復旧対応の負荷が結構大きいことから、UPS (無停電電源装置)を導入することにした。

製品選定

さっそくUPSをAmazonで調べ、以下理由からCyberPowerの「CPJ500」を選定した。

・安価であること
・USBで制御が可能なこと
・コンセントが4口ではなく6口あること



同価格帯ではオムロンのUPSもあり候補に挙がったが、こちらはコンセントが4口となっていることがネックとなる。自宅環境では4口では不足することから、CyberPowerのUPSを購入することになった。

QNAPのNASとUSB接続してみる

本UPSをQNAPのNASとUSB接続すると、NAS側からUPSの状態を確認することができ、万が一停電時になった際は、自動でNASをパワーオンすることが可能になる。

設定方法は簡単で、UPSに付属するUSBケーブルを使ってUPSとNASを接続すれと、自動でNAS側でUPSを認識する。
※NASにて「USB UPS device plugged in」のメッセージが表示される


NSAにログインし、「コントロールパネル」→「外部デバイス」を選択し、UPSタブを開けば、「UPS情報」欄にUPSのバッテリー情報や、バッテリーを利用した際の推定稼働時間が表示される。


UPS異常時の動作確認

ためしにUPSの電源を抜き、バッテリーでの電源供給に切り替えてみたところ、NAS側でUPSを「異常」として認識した。


UPS異常となった際と、UPSが正常に復旧した際には、NASにて警告メッセージが表示される。

・異常時:Power loss detected on UPS. System would be shutdown after 5 minute(s).
・復旧時:Power has returned to UPS. Canceling shutdown.


NASにてSNMP Trapの設定をしておけば、監視装置にUPS異常のTrapを飛ばすことも可能である。以下は、UPS異常時のTrapをZabbixで検知した際のメール通知の内容となる。

【異常時】
------------------------------
2018.02.12 06:42:01

Trigger: SNMP Trap
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values:

1. SNMP Trap log (t3013qnap:snmptrap[]): 06:41:58 2018/02/12 .1.3.6.1.4.1.24681.1.10.0.2 Normal "Status Events" 192.168.33.13 - Power loss detected on UPS. System would be shutdown after 5 minute(s).
------------------------------

【復旧時】
------------------------------
2018.02.12 06:44:01

Trigger: SNMP Trap
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values:

1. SNMP Trap log (t3013qnap:snmptrap[]): 06:43:55 2018/02/12 .1.3.6.1.4.1.24681.1.10.0.2 Normal "Status Events" 192.168.33.13 - Power has returned to UPS. Canceling shutdown.
------------------------------

これでブレーカーが落ちた際にも、いちいちNASやサーバーの起動が不要となり、安心して冬を過ごすことができるようになった。特にNASに関しては、様々なデータが保管されており、停止に伴うデータ破損の影響が大きいため、データ保護の観点からも安心材料を得ることができた。

2018年2月13日火曜日

Amazon EchoがWi-Fiに接続できない場合の対処手順

先日、Amazon Echoの招待メールを受け取ったので、さっそく購入してみた。

Andoroid端末にAmazon Alexaアプリをインストールして初期セットアップを進めていたのだが、Wi-Fiの設定箇所で、いくら正しいパスワードを入れても接続に失敗する事象が発生した。

失敗時のメッセージは以下となるが、Wi-Fiに接続できなかったと表示されているだけで、原因については記載されていない。何度か接続をリトライしても同じ事象が発生したため、再現性はあるようだ。

------------------------------
Your device was unable to connect to your Wi-Fi network. Please exit setup and try again. Visit Help for troubleshooting tips.
------------------------------


Webでもは類似事象が多数報告されている。失敗した端末とは別の端末を使ったら接続できたとか、何度も接続作業を繰り返したら成功したとか、そのような内容が多いように見える。

結果的に私の環境では、Androidのアプリではなく、PCを使ってAlexaのWeb画面でWi-Fi接続設定をすることで成功したが、簡単には成功しなかったので、本記事で手順をまとめておく。

環境

・Wi-Fiルーター:NEC Aterm WG1800HP2
・無線方式  : IEEE802.11ac (5GHz)
・暗号化方式 :WPA2-PSA(AES)

Amazon Echo Wi-Fi接続手順

1. Amazon AlexaのWebサイトにログイン

まず、以下URLにアクセスする。ログインIDとパスワードの入力を求められるので、Amazonと同じものを入力してログインする。

https://alexa.amazon.co.jp/

2. 新しいデバイスを追加

左メニューの「設定」を選択し、「新しいデバイスをセットアップ」を選択する。


3. セットアップするデバイスを選択

セットアップ対象の機器を選択する。今回は「Echo」を選択した。


4. 言語を選択

「日本語」を選択する。


5. Wi-Fi接続設定の開始

「まずWi-Fiに接続しましょう」と言われるので、「Wi-Fiに接続」ボタンを選択する。


「computerとEchoを接続」の画面が表示される。このタイミングより、Amazon Echo本体がWi-Fiのアクセスポイントとして動作するようになる。


PCのWi-Fi選択画面を開くと、「Amazon-XXX」という名前のアクセスポイントが見えてくるはずなので、それを選択することで、PCとAmazon EchoがWi-Fiで直接接続される。


問題なければ画面は自動的に遷移し、「Echoに接続しました」と表示される。


6. Wi-Fiネットワークを選択 (1回目)

次の画面ではAmazon Echoから見えるWi-Fiアクセスポイントが表示されるので、接続先を選択する。




選択するとパスワード入力画面に遷移するので、正しいパスワードを入力して「接続」を選択する。


数分接続待ちが発生したのち、Wi-Fi接続に失敗する。これは、Androidで表示されたエラーと(英語と日本語の違いはあるが)全く同じである。

------------------------------
デバイスを登録中にエラーが発生しました。トラブルシューティングの方法についてはヘルプをご覧ください。
エラー1
------------------------------


7. Wi-Fiネットワークを選択 (2回目)

ここでめげずに、再度同じパスワードを入力して「接続」を選択すると、今度は別メッセージで失敗する。

------------------------------
認証の期限が切れました。computerをインターネットに接続し、アプリからログアウトして、もう一度試してください。
------------------------------


どうやらWi-Fi接続時に発生した待ち時間の間に、Amazon Echoの設定可能時間を超過してしまったようだ。

8. 同じ作業を繰り返す

念のため、Amazon AlexaのWeb画面からサインアウトし、再度手順「1」~「5」を繰り返して、「Wi-Fiネットワークを選択」の画面まで遷移する。

9. Wi-Fiネットワークを選択 (3回目)

ここでうまくいっていれば、先ほど接続に失敗したアクセスポイントが「接続済み」になっているはずである。


「接続済み」の状態で該当のアクセスポイントを選択すると、パスワード入力が不要の状態となっている。ここで、「接続」ボタンを押下する。


10. 接続に成功

「EchoがWi-Fiに接続されました」と表示され、ようやく接続に成功する。


まとめ

どうにかAmazon EchoをWi-Fiに接続することができたが、Amazon EchoのWi-Fi接続手順は煩雑となっており、ITリテラシーが高くないユーザーにおいては、敷居が高いと感じた。実際、WebではAmazon EchoのWi-Fi接続作業で苦労している情報を多数見つけることができる状況であり、今後改善していかなければ、Amazon Echoの普及の足枷になると感じた。

2018年2月5日月曜日

Postfixで"Permission denied"でファイル送信が失敗する

Postfixでメール送信を行う際に、以下のようなエラーで失敗することがある。

# postqueue -p
------------------------------
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
782A818BD67B      429 Sat Jan 13 21:05:10  ex-1@example.com
(maildir delivery failed: create maildir file /var/spool/virtual/example1.com/ex1-1/Maildir/tmp/1515845435.P3212.t1110rh72: Permission denied)
                                         ex1-1@example1.com

-- 0 Kbytes in 1 Request.
------------------------------

これはSELinuxが動いていることが原因となるので、以下の通り無効化してしまえばよい。
※SELinuxを無効化したくない場合は、適切にSELinuxを設定するしかないが、本記事の範囲外とする。

# getenforce
------------------------------
Enforcing
------------------------------
# setenforce 0
# getenforce
------------------------------
Permissive
------------------------------

上記はOS再起動をするともとに戻ってしまうので、以下設定ファイルを修正して完全にSELinuxを無効化しておく。

# cat /etc/selinux/config
------------------------------
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted
------------------------------

人気の投稿