Window10で設定が戻る

VPNのサポートでお客さまから、「以前はできてたのに、できなくなった」的な問い合わせは良くいただきます。

だいたい今までだと、VPNなどのネットワークの問題というよりWindowsの設定を変えてしまったり(お客様の誤操作で設定が変わるも含め)、何かアプリケーションを入れたりすることによる不具合が多かったのですが

 

Windows 10 機能更新適用時に初期化される設定について

Windows10の場合、半年に1回やってくる恐怖のFeature Update において、各種設定が初期化されるということが公式に認められています。

OSの設定だけでなく、サードパーティーのアプリケーションも初期化される可能性があるらしい、おそろしい。

(まあ、デバイスが認識しなくなる なんてもっと大変なことも起きますが)

 

具体的に何が初期化されるまでは明確に書かれていませんが、ぐぐってみると

Windowsファイアウォールの設定や、悪しき高速スタートアップ の設定等通常の運用に大きくかかわることが初期化されることがあるようです。

うちの会社もそうですが、中・小規模の会社だと、従業員に支給するパソコンは、いろんな設定(会社ごとで決めてる設定やチューンがあると思います)を1台毎に施して従業員に使ってもらってますが、それが半年ごとにやり直しになってしまう(全部ではないですが)なんてことが、起きるわけですが正直たまったものではありません。(MS的には、だったらActivedirectoryにしたら?ってことなんでしょうが・・・)

もうすぐ、Windows7のサポートも切れます。(あと1年半)

単位OSの入替だけではなく、根本的な運用も含め見直しが必要かもしれないですね。

 

 

VPNでNASが使えない!!

弊社サービスの「VPNソリューションパック」を利用しているお客様からの問い合わせで

良くいただく内容として

本社ではNAS(Network Attached Storage)が使えるんだけど、拠点からは使えない!

というのが良くあります。

この場合、大抵の原因は、

NASのネットワークの設定で、「デフォルトゲートウェイ」が設定されていない

という場合がほとんどです。

※ちなみにデフォルトゲートウェイとは

コンピュータや通信機器などのネットワーク設定の一つで、送信相手までの経路がわからない場合に、とりあえずデータを送信する中継機器のIPアドレス。

(参考:e-words

 

インターネットVPNの場合、一般的に本社とVPN拠点はネットワークアドレスを分けるのが一般的なため

デフォルトゲートウェイが設定されていないと、同一のネットワーク(たとえば本社内)であれば通信できますが、異なるネットワーク(VPN拠点)とは通信できません。

ちなみに異なるネットワークには、インターネットも含まれるので、この設定が抜けているとインターネットにもつながりません。

(NASがインターネットにつながる必要はあまりありませんが・・・)

 

最近は一般家庭にもNASを入れるのが珍しくないくらいNAS自体が普及していますが、

それに伴い、個人ユーザでも簡単に導入できるように、NASメーカ側も「誰でも簡単に設定できる」ように機器側で仕掛けをしています。

いわゆる「簡単設定」みたいな設定がそれにあたります。

この「簡単設定」を使うと、個人で使うのに必要な最低限の設定だけしてくれるのですが

この時に先ほどの「デフォルトゲートウェイ」を省略して設定を完了する場合が多いようです。

(まあ、個人で使う分にはなくても良いですからね)

そのため、VPN利用の場合、上記のようなトラブルが発生することになるわけですね。

ちなみに似たような事象としては、「複合機がVPN拠点から使えない」という場合も先ほどのデフォルトゲートウェイが未設定の場合が多いですね。

あと、Windows系のサーバを使っている場合は、「Windowsファイアウォール」の設定の確認も必要になります。

最近はサーバOSでも「Windowsファイアウォール」が搭載されていますので、これを初期値で使っていると、「同一ネットワーク」以外からの通信はブロックするので注意が必要です。

(なにやら、Windowsアップデートすることで、ファイアウォールの初期値に戻る なんて事象もあるようなので、前はできていたのに急にできなくなった ってときは再度ファイアウォールの設定は見直したほうがよいかもしれません)

 

 

 

 

“Windowsセキュリティシステムが破損しています” というエラー

お客様から、パソコンで変なエラーがでるようになってしまったのでどうしよう

という問い合わせがあって、リモートで画面共有してもらったら↓のようなエラーが出てました。

Windowsセキュリティシステムが破損しています

こんなん出るとびっくりしますよねぇ

これ自体はかなり昔からある、偽セキュリティソフトをインストールさせるための詐欺警告のようです。

「×」を押せば・・・・ と思いきや、この手のやつはそれすらもNG(押すと偽ソフト発動?) らしく IEを強制終了するのが正解だそうです。

(Ctrl+Shift+ESCでタスクマネージャ開いてIEシャットダウン)

その後、IEのキャッシュ削除→ウィルススキャン が王道のようです。

こちらのお客様は、MSのessentialを使っていたので、それだけはでは心配なので、トレンドマイクロとかのオンラインスキャンも念のため試してほしいと伝えました。

 

この手の詐欺は、いわゆる「いかがわしい」サイトにありがちですが、ググってみると動画配信サイトや、ぱっとみ普通のサイトなどでも出くわす可能性はあるようです。

なので、自分はそんな変なサイトみないから関係ない って感じでもないようなので気を付けましょう。

 

今回、essentialしか入ってなくて、有料のアンチウィルスソフトは入ってませんでしたが、それらであればブロックされたかどうかは不明

(有料のであればちゃんとブロックされたケースと、そうでないケースもある)

なのでアンチウィルス入っているから安心。というわけでもないのでこちらもご注意を。

 

ちなみに今回のお客様ですごいと思ったのが、この画面がでたら何もせず連絡をしてきたことです。

普通こんな画面みたら、「×」ボタンくらい押しちゃいますよね?実際押してたらアウトだったかもしれない。

変に詳しい人ほど押しちゃうかも。

お客様のなかで「なんかやばい!」って直感が働いたんだと思いますが、そういう意味ではものすごいセキュリティ意識が高いのだと思います。

こういう冷静な判断って情報セキュリティ対策として非常に大事ですよね。

AWS(Amazon Web Services)とのVPN接続の検証

 

先日(といってもかなり前の話ですが)とあるシステムベンダー様からAWS(Amazon Web Services)のVPCとの拠点間VPN できないか
という相談があり、システムベンダーと協力して弊社がいつも使っている
センチュリーシステムズのNXRシリーズを使ってVPN接続が可能か検証を行いました。
(自分用の備忘録です。すみません)

クラウドサービスとのVPN接続ですが、
(当たり前ですが)クラウドサービス側にVPNルータ(ハードウェア)をamazon側に設置することは
できないので
クラウドサービス側で、なにかしらの仮想的なVPNルータを動かす必要があります。
このVPN仮想ルータは、
①クラウドサービス側で準備されているものを利用する
②クラウドサービス上の仮想サーバに利用者がVPN機能を持ったソフトウェアをインストールしそこでVPN接続する
の大きく2通りあると思いますが、今回は、Amazonが準備している仮想のVPNルータ
仮想プライベートゲートウェイ(Virtual Private Gateway) とセンチュリーシステムズのNXRシリーズとの
VPN接続を試します。

ちなみに
①のメリットは、クラウドサービス側で準備されている機能をそのまま使うだけなので手間がない反面
汎用性がなかったり、機能が限られる、対向との接続性が大丈夫か? 等の問題もあります。
②は逆に、汎用性は高く、機能も充実していますが、
導入の手間やコスト、この仮想VPNルータ用で仮想サーバの契約をしないといけないのでコストもかかる等のデメリットがあります。
そもそもこういった、仮想サーバにインストールが可能なVPNのソフトウェアがそれほど充実していないため調達が難しい点もデメリットかもしれませんね。
※センチュリーシステムズでは、②用の仮想サーバにインストールが可能なVPNのソフトウェア「FutureNet VXR-x86」というソフトウェアがありますが、今回は使用しません。

AWSでの①の機能制限の例としては
・VPNの対向数が10まで
・対向のVPNルータのWAN側は固定のIPアドレスが必要
・ルーティングがスタティックかBGPに限られる
等があります。
詳細は以下参照
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html

さて、さっそくVPNのテストなのですが

構成は以下のような1:1の接続です。(右側が、オンプレ側ですね)

AWS側の設定ですが
amazonのマニュアルが↓のようにありますでの、こちらを参照して設定。
(今回はシステムベンダーさんにやってもらい、あとでレクチャーを受けましたが、↓のように進めれば基本大丈夫そう)
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/SetUpVPNConnections.html

で、続いてオンプレミス側のルータの設定ですが、
AWSの仮想プライベートゲートウェイを使うときですが、便利なことに
AWS上のVPCへVPN接続する際のオンプレミス側のルータに必要な設定(コンフィグ)を、マネジメントコンソールからダウンロードできます。
サポートされるルータはなんでも良いわけではないですが、対応していればベンダーとバージョンを指定すればダウンロードでてしまいます。
ダウンロードしたコンフィグを、オンプレ側の機器に流し込んでしまえばそれで終了なのです。
めちゃくちゃ便利。
(ただ、あくまで一般的な設定なので、ルーティング設定等は手直しが必要な場合があるようです)
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html

すごい便利なのですが、今回検証するセンチュリーシステムズは対応してません。残念!!!

対応していない場合はどうするかというと、
・マネジメントコンソールから、ベンダ「Generic」(一般的ってことですね)のコンフィグをダウンロード
・それに記載されているIPSECのパラメータを参照して、オンプレ側のルータを手動で設定

になります。はい、めんどくさいです。

ちなみに、AWSの場合、
>リモートネットワークを VPC に接続するには、VPN 接続を使用します。各 VPN 接続には 2 つのトンネルがあり、

>それぞれのトンネルが固有の仮想プライベートゲートウェイのパブリック IP アドレスを使用します。

となっており、AWS側は回線の冗長化が標準的にされています。なので
オンプレミス側のルータは、この冗長化に対応していないと、接続できないorできても何かしら不具合がでる可能性があるかも。

(AWS側のログでエラーはきまくるとか )

で、戻ってオンプレ側のルータの設定ですが、めんどくさいとは言いつつもAWS用で特別な設定は前述の冗長化くらいでそれ以外特殊な設定はないためさくっと設定して、 接続テスト!!

とりあえずAWS側の接続状態は以下のような感じ(ステータスがアップ)でOKぽいです。(設定が2つあるのは前述の回線が冗長化されているためです)

接続記録等の詳細なログなどはなさそう。amazonに問い合わせたらもらえるのかな??

 

VPC側にサーバとかは準備していなかったので、オンプレ側からpingを打ってみましたが、問題なくつながるようです。欠けたりすることもなさそうです。

(しまった、pingの応答速度記録するの忘れた!!!!もともとオンプレ側の回線ADSLだったから参考にならないからいいか・・・)

本当は、回線冗長化がちゃんとされているか確認したいのですが、AWS側のメイン回線を切る術がないので確認でできてません。。。。
そもそも故障率ってどんなもんなんでしょう?切替わり時間とか?
一応↓みたいな監視てきなこともできるようですが、今回は確認できてないです・・
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/monitoring-overview-vpn.html

とりあえず、センチュリーシステムズのルータでもとりあえずは繋がることは確認取れましたが
今回は1:1のVPN接続でしたが、1:nの確認はしていないですし、
上でも書いた、AWS側の冗長化の確認だったり、障害発生時、Amazonに何がどう確認とれるかであったり。。。。未確認なことも多いです。
根本的にAWSのことがあんまりよくわかってないので、ちゃんとサービス化しようとすると、もうちょっと時間がかかりそう。

Windowsアップデート後、リモートデスクトップが接続できない

なんかまたアップデートがらみで、仕様という名の不具合がでてます。

どうやら、アップデートの影響でリモートデスクトップに接続できなくなるみたいです。

詳細は↓に書いてあるので割愛しますが

https://blogs.technet.microsoft.com/askcorejp/2018/05/02/2018-05-rollup-credssp-rdp/

簡単に書くと

Windowsアップデートしてないサーバに対して、Windowsアップデートしちゃったクライアントからリモートデスクトップができなくなる

ってことのようです。

クライアントOS(Windows7とか)は比較的、ちゃんとアップデートしているケースが多いと思いますので

クライアントOS間であれば問題ないと思いますが

サーバOSの場合、アップデートすると逆にアップデートしないで運用していることも多いと思いますが

この場合リモートデスクトップできなくなるみたいです。

抜本的な解決方法としては、ちゃんとサーバ側もアップデートしろってことのようですが

アップデートすると別の不具合出ちゃうかもしれないじゃん!!!って思ってる管理者が大多数かと思いますが

一応、そのため(?)にセキュリティレベルは落ちますが、別の回避策があります。

https://blogs.technet.microsoft.com/askcorejp/2018/05/02/2018-05-rollup-credssp-rdp/

の 4. 回避策 を参照してください。

(クライアント側とサーバ側でそれぞれありますが、どっちかだけで良いようです。)

 

ただ、弊社のお客様の何社かで起きてますが、

上記の方法で回避はできるんですが、クライアント側でリモートデスクトップ(というよりRemoreAPP)のID/PASSを保存してる場合、このID/PASSがリセットされてしまう場合が

あるようです。(リセットされてるんで、結局リモートデスクトップつながらないみたいな)

回避策実行したのに解決しないじゃん って思いそうですがが(少なくとも私は思いました)、ID/PASS入れたらつながるのでその辺はご注意を。

 

 

 

 

 

 

Windows 10 April 2018 Update開始

Windows 10の大型アップデートである「Windows 10 April 2018 Update」が4/30(現地時間)の提供が開始されたようです。

http://tech.nikkeibp.co.jp/atcl/nxt/news/18/01091/

https://pc.watch.impress.co.jp/docs/news/1119750.html

https://forest.watch.impress.co.jp/docs/special/1119651.html

 

今回もいろいろ機能は追加されているようで、

・アプリケーションの操作履歴を時系列に整理して見せる「Timeline」 ←MSアカウントが共通であればほかのPCの履歴も見える!便利!?

・ファイルやURLを簡単にBluetooth経由で送れる「Near Share」 ←iOSのAirDropみたいなもの?

・従来の非通知モードの拡張「集中モード」 ←SNSの通知などを一時的に止める。

・HEIF(High Efficiency Image File Format)形式イメージの読み取りがサポート←iOSでは最近標準の形式。Win7でも対応してほしい・・

等々。結構面白そうな機能がたくさん追加されるようです。

ただ、この手の大型アップデートは不具合もつきもの。(今回は開発段階で不具合が見つかりリリース自体も遅れたようですが・・)

過去にもせっかくアップデートしたのに、OS自体が立ち上がらないとか、デバイスが動かないとかいろいろ起きてましたので、それはそれで心配。

そもそも、リリースをGWの4/30のタイミングにするとか、「April 2018 Update」に無理やり合わせた感がぷんぷんします。

ほんとに不具合解消されてますよね?

別にMay 2018 Update でもいいんですよ、MSさん。

 

GW明けに(アップデートのせいで)VPNがつながらない!ネットワークにつながらない!という問い合わせがガンガン来ないことを祈るのみ。。。

 

2018/5/2追記

April 2018 Updateから、「ホームグループ共有」が廃止されるようです。

業務用PCで使っている人は少ないかと思いますが、念のため↓が「ホームグループ共有」のやり方です。このやり方してる人は要注意です。

https://www.fmworld.net/cs/azbyclub/qanavi/jsp/qacontents.jsp?PID=8210-8382

 

 

更新プログラム適用でデスクトップアイコンが消える?

一部のPCで、Windowsアップデート適用後、デスクトップのアイコンが消える という不具合が発生しているようです。

うちの環境では発生していませんが、弊社の一部のお客様で本事象が発生し、復元→「KB4099950」を削除で解決しているようです。

https://answers.microsoft.com/ja-jp/windows/forum/windows_7-update/%E6%9B%B4%E6%96%B0%E3%83%97%E3%83%AD%E3%82%B0/3b3bb1c3-a759-4c48-9216-b923c7f8a13d

もともとこの更新プログラムは、前回ここでも書いた3月の更新プログラムを適用したWindows 7/Windows Server 2008 R2環境の一部で発生していたネットワークの不具合が修正したプログラムのようですが、これを適用することで新たな問題が発生してるようです、、、、

 

更新プログラムの不具合には慣れっこになってきましたが、直近の不具合の修正プログラムに不具合があった ってのはさすがにちょっと・・・という感じです。。

 

不具合があるのは百歩譲って仕方ない(すべてのH/W、ドライバに対応させるのは無理?)としても、今回のようなケースで

原因を特定(どのKBか特定)→復元→KB削除→そのKBが適用されない様にする

という対処法大変なんで、ボタンをポチっとしたら戻るとか、もっと楽になりませんかね?

Windows7 3月の更新プログラムを適用すると無線 LAN,有線 LAN 利用時に問題が発生する

毎月定例のWindowsアップデートですが、

先週配信された更新プログラムを適用すると、無線 LAN,有線 LAN 利用時に問題が発生するそうです。

対象OSは、Windows 7 SP1 と Windows Server 2008 R2 SP1

詳細は以下、MicrosoftサポートチームのURLを参照していただければと思いますが

3月の更新プログラムを適用すると無線 LAN,有線 LAN 利用時に問題が発生する

 

起きる現象の抜粋としてはこんな感じ


<現象1-1>

・ステルスモードの SSID への接続用の無線プロファイルが表示されなくなる

 <現象1-2>

・無線 LAN アダプターが無効化される、利用できなくなる

 

<現象2>

・ネットワーク インターフェースに静的に設定した IP アドレス情報が失われ、DHCP などのデフォルト設定に置き換わる。


現象1は無線、現象2は、有線でも無線でも発生するっぽいですね。(まあ、無線を静的アドレスにすることは少ないので実質有線のみか・・・)

 

しっかし、毎度定例アップデートでいろいろやってくれますが、特にWindows7がらみが多いですね・・・・

前回も書きましたが、早く10に移行せよってことでしょうか。。。。。

 

そろそろWindows7からの移行の準備を・・・

2014年WindowsXPのサポート終了から、早4年。
今度は、2020年1月14日にサポートが終了するWindows7への対応をそろそろ始めないといけない時期に来ました。
XPの対応がついこないだような気がしますが、もうそんな時期なんですね。。。
皆さんご準備のほうはいかがでしょうか。

まだ2年近くありますが、XP→7に入れ替えを経験したかたならわかるかと思いますが
「あと2年しかない」というのが実感なのではないでしょうか。

ちなみに
OSやブラウザのシェアを調べることができるサイト「Statcounter」によれば
2018年2月の時点では
Win10・・・43.54%
Win7・・・41.55%
Win8.1・・・・8.53%
WinXP・・・・3.2%
Win8・・・・2.49%
WinVista・・・・0.62%

という比率だそうで、いつの間にかWin10が、Win7を追い抜いておりました。

http://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

これだけ見ると、Win10への移行が順調な気もしますが、法人利用の場合はまだまだWin7が現役という会社も多いんじゃないでしょうか。
弊社のVPNのサポート中、お客さまののOSを確認するとまだまだWin7のほうが多いです。

ということで、弊社もまだままWin7がメインなので、入れ替えをしていかないといけないですが
そのままWin10へ移行するか
どうせなら、この際RDPサーバ立てて、シンクライアント環境にしちゃうか悩み中。

Win10の場合、定期的な大型アップデートの度にデバイスやソフトウェアが動作しなくなったりでトラブルも多いし・・・

その点、シンクライアントにすれば個別のPCの不具合などに対応しなくて済みますし、バックアップとかセキュリティ関連とか
まとめてできて便利そう(多分。。。)だし、何よりも固定席を持たない「フリーアドレス」環境にもできる!!

でもサーバOSのメンテはそれはそれで大変(苦手)だし、相応のコストもかかるし、、、
さて、どうしたものか。

Win10は、Windowsとしては最後のOSなんて言われたりもしてますので、この移行がらみの対応はこれで最後の可能性もありますが
数年後、何がどうなっているか読めない世界ではあるので・・・
そういったことも含め、今回の件の自社分は粛々と進めていこうかと思います。

「フレッツv6オプション」を使ったIPv6のVPNのテスト③

 

前回からの続きでv6でのVPNテスト最終回です。

前回までで、とりあえず「フレッツv6オプション」を使ったVPN環境の構築まではできましたので
v4との比較でどれくらい速度に変化があるか測定してみたいと思います。

尚、今回の結果は、あくまで弊社の環境(回線、LAN環境、測定PCの性能)での測定結果
になりますので、参考値として読んでもらえればと思います。

 

■環境

・v4環境
ルータ①
回線:フレッツ光ネクストファミリー隼 ひかり電話なし
エリア:愛知県
WAN環境:OCN IPv4 PPPoE接続

ルータ②
回線:フレッツ光ネクストファミリー隼 ひかり電話あり
エリア:岐阜県
WAN環境:OCN IPv4 PPPoE接続

・v6環境
回線、エリアともに同じ環境
ルータ①
WAN環境:「フレッツv6オプション」 ネーム利用あり

ルータ②
WAN環境:「フレッツv6オプション」 ネーム利用なし

 

■測定方法
1)ルータ①配下にある、ファイルサーバ(WinSV)から、ルータ②配下のPC(Win10)
1GByte のファイルをコピー
その際のWindows上での速度を記録

2)PCAUSAのTest TCP (PCATTCP) というフリーのツールを使い測定

 

■測定結果
1)
・IPv6
約8MB/s=約64Mbps

・IPv4
約3.6MB/s =約28Mbps

 

2)
・IPv6
約48Mbps

・IPv4
約23Mbps

 

 

※測定する時間はいろいろ変えてみましたが、たまたま混んでない日だったのか
時間帯による変化はほぼありませんでした。
夜間遅いときに計りたかったのに、こういうときに限って混雑してないという・・・・
ただ測定した日は、それぞれのルータがつながっている網終端装置は「それなりに」混んでいる とNTT/プロバイダからは聞けています。

測定方法によって、値は結構ことなりますが(特にv6)
おおむねv4の倍の速度が出ているようです。思った以上に良い結果ですね。

「フレッツv6オプション」の場合、NTT東西間は接続できないことや、インターネットの速度遅延は解決されない

等の問題はありますし

この後の弊社でのサービス化についてはまだ準備/確認これからですが、現状困っているお客さまに対しての

解決策となればと思います。