FortiClientのSSL-VPNが80%ぐらいで-12のエラーとなり接続出来ない


FortiClientのSSL-VPNを設定し、接続しようとしたら80%ぐらいのところで「 Unable to logon to the server. Your user name or password may not be configured properly for this connection. (-12) 」というエラーとなり接続できない。

ぐぐってでてきたFortinetフォーラムの「Error Forticlient stop 80%」は2017/02/10の書き込みながら、2019/01/23のコメントとしてWindows10の場合の事例について記載があった。

で、この記載を実施したところなおった。

「Internet Explorer」を開き、「インターネットオプション」の「詳細設定」を開く

上記の「Internet Explorerの設定をリセット」にある「リセット」を実行する。

実行後は一度再起動する。

再起動後、 「Internet Explorer」を開き、「インターネットオプション」の 「セキュリティ」を開く。

上記の「信頼済みサイト」を選択し、「サイト」をクリックする。

開いたウィンドウではSSL接続先のホスト名もしくはIPアドレスを登録する。(不要かも?)

ここで一度、FortiClientを起動してSSL-VPNが接続できるかを確認する。

まだ接続できないようであれば、「コントロールパネル」を開く

「プログラムのアンインストール」を選択

「FortiClient」を選択し「修復」を行う。

修復完了後は、再起動を行う。

おそらく、これでSSL-VPNが接続できるようになると思われる。


後日、「Unable to establish the VPN connection. The VPN server may be unreachable. (-14)」というエラーがでる・・・なんで?

(これは接続先が停止していたためと判明)


2021/01/06追記

新端末で「ステータス: 98%」で時間がかかって、エラーも何も出力されないまま、パスワード入力要求まで戻る、という現象が発生

調べると「IPv6を無効にする」なんて対処がでてきたりするが、デバイスマネージャでネットワークアダプターの項目にある「WAN Miniport (IP)」を削除し、Windows再起動してWAN Miniport(IP)を再作成すればいけるらしい

楽天モバイルの場合はIPv6周りの動作の問題で、対処方法については「楽天モバイル回線でForticlientによるSSL-VPNを行うと98%で止まるがエラーもない件の対処」に記載した。

ESXiで使用できるUPS連動シャットダウンソフトの情報 2022/08/17修正


ESXi 6.7からvMAというVMware提供の仮想アプライアンスが使えなくなった。
LinuxベースなのだがvCenter/ESXiをCLIから操作するためのツールが導入済みなので、UPS連動シャットダウンする際によく使われていた。

ESXi6.7以降は動かなくなってしまったので、代替を探す必要がある。
(APC PowerChute Bussiness EditionはvMAのみ対応)

APC PowerChute Network Shutdown 4.5

APC PowerChute Network Shutdown 4.5 for DELL VxRail ということで、DELL VxRail向けにPCNS v4.5が2022年7月頃にOVAファイルとしてリリースされています。それ以外の環境向けには引き続き PCNS v4.4が提供されています(対応表)。

APC PowerChute Network Shutdown 4.4

2020年10月登場の新バージョン:シュナイダーエレクトリック、電源管理ソフトウェアの最新版「PowerChute Network Shutdown v4.4」を発売

PowerChute Network Shutdown v4.4 ご紹介(最新版)」「PowerChute Network Shutdown v4.4 for Windows & Linux 対応OS表」「PowerChute Network Shutdown v4.4 for Virtualization 対応OS表」「PowerChute Network Shutdown v4.4 既知の問題PCNSユーザーズガイド」「PCNSの各種設定例

PowerChute Network Shutdown Operating System, Processor, JRE and Browser Compatibility Chart

PowerChute Network Shutdown ドキュメント」「PowerChuteシリーズ 各種マニュアル

PCNS v4.4でもJavaを使うという点には変更はない(今回はOpenJRE 14.0.2)。OpenJREのアップデートツールも添付されているとのこと。

今回のトピックは、VMware vSAN、Nutanix AOS、Microsoft Azure Stack HCI、Cisco HyperFlex、HPE Simplivityの自動シャットダウンをPCNS管理インタフェース上から設定できるようになった、ということ。

また、sshでアクセスし連動シャットダウンを仕掛けることが可能になったため、NetApp ONTAP 9.xとの連動シャットダウンなどもサポートした、とのこと。

Schneider Electric (APC) PowerChute Network Shutdown

2022/03/31追記:この項目にあるv4.1~v4.3に関するリンクはAPCサイトの更新に伴い動かないリンクばかりになっている。

APC PowerChute Network Shutdownに関する情報は「PowerChute Network Shutdownプロダクトセンター | よくあるお問い合わせ」と「PowerChuteシリーズ 対応OS表」を起点に捜索する。

PowerChute Network Shutdown v4.3 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスイメージが提供されているのでそれを使う。vSphere 7/ESXi 7.0サポートに関しても記載されている。
PowerChute Network Shutdown v4.2 for Virtualization 対応OS表」はシャットダウン用仮想アプライアンスか、vMAにPowerShuteインストールか、を選択できる。

PowerChute Network Shutdown v4.0以降のバージョンでVMware環境を保護する場合のPowerChuteインストール先について

PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例1
PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例2
PowerChute Network Shutdown v4.1 v4.2 電源障害時のシャットダウンプロセス(VMWare仮想環境) – 構成例3

VMware HA利用時やvSAN利用時は、VMware側がユーザ操作なしに停止することを全く考慮していないため、ESXiサーバのみの環境ではうまくシャットダウンを行うことができない。

別に物理のWindowsサーバを用意し、そこからシャットダウン命令を送る必要がある。また、復電後の起動についてはもっと考えられていないため、その処理も自前でどうにかする必要がある。

PowerChute Network Shutdown for Virtualization v4.x VMware HA環境でのサポート構成」(VMware HA環境では仮想マシン停止をサポートしていない)

20180222_VxRailccトラブルシューティングセミナーvSAN環境におけるUPS構成とシャットダウンシュナイダー出口様

富士通のWebにある「PowerChute Network Shutdown for Virtualization v4.3」(PDF版)でvSphere, Hyper-V, Nutanix AHV環境でどういう風に機器を配置すればいいのか分かりやすい絵付きで解説されている。

HPE Power Protector

HPEブランドで販売されているUPSは、HPE Power Protector(HPEPP)を使用してシャットダウンを行う。

ソフトのダウンロードはなかなか見つけにくい。以前は「HPE swdepot Power Protector UPS Management Software」だったが2020年10月ぐらいから死んでいる。2021年10月/2022年3月の段階ではドキュメント上で「Download updates from HPE Software Depot」というリンクがあるが、リンク先が動作していない。なんとかして後述の個別ダウンロードリンクを発見する必要がある。

ESXi 6.7以降の対応について「アドバイザリ: HPE Power Protector – VMware vSphere Management Assistantのサポートが終了したため、VMware ESXi 6.7 (またはそれ以降) を実行しているHPEサーバーでHPE Power Protectorが正しく機能しない」「Advisory: HPE Power Protector – HPE Power Protector Does Not Function Correctly On HPE Servers Running VMware ESXi 6.7 (Or Later) Due to The Discontinued Support For VMware vSphere Management Assistant」に記載している。

vMA使えないから、無料で使えるdebian使って仮想マシン作って、それにHPEPPを入れろ、ということになる。

2019/12/06リリース版のダウンロードリンク
HPE Power Protector Windows版 v2.02.087 (HPE Power Protector (HPEPP) Clientのインストール方法 (Windows))
HPE Power Protector Linux版 v2.02.087 (HP UPS – HP Power Protector (HPPP) Client のインストール方法 (Linux))

2020/10/23リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.02.089
HPE Power Protector – Linux版 v2.02.089

2021/08/12リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.03.091
HPE Power Protector – Linux版 v2.03.091

2022/02/09リリース版のダウンロードリンク
HPE Power Protector – Windows版 v2.04.094
HPE Power Protector – Linux版 v2.04.094

EATON Intelligent Power Protector (IPP)とIntelligent Power Manager(IPM)

日本代理店ダイトロンの製品ページ「Intellignent Power Protector」「Intelligent Power Manager

メーカページ「Eaton Intelligent Power Manager

2020年からIPMのライセンス体系が変更になり、また海外ではIPM2も登場した。IPM1とIPM2が互換性がなく、日本国内向けではIPM2は非サポートとなっているようだ。

連動シャットダウンについてはWindows仮想マシンにIPMを入れる方向性のようだ

IPM Optimize/(旧名)IPM Silver/ (旧名) IPM Goldを使うとVMware HAとvSANを含んだシャットダウンにも対応。

VMware HAはWindows仮想マシンにIPMを入れることで対応可能。復電も対応→「シャットダウン for vCSA on vSphere HA by IPM 1.68」「自動起動 for vCSA on vSphere HA by IPM 1.68

vSANはvSANを使っていないESXi上にvCSAとWindows仮想マシン+IPMを置くことで対応可能。復電も対応→「シャットダウン for VMware vSAN 6.6.1 by IPM 1.60

オムロン VirtuAttendant

無償のUPS管理ソフト「PowerAct Pro」はvMA利用のためESXi 6.5までになっている(PowerAct Pro Slave Agent VMware版 ダウンロード)

有償のUPS管理ソフト「VirtuAttendant」はESXi 7.0対応版が出ていて、手順説明はリンク先に掲載されている。なお、ライセンス料金は1つのvCenter Server環境につき192500円。

また「構成事例/設定ガイド」の「Nutanix / vSAN / 3Tier の構成事例〈ネットワークカード〉」にESXi6.7に対応したVSAN構成時の設定ガイドvSphere+RAID構成時の設定ガイドが掲載されている。

その他参考資料

NEC編

ESMPRO/AutomaticRunningController ダウンロードページ」にある「VMware ESXi 環境における電源管理ソフトウェアの導入(第37版 2020/01/31)(第41 版 2021.11.30)にNECのESMPRO/AutomaticRunningControllerと連携させる場合の詳細解説が書かれている。

富士通編

PRIMERGY 技術情報の「仮想システムでのUPS利用ガイド」にて、PowerChute Network Shutdown Enterprise Editionを使用する場合の説明がある。

また、富士通サーバ ISV/IHV技術情報の「APC PowerChute Network Shutdown」と「APC PowerChute Network Shutdown(過去事例)」とにてAPC UPSを使って行われた各種検証内容に関するレポートが公開されている。

VMware編

VMwareのKnowledgeに「VMware ESXi ホストへの APC Powerchute Network Shutdown ソフトウェアのインストール (1007036)」というのが掲載されたが、2020年2月掲載なのにvMAを利用するバージョンでRelated ProductsもESXi 5.5.xが最新という古い記述になっている。

10ドルの45W USB PDアダプタMAD GIGA PD Adapterを買ってみた


aliexpressで約10ドルという怪しげなUSB PDアダプタが売っているのを発見。

20V対応で45Wまで行けるらしいので買ってみた・・・

発注から2週間ちょいで到着。

・・・「公式ページ」があるのか

しかし、2019/10/04時点ではこのUSB PDアダプタは掲載されていなかった。

箱の中身は、USB PDアダプタ本体と説明書のみ

サイズ感の比較として、RAVPower 36Wと並べて見る。

裏面

USB端子側

AC側

そして、スペック表記。これは上がMAD GIGA

MODEL: PD45W+BC5V2.1A
INPUT: AC100-240V 50/60Hz 0.8A Max
OUTPUT USB-C: 5V3A / 9V3A / 15V3A / 20V2.2A
OUTPUT USB-A: 5V2.1A
MADE IN CHINA shanzhen hexinyu technology co,Ltd

で・・・こいつ、ACプラグの折りたたみ機構がちゃんと考えられていないようで、プラグを引き起こすために指を入れるスペースが確保されておらず、爪を差し込んで引き起こす的な感じになっています。

それ以外はぱっと見問題なさそうです。

次に電源を入れてみます。

手元にあるTC66Cで検査・・・

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・え?ほんとに販売ページに書いてあった「Type-C: 5V/3A, 9V/3A, 12V/3A, 15V/3A, 20V/3A 」ってマジなん?

いや、筐体に書いてあるスペックには載ってないけど12V3A隠し仕様で存在してる、ってのはよくあるけど、20V3Aって60W使えるって??いや、間違いかもしれないからPower-Zでも調べて見よう

5V3A / 9V3A / 12V3A / 15V3A / 20V3A

・・・どうやら間違い無いようですね(ちなみに本編とは関係ないですがRAVPower 36Wは5V3A/9V3A/15V3A/20V2.25Aと45W使えると出ました・・・)

自宅には20Vを使うUSB PD機器がないので、先日買ったUSB PD 20Vを丸形ノートパソコン電源に変換するアダプタを使ってテスト

うちにあるDynabookだと最大で20V2Aぐらいまでの使用に留まり、45W以上いくのかは確認出来ませんでした。

まぁ、約40W使用でそこそこ熱い感じだったので超えると危険そうですけどね

EC-CUBE 4.0をSELinux有効状態のOracle Linux 7上に構築する手順(仮


EC-CUBE 4.0のテスト環境が必要になったので、Oracle Cloud上のOracle Linux 7インスタンスを立てて、その上に作成した。

が・・・公式ドキュメントはSELinux関連の設定とか触れてないし、かなり面倒だった。
厳密にやろうとするとかなりキツイので、SELinux有効の中でも簡単な対処としている。

環境初期準備

タイムゾーンを日本に設定

# timedatectl set-timezone Japan

fail2ban設定

sshアタックがあった場合にとっととIPバンするためにfail2banをインストール。
・・・いや、ターゲットにされるとホント、すごい勢いでsshアクセスの試行がありますよ。

# yum install -y fail2ban fail2ban-hostsdeny fail2ban-systemd
# systemctl enable fail2ban.service
# cat <<EOF > /etc/fail2ban/jail.local
[DEFAULT]
# 24時間以内に3回不審なアクセスがあったら24時間BAN
#bantime  = 86400
#findtime  = 86400
bantime  = 259200
findtime  = 259200
maxretry = 5

#CentOS7なのでsystemd
#backend = systemd # jail.d/00-systemd.conf で設定されてた

# 除外IP
ignoreip = 127.0.0.1 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 <除外したいIPを追加>
[sshd]
enabled = true
banaction = firewallcmd-ipset
EOF
# systemctl start fail2ban.service
#

webサーバとphp設定

phpはOracleが用意しているphp 7.2を使用するため、「oracle-php-release-el7」をインストール。現状の標準設定だとphp 7.2が標準選択されている。なお、php 7.1かphp 7.0を使うこともできるが、いまさら利点は無いので使用しない方がよい。

# yum install oracle-php-release-el7
# 

phpパッケージとhttpdをインストールして、firewall開け設定実施

# yum install -y httpd mod_ssl php php-json php-mbstring php-pdo php-xml php-zip php-mysqlnd php-intl 
# systemctl enable httpd
# systemctl start httpd
# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https
# firewall-cmd --reload

APCU(php-pecl-apcu)のインストールを推奨されたが、パッケージのコンフリクトが発生していたのでインストールしなかった。

SQLサーバ設定

今回はmariadbをSQLサーバとして使用した。

# yum install -y mariadb-server
# systemctl enable mariadb
# systemctl start mariadb
#

SQL起動後、ECCUBE用のデータベースを作成した。

# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.64-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database eccube character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all on eccube.* to cubesql@localhost identified by 'dbsqlp@ss';
Query OK, 0 rows affected (0.08 sec)

MariaDB [(none)]> exit
Bye
#

ECCUBEファイル展開

/var/www/html/eccube にEC-CUBE 4.0.3を展開した。

展開した中に.htaccessファイルが含まれていますが、標準設定では読み込まないのでApacheに設定追加を行います。 (もっとセキュリティを強化してもいいとは思いますが、面倒だったので・・・)

# cat <<EOF> /etc/httpd/conf.d/eccube.conf
<Directory "/var/www/html/eccube">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>
EOF
# systemctl restart httpd
#

で・・・SELinuxがらみがどうなるかですが、おもいっきり引っかかりまくりました。

とりあえず該当するコンテンツに対して「httpd_sys_rw_content_t」を割り当てることで対処しました。

最初は個別に対処していこうとしたのですが、インストールプロセスを進めていくと、/var/www/html/eccube全体に対して権限を要求されたため、最終的には下記となりました。

# chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube
#

とりあえず、これでEC-CUBE 4.0の初期セットアップ完了までできるようになりました。

なお、サイトによっては「getsebool -a|grep httpd_can_network_connect」で「httpd_can_network_connect」の値を確認し、offであればonに変更する、と記載されているものもありますが、必要ありませんでした。

エラーコレクション

SELinux設定をしていく中で出てきたエラー群です。

まず、 http://IPアドレス/eccube/ にアクセスすると以下が現れました。

(2/2) ContextErrorException
Warning: file_put_contents(/var/www/html/eccube/var/cache/install/EccubeInstallDebugProjectContainerDeprecations.log): failed to open stream: No such file or directory

(1/2) RuntimeException
Unable to create the cache directory (/var/www/html/eccube/var/cache/install)

このときに表示された /var/www/html/eccube/var に対して「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/var」を実行しました。

次にでたエラーは下記です。

Filesystem->copy('/var/www/html/eccube/html/template/default/assets/img/common/favicon.ico', '/var/www/html/eccube/html/user_data/assets/img/common/favicon.ico')

/var/www/html/eccube/html/user_data以下に書き込む権限がないというもの。
eccubeディレクトリ内を探すと他にも「user_data」というディレクトリがあったため、「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/html/user_data」と「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube/app/template/user_data」を実行した。

最後に「権限チェック」で引っかかった。

以下のファイルまたはディレクトリに書き込み権限を付与してください。
>>☓:/var/www/html/eccube
>>☓:/var/www/html/eccube/app/Plugin
>>☓:/var/www/html/eccube/app/PluginData
>>☓:/var/www/html/eccube/app/proxy
>>☓:/var/www/html/eccube/app/template
>>☓:/var/www/html/eccube/html
>>☓:/var/www/html/eccube/vendor
<略>
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/README.md
>>☓:/var/www/html/eccube/vendor/ocramius/proxy-manager/composer.json
>>☓:/var/www/html/eccube/composer.json
>>☓:/var/www/html/eccube/composer.lock

ようはここまでで「httpd_sys_rw_content_t」を設定しなかった全ファイル。

「chcon -t httpd_sys_rw_content_t -R /var/www/html/eccube」を実行して再チェック・・・

>>○:アクセス権限は正常です

これでセットアップを進めることができました。

Oracle Cloud上にWindows Server 2016インスタンスを作ったら記号が入らずパスワード入力ができなかった件


Oracle Cloudの登録特典でもらえる30日有効の33000円分のクレジットがまだまだ余ってるので、Windows Server 2016インスタンスを作ってみた。

画像

初期パスワードはシステム側で自動生成される・・・と

画像

ありますね。

初回ログインはコンソール画面から行う必要があるので、上記の画面をスクロールして「リソース」の「コンソール接続」から「コンソール接続の作成」を選択

sshの公開鍵を指定して・・・

コンソール接続が「アクティブ」となったら、右側のメニューから「VNCを使用して接続」を選択

「プラットフォーム:WINDOWS」を選択して、文字列を「コピー」

Windows上でPowerShellを開いて、コピーしたものを貼り付けて実行

で・・・VNC Viewerを起動して「localhost:5900」に接続を実行すると下記の様にログイン画面が出てくる。

画像

で・・・ココで問題が発生。

パスワードを入力しようとしても 「:→;」「@→2」「^→6」「`→~」「=→+」 という感じで期待通りの入力が行えない。

Windows 10の日本語キーボード環境で「;キー」と「:キー」のどちらを押しても「;」が入力される事態。UltraVNCにあるSend Custom Keyを使用して「85」「86」を送っても、同じく「;」が入力されてしまう。

UltraVNCには「Japanese keyboard」という設定項目があるのでそれを設定しても状況は変わらず。

画像

UltraVNC
RealVNC
TigerVNC
この3つを試したところ、TigerVNCでは、Windows上のキーボード認識がUSキーボードになってるけど、実際につながっているのは日本語キーボード、という場合に相当する動きをしてくれた。

この動きであれば、日本語キーボードを英語配列だと思い込んで操作することによってなんとか記号を入力することができる(一部入力できないものもあるが、UltraVNC/RealVNCよりはずっとマシ)

TigerVNC Viewerでログインに成功し、デバイスマネージャー(Device Manager)から「Standard PS/2 Keyboard」を「Japanese PS/2 Keyboard (106/109 key)」に変更することで、日本語キーボードであっても期待通りに入力出来る環境を用意することができた。

(下記の画像はWindows Server 2012R2のだけど、Windows Server 2016もほぼ同じ)

「Standard PS/2 Keyboard」の「Properies」を開き、「Driver」タブを選択する。

「Update Driver」を選択し、下記では「Browse my computer from driver software」を選択

下記は「Let me pick from a list of device drivers on my computer」を選択

「Show compatible hardware」に入っているチェックを外す

チェックを外すと下記の様に選択肢がたくさん現れる。

下記の様に「(standard keyboards)」内の「Japanese PS/2 Keyboard (106/109 Key)」を選択し、「Next」

警告は「Yes」

変更完了

再起動して、変更を反映させます。

また、コントロールパネルの「Language」にて

「Add an input method」を選択し、リストから「QWERY Japanese」を選択し、「Add」

「Save」します。

Save実行とともに時計の横に「ENG US」が表示されますので、それをクリックすると「ENG JA」が選択できます。

これにより日本語キーボードをつかって正常に入力することが可能となります。

なお、この設定を行ってもUltraVNC,UltraVNC(Japanese Keyboard設定あり),RealVNCでは相変わらずな動作をして記号や日本語変換が行えませんでした。