弁天島 (和歌山県東牟婁郡那智勝浦町勝浦)
白蛇弁天の祀られている島。干潮時には陸続きとなる。ホテルの方のお話しでは、ご神体は「島そのもの」とのこと。
中国VPN規制の行方
VPNサービスを提供するGreenVPNが、7/1からサービスを停止した。
「監督官庁から通知を受けた」としているらしいが、中国政府によるインターネット閲覧の規制強化の見せしめである事は疑いようのない事実。
Bloombergの報道によると、中国政府は通信事業者各社に対して、VPN接続の規制を強化するように要請したらしい。
www.bloomberg.co.jp
これにより、2018.2.1までに、当局が未認可のVPNサービスは、グレートファイアウォールにより順次ブロックされる可能性が高い。
≪≪企業のリスク≫≫
国外の(中国にとって)有害なサイトとの接続をサービス化している「違法なVPN業者」に対する取り締まりが目的とは言え、通信を遮断する方法によっては、適正な事業者のサービスにも影響を及ぼすリスクはある。
通信が自由な通常の国での感覚では、VPNと言えば、事業拠点間を固定的に接続する時や、「リモートアクセス」時のセキュリティ強度を高める為に用いられる技術というイメージなのだが、こと中国に於いては、何かと規制の厳しい国内網から逃れ、安全/自由な海外事業者を中継して規制対象サイトへアクセスする為に用いられる。
(一般的には『内を固める』のが目的だが、中国では『外へ安全に逃げる』用途に使われる)
例えば自営でVPN-GWを稼働させている企業の場合、通常は中国電信当局への認可申請など行なわないであろうから、China Mobile(中国移動通信)、China Unicom(中国聯通)、China Telecom(中国電信)などのFW設定により、運悪くVPN通信を遮断される可能性だってある。
通信事業者の国内VPNサービスを使ったところで、中国当局未認可のインターネットVPNサービスである事は、自営VPN-GWと同じだ。
認可済み国際VPNサービスを利用し、中国国内は当該国際VPNサービスのアクセスポイントまで専用線接続すれば、(金盾を迂回するので)問題なく全てのサイトへアクセス出来るが、コストが馬鹿にならない。
国内キャリアの海外担当者とも相談したが、2018.2.1までは違法VPN事業者のみが規制対象に絞られるであろうから、当面 早急な対応は不要だと考えられるとの事だった。
ただ、2018.2の規制強化の対応で、当局がVPN接続の実態を新たに把握する事項も多々あるだろうから、次のフェーズとして、正規VPN事業者への規制が強化される可能性は残る。
ネットワーク速度計測結果
Pingコマンドを使った、経路(閉域型VPN、Internet-VPN)別・拠点別の簡易レスポンス計測ツールを作成した。
当該Batchファイルを各拠点のサーバに仕込んで、タスクスケジューラで1時間ごとに実行するようにスケジューリングした。
2週間程度ログを採取したので、回線種別ごとの平均値を掲載する。
(足回りがベストエフォート回線なので拠点(地域)によって若干のばらつきはあるが・・・)
SmartVPN/ファイバーコネクト(100M)* 約12～18Mbps
※アクセス回線は フレッツ光ダークファイバー
SmartVPN/光アクセスプランF(200M)* 約8～11Mbps
※アクセス回線は フレッツ光ネクスト
Internet-VPN/OCN・フレッツ光ネクスト 約40～66Mbps
※ベストエフォート 最大200Mpbs
Internet-VPN/OCN・フレッツ光ネクスト 約68～71Mbps
※ベストエフォート 最大1Gbps
Internet-VPN/K-Opt・インターネットHG 約2.5～3.0Mbps
※タイプS(ベストエフォート型・最大100Mbps)
Skypeの企業利用(2)
Skype 及び Skype for business に関して、再度 情報収集した。
(a)Skype(無料版)は、各機能ごとに通信方式をP2Pからクラウド・サーバ型へ移行しているが、全ての機能が完了したという情報は見つからなかった。ただし、大半の機能が最新バージョンでないと利用出来なくなってきている模様。
(b)Skype for Business(以下SFB)は、正規のクラウド・サーバ型のビデオ会議システム(マイクロソフト・旧Lync)。
(c)SFBを利用する場合、Skypeクライアント(PC側にインストールするソフト)は最新バージョンでなければならない。
(d)Skype(無料版)からSFBに通話する場合、Skype(無料版)クライアントは最新バージョンでなければならない。
上記より、Skype(無料版)の企業内利用時には、以下のような懸案事項が残る。
(1)通信方式の問題(P2P)
一部の機能が「旧Lync」サーバーに吸収されていないのではないか。この移行を積み残している機能について、P2P方式で通信される懸念がある。
(2)社内ネットワークのトラフィック抑止
音声・映像・画面共有のみの機能であれば、UTMなどの機器を経由させなくてもセキュリティ上の問題はないと考える。が、ファイル添付機能などの機能がある場合、セキュリティ対策は必須となる。トラフィック抑止の為に社内ネットワークを迂回させたい場合、ビデオ会議システムの機能はシンプルな方が良い。
(3)利用者を限定出来ない場合のリスク
以下の様な機能・条件の場合には、リスク回避の為、社内ネットワーク接続デバイスからの利用は避けたい。
①社外の不特定多数と接続可能
②ファイル添付などの機能がある
③意図せぬ相手から接続されてしまう危険性のあるP2P方式の通信 など
インターネットアクセスなし／CAPI2-ID4101エラー
随分前から、タスクバーのネットワークプロパティが「インターネットアクセスなし」となっており、(おそらく同時期から)イベントログに大量の「CAPI2-ID4101エラー」が出力されていた。
NetshコマンドでWinHTTP通信にProxyを設定して逃げていたが、原因が分かったので・・・
【事象】
(1)「インターネットアクセスなし」の状態になっている(インターネットアクセスは問題なく出来る)
(2)CAPI2-ID4101『ルート証明書の自動更新ができませんでした』エラーが頻発する(ルート証明書が古い訳ではなさそう)
※各APL処理に於ける実害は不明。(ルート証明書確認のタイミングに、WWWアクセスが遅くなる?)
【影響範囲】
社内の全Clientパソコン(除 ファイアウォールで直接通信を許可しているPC)
【環境】
(1)一般Userのブラウザはインターネットへの直接通信は出来ず(UTMのFirewallポリシーで通信拒否設定)、必ずProxy(Squid/RHEL)を経由せねばならない
(2)社内標準ブラウザ：IE11(ERP系業務など)、Chrome(SaaSや通常のWWWアクセス等)
(3)Proxy設定：冗長化対応の為に以下の設定にしている
①PACファイルを資産管理ソフトで各Clientに配布(PACファイルはローカルを参照)
②ADグループポリシーで「自動構成スクリプトを使用する」に設定
(4)WSUSを使用している(ルート証明書の更新は対象外→MSサイトに直接アクセスするはず)
(5)Client-OS：Windows7(近々Windows10に上げる予定) Windows10移行計画 http://ict33.com/migration.php
【原因】
IE11で、自動構成スクリプトのアドレスに、fileプロトコルでアドレスを指定する事がサポートされなくなった為。
fileプロトコルについて・・・
・標準的通信モジュール"WinInet"では有効
・WinUpdateなど用通信モジュール"WinHTTP"ではサポート対象外
Windows7のIE11では、自動構成スクリプトのPACファイルパスには fileプロトコルでアドレスを指定しているが、正常に動作している。
2015/秋頃から、「CAPI2-ID4101エラー」が頻発するようになった。
上記時期頃からWinHTTPモジュールが、「fileプロトコルでのアドレス指定」をサポートしなくなったと思われる。
Windows7のIE11では、まだ「fileプロトコルでのアドレス指定」をサポートしてくれているようだ。
【処置】
(1)WebサーバにPACファイルを配置
(2)DNS/DHCPサーバで、WPAD(Web Proxy Auto-Discovery)を有効にする
(3)ブラウザのProxy設定を、「設定を自動的に検出する」にする
【対策】
マイクロソフトに文句を言う ^^;
ネットワークの速度計測
Pingコマンドを使った、経路(閉域型VPN、Internet-VPN)別・拠点別の簡易レスポンス計測ツールを作成した。(といっても、単純なBatchファイルだが・・)
Expingが送信バッファサイズを4,096byteまでしか指定出来ないので、仕方なく。。
--------------------
:start rem 開始
echo 開始日時、 %date%,%time% > temporary.log
echo 【閉域型VPN】、 >> temporary.log
:Entry-VPN1 rem 閉域型VPN・主要拠点
ping "本社・閉域網WAN側グローバルIPアドレス" -l 20712 >> temporary.log
ping "支社・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "研究所・閉域網WAN側(G)IPアドレス"-l 20712 >> temporary.log
ping "PrivateクラウドDC・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
:Entry-VPN2 rem 閉域型VPN・工場
ping "A工場・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "B工場・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
（省略）
:Entry-VPN3 rem 閉域型VPN・営業所
ping "A営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "B営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
ping "C営業所・閉域網WAN側(G)IPアドレス" -l 20712 >> temporary.log
（省略）
echo 【Internet-VPN】 >> temporary.log
:Internet-VPN1 rem Internet-VPN・主要拠点
ping "本社・アクセス回線WAN側(G)IPアドレス" -l 1426 >> temporary.log
ping "支社・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "研究所・アクセス回線WAN側(G)IPアドレス" -l 1426 >> temporary.log
:Internet-VPN2 rem Internet-VPN・工場
ping "A工場・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "B工場・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
（省略）
:Internet-VPN3 rem Internet-VPN・営業所
ping "A営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "B営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
ping "C営業所・アクセス回線WAN側(G)IPアドレス" -l 65500 >> temporary.log
（省略）
echo 終了日時、 %date%,%time% >> temporary.log
:end rem 終了
find "、" < temporary.log >> response.log
--------------------
【Batchファイルについて】
ping、echo、find の3コマンドのみの使用
メインはpingコマンド
echoコマンド：ログを見やすくする為、コメント/区切り行を挿入
findコマンド：ping出力結果(=>temporary.log)の、必要な行のみの抽出・累積(=>response.log)
※抽出行の対象となる文字列は "、" とした
【通信速度の算出】
通信速度=送信データサイズ×8×2÷1,000,000÷(ping応答時間÷1,000)
通信速度：単位が Bits per Second なので、データサイズ(Byte)に8を乗じる
送信データ：Pingはデータを上り下りで送受信した結果の時間を返すので、2倍する
百万で除す：単位をMbpsにする為
応答時間÷1,000：単位が Milli-Sec なので、Secにする
【送信データサイズについて】
Ethernet(有線LANで最も使用されている規格だが..)に於いては、
1フレーム(データ送受信)の最大値は1,518Byte。(制御部:18Byte、データ部:1,500Byte)
※下記の(3)～(8)は、イーサネットにおけるデータ部を使用
これを超えるサイズのデータを送出する場合は、パケットに分割されて送信される。
パケットは各レイヤ(階層)で制御の為のヘッダー情報が付加される。
つまり、最上位レイヤでは 1,500－(各レイヤでのヘッダーサイズ) が実質のデータ部となる。
※これが MTU(Maximum Transmission Unit)となる。
各レイヤでのヘッダ情報は下記の通り。
(1) 8 Byte：プリアンブル…ディジタル・データ伝送で付加される、データ開始の同期符号
(2) 18 Byet：Ethernet(OSI第2層=データリンク層、ヘッダ&トレーラ)
(3) 20 Byte：IP(Internet Protocol：OSI第3層=ネットワーク層)
(4) 8 Byte：ICMP(OSI第4層=トランスポート層) ※1
-----以下はWANで付加されるヘッダ情報 ※2-----
(5) 16 Byte：L2TP(OSI第2層=データリンク層)
(6) 2 Byte：PPP(Point to Point Protocol：OSI第2層=データリンク層)
(7) 20 Byte：IP(OSI第3層=ネットワーク層)
(8) 8 Byte：UDP(OSI第4層=トランスポート層)
通信速度の算出に於いては、pingで指定した送信バッファサイズ(フレームサイズ)に、以下の通りヘッダーサイズを加算した。
想定MTU＝1,500ー{(3)～(8)の合計}
パケット分割数＝Round-Up{(送出フレームサイズ)÷(想定MTU,0)}
実質のデータサイズ＝送出フレームサイズ＋{ヘッダーサイズ(1)～(8)の合計}×パケット分割数
※1) ICMP(Internet Control Message Protocol)
pingはTCP/IPプロトコルではなく、ICMPというプロトコルで動作する。
ICMPはIPの上位層(トランスポート層)のプロトコルだが、ネットワーク層のプロトコルであるかのような特別の処理がなされる。
TCP/IP通信の場合、ヘッダー情報は40Byteとなる。
TCP(Transmission Control Protocol：OSI第4層=トランスポート層)：20Byte
IP(Internet Protocol：OSI第3層=ネットワーク層)：20Byte
※2) PPPoE(Point to Point Protocol over Ethernet)
Ethernetヘッダーに加えて、PPP(データリンク層)ヘッダー：2Byte、PPPoE(データリンク層)ヘッダー：6Byte が付加されるが、
ヘッダー情報のサイズはL2TPの方が大きく、MTUは最小値の指定が推奨されているのでL2TPのMTU値とした。
