日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

ヘビーユーザーには痛いかもしれない

一部のTwitterで使われていたUserStreamという機能が今日以降順次廃止となる。

UserStreamというのは、Twitterのタイムラインがリアルタイムに受信できる機能で、

クライアント側からタイムライン取得を行わなくても、タイムラインが取り逃しなく取得できて、

API制限も回避出来るということで、ヘビーユーザーには人気が高い機能だった。


まぁUserStreamが廃止になったところで、従来からのAPIは基本的に使える。

ただ、タイムライン取得は15分間で15回、すなわち平均1分に1回しか取得できない。

従来のUserStreamはリアルタイムだったから、比較にならないぐらい遅い。

でも、よく考えたら1分に1回でもそこまで問題はないか。

1回のAPI発行で取得できるのは最大100件なので、1分で100件以上流れると取り逃すことになる。

投稿数の多いユーザーを大量にフォローしてると問題だろうが、そうでもなければ許容できるのでは?


背景としてはTwitterをWebや公式クライアントで閲覧してくれれば、広告など差し込めるが、

非公式クライアントを使って閲覧されたところで、Twitterとしては収益を上げにくいという事情があるようだ。

1つのAPIキーで10万アカウントが上限になる規制が導入され、一部の非公式クライアントでは新規登録を中止している。

そういう事情を考えると、非公式クライアントの存在は経過措置のような感じはある。

一気に廃止するとユーザーが離れてしまうが、かといって、非公式クライアントを利する気はないという感じかね。


じゃあ、公式クライアントを使う方向へ向かうべきではないだろうか?

という話もあるのだが、納得できない点が多い。

WebでTwitterにアクセスしたときに困るんだけど、1つが時系列順じゃないこと、1つが希望しないTweetが表示されること。

時系列順にならないことについては「重要な新着ツイートをトップに表示」を無効化することで解除できる。

時系列順ではないというのは、Twitterが判断した過去の重要そうなTweetを優先表示する仕組みがあるから。

これが的外れであると感じることが多いので、じゃあ素直に時系列順でくれという話。

希望しないTweetというのは主にプロモーションが主だが、それ以外にもタイムラインとは差異があるようだ。


設定次第で不都合は軽減できるが、やはり慣れたクライアントに比べると使いにくいと感じるもので。

UserStreamは廃止されたとしても、それ以外は従来通り使えるなら、今まで通りのクライアント使うかとなる。

公式クライアントに比べて対応する機能がやや限定されるなどの制約はあるのだが、

それでも慣れてるクライアントを使える方がメリットあるなと。

特にWindowsのデスクトップアプリとしては公式クライアントないしね


もうTwitterはダメだという話もあるけど、極端に流速が速くない僕にとってはあまり変わらないなと。

そもそもTwitterはミニブログですからね。更新を1分間隔でポーリングするのはやり過ぎ感もある。

未読が100件超えると抜けることが問題だから1分間隔でポーリングするけど、というのが実情かなと。

世の中でTwitterを広報手段として活用しているのは変わらないわけで、今後もうまく利用して行くのがよいのかなと。


Author : hidemaro
Date : 2018/08/17(Fri) 22:28
Linux・Net・Web | Comment | trackback (0)

ダイアルアップの名残がないフレッツ光

引越にあたって、フレッツ光の回線を新しく引いてもらう必要はあるが、

回線さえ引ければ、プロバイダーには特段の手続きをしてもらわなくてもインターネットに接続できる。

というのも、PPPoE接続の場合は、プロバイダーはユーザーがどの回線を使っているか特定する必要はないから。


情報処理技術者試験の勉強をしていて、PPPoEの意味を知ったんだけど。

そもそも、ダイアルアップ接続の方式としてPPPという方式がある。

もともとは電話線で使っていた方式だが、ユーザーを認証する仕組みとしては、光回線でも有用なので、

電話線ではなくEthernetにPPPフレームと同等のデータを流す方式としてPPPoEという方式が作られたらしい。

フレッツ光はNGN網への接続を提供するサービスで、もともとNTTは法律の規定により都道府県を越える通信サービスが提供できなかった。

現在は都道府県を越えることもできるのだが、インターネットとの接続はNTTは行っていない。

そこでNGN網に設けられた相互接続点(POI)に対して、NGN網のEthernetを介してPPPのフレームを送ると、POIからインターネットに出られる仕組みになっている。

結局は電話線がNGN網に変わっただけで、やってることはあまり変わっていないとも言える。

電話線の時代はプロバイダーと契約していれば、そのプロバイダーのいずれかのアクセスポイントに電話をかければインターネットに接続できた。

それと同じことができてしまうと。


NTTと違って回線とプロバイダーが一体化されているCATVインターネットはもっとシンプルな仕組みだ。

引越前に使っていたCATV会社では、モデムにルーターまたはPCを接続すると、DHCPでIPアドレスが付与される。

IPアドレスは1回線につき1つだけ割りあてられるが、グローバルIPアドレスだった。ここから直接インターネットに通じているということだ。

1回線につき1台しかIPアドレスが与えられないので、2台以上のPCを接続する場合はルーターが必要だが、1台ならばなにもいらない。

とはいえ、PCが直接インターネットにつながるとセキュリティ上の懸念があるのだけど、

Windows共有が他の契約者との間で通じないようにVLANで契約者ごとに独立したセグメントにするぐらいの対策はやっていたはずだが。


明らかにフレッツ光の接続方式は複雑だが、それゆえの問題があって、それがPOIの混雑。

フレッツ光とはなんぞやと

引越前に調べてましたね。2014年ごろまで、Bフレッツからフレッツ光への移行期にはこの混雑が大きな問題になった。

現在はある程度落ち着いたとされているが、全く問題が無くなったというわけでもない。

こういう問題はCATVインターネットでは発生しないはず。光でもeo光のようなプロバイダー一体のサービスでは起きないはず。


といっても、それがフレッツ光のやり方だしね。と思っていたら、どうもPPPoEを使わない方式もあるらしい。

excite MEC光

exciteはIIJの回線を卸で買って、大した付加機能を付けずに小売してるんだけど、

これもそうでIIJが提供しているサービスを、シンプルに売っているだけのものだ。

IIJ IPv6 FiberAccess/Fサービス タイプIPoE

PPPoEに対してIPoEと呼ばれている方式だが、IPoEって普通のEthernetじゃねーか。つまりそういうこと。

NGN網にPPPフレームではなく、普通にIPフレームを流すことができる方式なのだ。

ただし、IPv6に限る。これが難点である。


そもそもNGN網はIPv6で構成されていて、ひかりTV や ひかり電話 はIPv6でNGN網に接続している。

これをそのままインターネット接続に使うのだが、ただフレッツ光と契約しただけではそれはできない。

すでにフレッツ光を使っているユーザーがIPoE方式を使うための手順は次の通り。

  1. フレッツ・v6オプションに登録する(無料)
  2. NTTに回線とVNE事業者(IIJの場合はインターネットマルチフィード)の紐付けをしてもらう
  3. 24時間以内にIPv6でインターネットに接続できるようになる
  4. IPv4のアクセスが必要な場合はDS-Lite方式でIPv4のパケットをカプセル化して送受信する

これを見てみるとわかるけど、回線とインターネット接続が紐付けられるという点ではCATVインターネットと似ている。

ちなみにインターネットマルチフィードはNTTとIIJが主になって設立された会社で、実質、IIJみたいなものだ。

VNE事業者の数に限りがあるので、集約することが求められたので、NTTとIIJはIPoE方式でのNGN網とインターネットの接続をこの会社に託したわけだ。

もっとも後にNTTコミュニケーションズがVNE事業者になったので、現在はNTT系の OCN や ぷらら はそちらに移行しているらしいが。


ただし、フレッツ光のIPoEでは IPv6 でしかインターネットに接続できない。

この問題を解決するために、インターネットマルチフィードはDS-Lite方式を使ったTransixというサービスを提供している。

transixサービス

IPv4のパケットをカプセル化して、インターネットマルチフィードのゲートウェイでIPv4にするわけだ。

DS-LiteはIPv4 over IPv6と呼ばれる技術の1つだが、この方式では複数人で1つのIPv4アドレスを共有する。

IPv4アドレスの枯渇には強いが、従来は1回線に1つIPv4のグローバルIPアドレスが割りあてられていたのと比べると不都合という話もある。

IPv6アドレスは少なくとも /64 は割りあてられますけどね。すなわち何台でもIPv6のインターネットに直接接続できるということ。

かといって、宅内にL2スイッチだけ置いて、複数台のPCを接続すると、外からPCにアクセスし放題になってしまうので、

結局はファイヤーウォールを置くなりしないといけないんですけどね。

DS-Liteに対応したルーターを買って置くという話なんでしょうね。


ところで、IPoEを使う手順にフレッツ・v6オプションに登録すると書いた。

実際はプロバイダーが勝手にやってくれるという話もあるが、何らかの形で登録される。

これ、何なのかというとNGN網折り返し通信が可能になるサービスらしい。

これに登録しなければ、NGN網はPPPoEの接続や、ひかりTV・ひかり電話の接続にしか使えない。

これに登録すると、NGN網に接続されている他のユーザーとも通信が出来る。

会社だとA事業所・B事業所でともにフレッツ光を契約して、v6オプションの登録を行うと、

A事業所・B事業所間でインターネットを介せずに通信ができる。

最初にNTTが都道府県を越えるサービスを提供できるようになったというのはこのことで、

NGN網内なら都道府県はおろか東日本・西日本の会社の別を越えて、インターネットに出ずに通信ができる。


IPv4だと必然的にこういうネットワーク構成になるしかないという面が強かったが、

IPv6になるとネットワークの構成や設定もいろいろな選択肢があって、なかなか難しいなとは思う。

家庭のネットワークでさえ、まずインターネットでのIPv4とIPv6の共存というところでいろいろ選択肢がある。

実はIPv6はIPoE、IPv4はPPPoEというのも選択肢の1つとしてはある。まぁPOIの混雑を回避するという目的にはかなわないけど。

IPv6の通信をどうやって取り扱うかというのも、ひかりTV や ひかり電話 の機器をネットワーク上のどこに配置するかとか。

セキュリティをどうやって確保するか、外との通信をどうやって確保するかというのも選択肢が多い。

あまり考えなくてもいいようにNTTもルーターをパッケージ化したりしてやってるみたいですけどね。


Author : hidemaro
Date : 2018/08/13(Mon) 21:48
Linux・Net・Web | Comment | trackback (0)

Google Chromeも可になったが

先日、勤務先の全社で標準アプリケーションとしてGoogle Chromeが追加された。

用途は社外のWebサイトの閲覧のため。

従来は標準アプリケーションのWebブラウザとしては Internet Explorer しかなかったのだが、

社外のWebサイトの閲覧に支障をきたすことがあるという理由で、代替策としてGoogle Chromeが追加されたのだという。

もっともそれ以前から職場単位でGoogle Chromeを使えるようにしているところも多かったようだけど。


社外のWebサイトの閲覧に支障をきたすことがあるというのは、

特定のWebサイトを見るとしばらくフリーズするような問題が発生するから。

どういう条件で発生するのかは調べてないんだけど、特定のWebサイトでは必ず発生するんだよね。

この問題に対する対策として、他のブラウザで社内での利用実績もある Google Chrome を使うことにしたようだ。

確かにChromeを使えばこのような問題は起きない。


一方で 社外のWebサイトの閲覧用となっているのは、社内のWebサイトの一部はInternet Explorerでしか使えないから。

基本的にChromeでの動作は保証されていない。

問題なく使えるページもそれなりにあるし、見た目が多少崩れる程度なら許容できるが、全く機能しないページも多い。

傾向を調べてみると 認証機能が対応していない、JavaScriptがActiveXに依存している、Microsoft製のシステム というところ。

認証機能が対応していないのは、おそらく回避策がありそう。同種の認証でもChromeで使えるページもあるわけだし。

JavaScriptがActiveXに依存しているのは、ActiveXに依存しないJavaScriptへの書き換えは可能だろう。

今後、社内のWebサイトでもChrome対応をすると書かれていたから、このあたりの問題も解決していくのだろう。

一方で、Microsoft製のシステムは、Internet Explorerの使用を前提として、Windowsと調和性の高いものを作ってるんだろうし、代替できないのでは? とも思う。


個人的には Mozilla Firefox をずっとメインで使ってるけど、あまりこだわりがないのならGoogle Chromeは無難でよい選択肢だと思う。

一方で職場で使っている限りにおいては Internet Explorerもそこまで悪くないのでは? とも思っていた。

特定のサイトでフリーズする問題は致命的なので、そこは問題だったのだが、

ただ、Windowsとの親和性という点ではメリットがあったことも確かで、それなりにメリットはあったと思う。

一般的にはOSやブラウザに依存するWebサイトはよくないけど、社内で使う限りにおいては許容できるし。


というわけで、最近はInternet ExplorerとGoogle Chromeで2窓して仕事をしている。

社内の設計資料を見るのはInternet Explorer、メーカーの資料を見るときはGoogle Chromeと言った具合。

本当はこの2つを1つのブラウザで両立できればよいのだが。


Author : hidemaro
Date : 2018/06/07(Thu) 21:49
Linux・Net・Web | Comment | trackback (0)

上位64ビットと下位64ビット

往復のバスで、ネットワークスペシャリスト試験の本を見ながら勉強をしていた。

名前は知ってても中身はよく知らなかった技術、名前も知らなかった技術、いろいろあるんだなぁと。


IPv6のIPアドレスは128ビットと非常に長い。

IPv4ではグローバルIPアドレスを個々のクライアントに割りあてることは難しく、

各クライアントにはプライベートアドレスを割り当て、家で1つのグローバルアドレスを共有するとかやっていたが、

IPv6ではアドレス空間が広いので、全ての機器にグローバルアドレスを割りあてることができる。


ところで、このIPv6のIPアドレスの割り当て方だが、

上位48bitはルーティングプレフィックス、それに続く16bitがサブネットID、最後64bitはインターフェース識別子というのが標準らしい。

ルーティングプレフィックスはIPアドレスの割り当てを受けた会社などを表し、

サブネットIDはその中で細分化されたセグメントを表す。

すなわちA社がIPv6のアドレスの割り当てを受けると、2001:db8:1234::/48 のように割りあてられる。

そして、社内のネットワークセグメントに対して 2001:db8:1234:abcd::/64 のように割りあてていく。

その上で最後の64bitのインターフェース識別子だが、MACアドレスから生成する方法が標準的らしい。

例えばMACアドレスが00:00:5E:00:53:00の機器が、2001:db8:1234:abcd::/64 のネットワークにいる場合は、

2001:db8:1234:abcd:0000:5EFF:FE00:5300 というIPアドレスを使うという具合に。

だから、IPv6の場合はDHCPなしでも自動的にIPアドレスを割りあてられるとされている。(DHCPを使うこともできる)


ここで、あれ? と思った。

それはMACアドレスというだけで世界中で一意なはずなのに、

なんでIPv6は48bitのMACアドレスよりはるかに長い128bitのアドレス空間を持っているのだろうと。

MACアドレスはネットワークの第2層(データリンク層)で重要な役目を果たしている。

このレベルではパケットのあて先をMACアドレスで表している。

その役割からすればMACアドレスは同一セグメント内で被らなければよいが、原則として世界中で被らないようになっている。

なぜ、その48bitでは全く足りないのだろうか?


日常生活に例えてみると、例えば「山田太郎」という名前の人は世界中に1人しかいなかったとする。

世界中で1人しかいないので、職場にも1人しかいない。というわけで、職場で山田太郎さんを呼べば必ず一意に決まる。

これがデータリンク層でのMACアドレスの役割。

とはいえ、世界中で一意だからっていって、世界中どこかにいる山田太郎さんを探すのは現実的にはできない。やはり住所が必要だ。

IPv6のアドレスは、前半64bitが住所相当、後半64bitが名前相当ってことですね。

前半64bitの住所相当でネットワーク上のどこにいるか特定して、あとは後半64bitでネットワーク内の誰か一意に特定するってわけですね。

これがIPv4のときはグローバルアドレスでは上で言うところの住所相当しか表せなかったと考えるとよい。

そこから具体的に誰と通信するかというのは、ネットワークアドレス変換(NAT)任せだった。

IPv6ではどこの誰かというのが全てアドレスに収まるから、全クライアントがグローバルアドレスを持てるってわけ。


ちなみにIPv6ではプロバイダーには原則として/32単位でアドレスを払い出しているそう。

プロバイダーはユーザーに/48単位またはそれより細かい単位で払い出す。

そして各ネットワークセグメントには原則/64単位で割りあてるというわけだ。

別に/64より細かく割り振ってもよいのだろうが、MACアドレスからの自動生成の都合も考えるとこれがよいということらしい。

なんでIPv6は/64が最小単位なんだろ? って思ってたんだけどそういう意味だったんですね。

かなり荒っぽい割り振り方に見えるけど、アドレス空間が非常に広いので問題なしということらしい。


確かにIPv6のアドレス空間が広いことは知ってたけど、具体的なところはあまり知らんもんだなと。

他にもIPv6関係でいろいろな技術が紹介されたけど、いやはや。


Author : hidemaro
Date : 2018/03/06(Tue) 23:50
Linux・Net・Web | Comment | trackback (0)

新gTLDだから取れたドメイン

金曜に出勤したら、勤務先のグループ会社が新しいWebサイトに移行するということが発表されていた。

複数のドメインに分散していた情報を1つに集約するという意図もあるようだ。

そのドメインを見て驚いたんだけど、最近増えたgTLDだったんだよね。


ドメインというのは大きく、generic top-level domain(gTLD) と country code top-level domain(ccTLD) に大別される。

gTLDは .org のように地域によらず(.govのような例外もあるが)使われるドメイン、

ccTLD は .jp のように国・地域ごとに割りあてられたドメインを指している。

伝統的には gTLD というのは .com, .net, .org, .gov, .edu, .mil の6種類だった。

ところが2000年以降、.info, .biz などのgTLDが少しずつ増えてきた。

そんな中で2012年、条件を満たせばgTLDの新設ができるようになった。


具体的にはこういうこと。

いよいよ始まる、東京のドメイン「.tokyo」各ドメイン登録サービス提供事業者で先行登録受付開始~ インターネットを通じて東京を世界へ ~ (GMOインターネット)

トップレベルドメインに「.canon」を採用 本日よりグローバルサイトを刷新  (Canon)

新しいgTLDはドメイン業者が申請して取る場合、業界団体が申請して取る場合、自ら使用するために企業が申請して取る場合などある。

GMOはドメイン業者として.tokyoドメインの新設を申し出ている。目的は .tokyo ドメインを売って儲けることでしょうね。

一方で企業が自ら使うために新gTLDを取得する例もあって、確か .canon はその世界初の事例だったはず。

まだ .canon の使用例はそこまで多くないが、将来的にはグループ内のドメインをここに集約したいんだろうな。


なぜ、新しいWebサイトで新gTLDが選択されたか?

その理由はおそらく3文字のドメインを取りたかったからだろう。

3文字のドメインというのは歴史のあるドメインではまず取れない。そんなに短いのは取り尽くされてるから。

.info や .biz も登場当初はそういうことができたが、今となってはそれも難しい。

そんな中、新gTLDはものすごい数があるから、そんな短いドメインも取れる可能性がかなり高くなった。

用途に適した新gTLDで空いているかは分からないけどね。そう考えるとうまいこと見つけたなぁと思うんだけど。


ただし、せっかく3文字のドメイン取ってもそこまで短くはないんだけどね。

元々、5文字+.com で計9文字のドメインだったが、新しいドメインは 3文字+6文字のgTLDだから、.入れて計10文字、1文字増えてんだよなぁ。

この会社、もともと3文字の会社で、なんとかそこを生かしたかったんだろう。確かに前より直感的ではある。

でも、旧ドメインも悪くはなかったと思うんだよなぁ。2文字を足して.comを取ってたわけだけど、それはそれで字面よかったしね。

どうしてもこの文字列でドメインを取りたいというなら、新gTLDに飛びつく価値もあるんだろうけど、

多少は変えてもいいよっていうのなら、無難なところから選ぶ方が総合的にはいいような気はするな。


新gTLDが新たな選択肢を増やすことに役立つならよいのだけど、こういう困った話もある。

アダルトサイトからブランド保護 (お名前.com)

.xxxドメインはアダルトサイト向けに2011年に追加されたgTLDだ。(なので一般的に申請でgTLD取れるようになる少し前のこと)

.xxxはアダルトサイト専用なので、ゾーニングに役立つという触れ込みで導入が認められた経緯があったようだが、

アダルトサイトが必ず.xxxを使ってくれる保証はないわけで、実態としては何の役にも立っていない。

その一方で自社の商標が.xxxと組み合わせて使われるのを不都合と考える人のために、保護用にドメインを取るということもできる。

お名前.comは保護用に.xxxなどアダルトサイト向けドメインの取扱を行っている。実用目的で使える.xxxドメインは取り扱っていない。

そんな商売ありかよって思うんだけど、新ドメインには原野商法のような側面もある。


ちなみに新gTLDと国際化ドメインの組み合わせというのもある。

例えば .xn—q9jyb4c 、これを見ても意味不明だが「.みんな」ってことですね。

はじめよう.みんな

なかなか国際化ドメインも使い所が難しいところだが、日本語ドメインならトップレベルまで日本語にしたいという話はあろうと思う。

日本語.jp のように日本語+ローマ字では中途半端じゃないかという話。

そう考えると国際化ドメインの新gTLDというのもニーズがあるのかなとは。

まぁそもそも日本語ドメインってのがどうなのよって話はありますけどね。


Author : hidemaro
Date : 2018/01/06(Sat) 23:55
Linux・Net・Web | Comment | trackback (0)

リモートアクセスのどれを選ぶか

今度、連日出張の予定がある。毎日通うので日帰り出張なんだが。

問題はこの出張期間と月末が被ること。どうしても月末にはやらないといけない処理がいくつかある。

どうしても月末処理ができない場合は課長に代理入力してもらうとか、代替策がなくはないのだが、正直めんどくさい。

これがきっかけになってリモートアクセスの準備をすることにした。


リモートアクセスはもともと出張先から会社にアクセスするという用途で、最近は在宅勤務という用途でも使われている。

在宅勤務向けに機能強化が行われ、現在は3種類のリモートアクセス方式が提供されている。

アプリ画面転送方式、VPN方式、シンクライアント方式の3種類だ。(社内での呼び名はこんな名前じゃないけど)

一体どの方式を選ぶとよいのだろうかと困ってしまった。


アプリ画面転送方式はおそらくこの中では一番利用者が多い方式だ。

もともと社外でのE-mail送受信のために、メーラーの画面を転送して表示する機能があった。

ただ、最近まではメーラーしか使うことが出来ず、添付ファイルの表示すらままならない状況だった。

これが在宅勤務対応として機能強化され、現在はブラウザやオフィススイートも一通り使えるようになった。

在宅勤務で使った人の感想を聞くと、「普通の事務作業ならば社内にいるのとほぼ同じように使える」とのこと。

アプリ画面転送方式は私物のPCでも使えるので、在宅勤務のために会社からPCを持ち帰りとやる必要が無いと。


VPN方式は、社外から社内のネットワークにアクセス出来るようにする方式だ。

この方式はPCが直接社内のネットワークにつながるので、社内のネットワークに接続できるPCであることが前提になる。

会社所有のPCを持ち出して、VPNで社内のネットワークに接続すると、ほとんど社内にいるのと同じようにPCが使えると。

機能的には最強なのだが、必ず会社所有のPCを持ち出す必要があるのが難点だ。

あと、使ったことある人に聞くと、VPNを導入する手順がめんどくさいらしい。確かに説明を見る限りはめんどくさい。


シンクライアント方式は、仮想PCの画面を転送する方式だ。

物理的なPCをレンタルする(基本的には業務用PCはレンタル)のと同じように、仮想PCをレンタルする。

するとその仮想PCは自分でカスタマイズでき、一定の範囲でアプリをインストールすることもできる。

画面を転送すること、私物のPCでも利用可なところはアプリ画面転送方式と同じなのだが、

カスタマイズ性が高く、社内でも社外でも仮想PCを使うことにすれば、全く社内・社外で使い勝手が変わらないことになる。

ただし、この方式は仮想PCをレンタルするという都合、他の方式よりもお金がかかる方式とされている。


今回はPCを持ち出す前提で考えたので、アプリ画面転送方式かVPN方式のどちらかだろう。

在宅勤務向けの機能強化が行われる以前だと、VPN方式にならざるを得なかったのだが、今はどちらでもやりたいことはできる。

持ち出し前提ならばVPN方式が一番高機能だが、導入手順がめんどくさいのが難点。

今回の用途はアプリ画面転送方式で対応でき、なおかつこちらは導入手順がとても簡単。

他の用途として、在宅勤務(といっても今は新人扱いで在宅勤務の対象外だが)などを想定しても、アプリ画面転送方式の方が好都合そう。


というわけでアプリ画面転送方式でリモートアクセスを使いたいと課長に言うと、

よろしいということで手続きが進み、即日利用できる状態になった。

シンクライアント方式は仮想PCのレンタルと言うことで重いけど、あとの2方式は部署負担が安いか無料かなのであまり気にしないようで。

初期設定も多少あるが、それもパスワードの設定ぐらいで、クライアント側はほぼ準備いらずだった。


あと、さっき試してたんだけど、実は自分のノートPCでも問題なく使えた。

もう最近はタブレットばっかり使ってノートPCを使う機会も減ってはいたが、久々に掘りだしてきた。

意外とサクサクと動くので、これならあえて会社のPCを持ち出さなくてもよいのでは? と思った。

このPCって今となってみればあまり性能がよくないんだけど(cf. Windows 10にしたかった)、それが想像以上に影響しない仕組みのようだ。

画面転送方式ってことは、このPC自体の性能にはあまり依存しない。その一方でオーバーヘッドもそう大きくない。

PC持ち出しのための手続きを進めて、承認はもらったけど、結局、必要なかったのかもね。

あんな腐ったノートPCで仕事にならんだろと思ったんだけど、意外とそうでもなさそうだった。


Author : hidemaro
Date : 2017/11/22(Wed) 23:33
Linux・Net・Web | Comment | trackback (0)

チェックを入れるだけで人間判定?

GoogleからreCAPTCHAのAPIのバージョンアップをしないと使えなくなるぞという連絡が来た。

reCAPTCHAはこのBlogでトラックバックスパム対策に使っている。

reCAPTCHAを使ってスパムよけ

画像の文字を打ち込むことでBotでないことを確認すると。


APIが変わるとどうなるんだろうということで見てみると驚きの変貌を遂げていた。

What is reCAPTCHA? (Google)

I’m not a robot(私はロボットではありません)というチェックボックスにチェックを入れるだけで、判定できるようになるらしい。

えっ、それで人間かBOTか判定が付くの? と思ったかも知れないが、別にこの行為だけで判定しているわけではない。

GoogleではreCAPTCHAにアクセスするユーザーの挙動を観察して、人間っぽいかBOTっぽいか調べているのよね。

ここで人間っぽいと判断されればチェックを入れるだけだが、BOTっぽいと判断されれば画像などを使った認証が必要となる。

デバッグ中にreCAPTCHAへのアクセスを繰り返したら、BOTっぽいと判断されてしまい、

「私はロボットではありません」にチェックを入れると、写真を使った認証画面が出てきた。

ここで正解すればチェックが入るという仕組みになっている。


以前からreCAPTCHAではユーザーの挙動を解析するということをやっていた。

人間っぽいと判断されれば簡単に読める文字が、BOTっぽいと判断されれば読みにくい文字が表示されていた。

これをさらに推し進めてreCAPTCHA v2では、人間っぽいと判断されればチェックを入れるだけでOKとすることにした。

さらにこれを推し進めたものとして Invisible reCAPTCHA というモードがある。チェックを付けなくても認証が完了するモードだそうで。

一方で、BOTっぽいと判断されたときの問題も文字を打たせるではなく、写真を選ばせるという問題に変わっている。

これはスマートフォン・タブレットでの使い勝手を考慮してのことらしい。

人間にとっては易しく、BOTにとっては難しく、ということを考えると文字認識という問題はやめた方がよいと考えたようだ。


導入法だが、まず、上記WebサイトでAPIキーを入手する。

そして、認証を必要とするページのHTMLにコードを貼り付ける。

最低限、script要素とdiv要素を1行ずつ貼るだけで完了する。

その上で、認証結果を受け取ったら、APIのURLにシークレットキー・認証結果・ユーザーのIPアドレスを投げると、

認証結果がJSONで返ってくるから、successがtrueかfalseか確認する。

サンプルコードを探してきて貼ってもいいけど、自分で書いても高々知れているので、今回は自力で書いた。


というわけでトラックバックURL作成ページを見てみると、

「私はロボットではありません」のチェックボックスが表示される形式に変わっているはず。

実態としては使用実績はごく少ないんだけど、今後も安心ということで。


そしてもう1つ、reCAPTCHA使ってるところあったな。

メールアドレスを隠すのに、Mailhideを使ってるんだよね。

Mailhideは古いreCAPTCHAのAPIを未だに使ってるので、大丈夫かなぁと。

Mailhide側で新しいAPIに移行してくれれば対応不要なんだけど、そもそもメンテナンスされてるんかいって話。

reCAPTCHA v2を使ってE-mailを隠すものを自作しますかね?


Author : hidemaro
Date : 2017/10/20(Fri) 23:40
Linux・Net・Web | Comment | trackback (0)

無料で自動の認証局

明日から徳島に出かける。

今日はえらく涼しかったけど、明日からは暑いんだそうで。

徳島にいると、外にいる時間が長いだろうから、なおさらねぇ。


だいぶ前から気づいてたんだけど、StartSSLの証明書がGoogle Chromeで安全ではないと表示されるようになった。

これは、StartSSLがポリシーに反する証明書の発行を行っていたことに対する対抗措置だ。

グーグル、中国の認証局WoSignの証明書を拒否へ--「Chrome 61」から (CNET Japan)

そもそもの問題を引き起こしたのは中国のWoSignという認証局なのだが、

WoSignはStartSSLを買収して傘下に収めていて、なおかつWoSignの中間証明書をStartSSLに署名させていたので、巻き添えを食らうことになった。


有効期限が切れて、新しい証明書に変えるときに別のところに乗り換えようとは思っていたのだが、

どうせ自分しか使わないんだし、エラーを無視してアクセスして、当面は使い続けようと考えた。

ところが最近、エラーを回避してアクセスすることができなくなってしまったので、早急に対策が必要となった。

他の認証局で無料で使えるところはないんかと調べていたら、Let’s Encrypt という認証局があることがわかった。

ドメイン認証による自動・無料の証明書発行システムが特徴で、

すでに多くのブラウザで導入されているIdenTrust社の署名を受けているので、無料で入手できるSSL証明書としては十分なものだ。


無料はともかく自動ってどういうことよってこういうこと。

Certbot

ドメインを持っているのが前提だけど

ここから certbot-auto というスクリプトをダウンロードして、

# ./certbot-auto certonly

として、多少の必要事項を入力するだけで、自動的にドメイン認証を行って証明書が発行される。

さらに、オプション次第ではApacheへの設定まで自動でやってくれる。

# ./certbot-auto –-apache

ただし、有効期間が3ヶ月とやや短いので、更新の頻度が高くなる。

でも、そもそも証明書の発行が自動化されているので、更新も自動的にやらせればよく、

cronとかで定期的にコマンドを実行すればよいと書かれている。

40 2 * * 0 certbot-auto renew 2>&1 | grep Congratulations
44 2 * * 0 service httpd reload >/dev/null 2>&1
45 2 * * 0 service postfix reload >/dev/null 2>&1
46 2 * * 0 service dovecot reload >/dev/null 2>&1

毎週日曜日の早朝にcertbotを実行して、自動的に更新を試みてもらう。

有効期間が1ヶ月以上残っている場合はそのまま、1ヶ月を切ったら更新をするということになるようで。

その後、Apache・Postfix・Dovecotに更新後の秘密鍵・証明書を読み込んでもらう。

おそらくこれでいけると思うんだけどね。


僕がStartSSLの証明書を使っていたのは無料だからということに尽きる。

オレオレじゃないSSL証明書を作りにいった

それ以前はオレオレ証明書だったんだが、やっぱり認証局証明書をインストールするのは手間ですから。

一方でStartSSLは有料での証明書発行も行っており、大手よりも割安ということをウリにしていた。

商売としての肝はこっちなのだが、せっかくお金を出したのに、ブラウザに弾かれてはたまったもんではない。


これだけ見れば安かろう悪かろうという話だろうと捉えることも出来るが、そうでもなさそう。

グーグルが無効化を発表、シマンテックのサーバー証明書にダメ出し? (ITPro)

Symantecの認証局ってもともとはVerisignのもので、いわば認証局の名門とも言えるところ。

とんでもない大ごとなのだが、さすがにSymantecはそのまま投げ出すようなことはしないよう。

どうするのかというと、Symantecは認証局事業をDigiCertという既存の認証局に譲渡してしまう。

そして、以前からのSymantecのお客さんにはDigiCertの証明書を発行する。これで無効化の影響は抑えられると判断したようだ。

さすが大手とも言えるが、一方で大手の認証局すらも1つ問題を起こすだけで弾かれてしまう世界でもある。


ちょっと話が脱線してしまったが、StartSSLは商売として認証局をやっていた。

一方、Let’s Encryptは無料・自動というコンセプトでやっているので、完全に非営利の認証局だ。

SSL対応を後押しするため、最低限、安全性を確保できる認証局ということでやっているのだろう。

確かにこういう認証局があれば、安心してSSLを導入できるという考えになれるだろうな。

一方で、組織の実在性とかそういうことを証明するものではないので、そこで他の認証局とのすみ分けがある。

あくまでもSSL通信の安全性を担保することだけが目的ということだ。ただし、その用途では最適な認証局だろう。

そうそう、これが欲しかったんだって話ですね。


Author : hidemaro
Date : 2017/10/07(Sat) 23:51
Linux・Net・Web | Comment | trackback (0)

投票ボタンを送る

あまり一般的に使える機能でもないんだけど……

Microsoft Outlookでは投票ボタンという機能がある。

E-mailに投票ボタンを付けられる機能で、Exchangeサーバーに参加しているユーザー間に限って使える。

電子メール メッセージで調査を実施して結果を確認する (Microsoft)


この機能、そんなに使用頻度は高くないが、確実に出番がある機能ではある。

用途としては、

  • 部内全員に対して行われる調査(該当・非該当の確認)
  • 飲み会の参加・不参加の確認
  • 労働組合の採決事項の賛否の確認

最初に挙げたのは業務だけど、あとは業務外だね。

というか最初に挙げた調査って年1回しか行われないのよね。

業務で使ってるの年1回だけって言うと存在意義を疑われるが、業務外では役立ってるので。


この機能は回答者にとっても、回答を求める側にとってもメリットが大きい。

回答者にとってのメリットは、投票ボタンをクリック→コメントを任意で付ける で回答が完了すること。

回答を求める側にとってのメリットは、投票結果が表形式で見られること。

E-mailで任意に返信してもらう方式だと、集計は手で行う必要がある。

その手間が省けるというのは大きなメリットで、回答を求める側としては積極的に使っていきたい機能だ。

とはいえ、最初に書いたようにExchangeサーバーに参加しているユーザー間に限って使える機能なので、誰でも使えるもんではないんだけどね。


OutlookのE-mailは拡張機能がいくつかある。

1つが、会議の出席依頼を送って、それに対して出席・欠席・保留というのを選べる機能。

これも便利だよね。クリック1つで出席と回答できるし。

逆に返答不要の場合は、返信を要求しないを選らんで送ればいいんだけどね。そこはどちらも選べるのがポイント。

もう1つ、フラグという機能がある。E-mailに対して、アラームを付けたりできる機能で、通常は受信者が必要に応じて付ける機能だ。

ただ、送信者から受信者に対してフラグを付けることができるんだよね。

この機能を使うと、回答期限の直前にアラームを鳴らして催促させたりできる。

今まで何度かこの機能を使われたことがある。けっこうマニアックだが、確かに効果的な方法かなと。


なかなか一般的に使える機能かというと難しいんだけどね。

会議の出席依頼はThunderbirdでも対応してるように見えるけど、Outlookと相互に使ったことはないからよくわからん。

ただ、社内ではメールクライアントとか統一されているから、使えるものは使うでいいでしょう。

業務ではほとんど使わない機能だって、業務外で使い道があればそれはそれでよいだろうと。


Author : hidemaro
Date : 2017/08/24(Thu) 22:52
Linux・Net・Web | Comment | trackback (0)

なぜ常時SSL化をするか

最近、常時SSL化という流れがあるらしい。

BASEが独自ドメインも常時SSL化、グーグルの「SSL推し」に対応 (ITpro)

確かに、いろんなWebサイトでHTTPS使ってるよなぁ。


これまでも、パスワードや個人情報をやりとりするWebサイトではHTTPSを使うことは一般的だった。

HTTPSはHTTPの通信内容をSSLで暗号化してやりとりするもの。

この仕組みによれば、他に知られると困るような情報を安全にやりとりすることができる。

自分のサーバーでも、パスワードをやりとりするところ、プライベートなコンテンツはHTTPSを使っている。

クライアント証明書で通す

これはHTTPSのちょっと変わった使い方だけど、必要なところでピンポイントで使うという発想に違いはない。


それに対して常時SSL化というのは、必ずしも秘密にする必要が無い内容でも暗号化すると。

一般的に知られてるような内容をわざわざ暗号化するのは無意味と思うかも知れないが、

SSLには盗聴を防ぐ以外の目的もあって、そこに期待しているという話である。


盗聴を防ぐ以外のSSLの役割、それは改ざん防止という役割である。

SSLではサーバー証明書で相手が信頼できるか確認してから、End to Endで暗号化通信を行う。

以前、TwitterがEV証明書を使ってるって話を取り上げたことがあるけど(cf. そこでEV証明書がくるとは)、

TwitterにHTTPSでアクセスすると、ブラウザ上に「Twitter, Inc (US)」と表示され、相手が確かにTwitterであることを確認出来る。

そして、その内容はTwitterのサーバーを出てから、改ざんも盗聴もされていないことが保証されているわけである。

TwitterのWebサイトの内容が改ざんされていないということに価値を感じるかと言われると、それは微妙だが、

これがもし銀行のWebサイトだったり、行政機関のWebサイトだったら、改ざんされていないというのは重要な気がする。


常時SSL化の難点としては、通信のオーバーヘッドが増えることがある。

その一方でHTTPS限定の高速化技術もあるので、レスポンスが悪くなるとも限らないらしいのだが。

常時SSL化しても割が合うという算段は十分なり立つようだが、注意は必要だよと。


End to Endでの暗号化というのはけっこうメリットがあるという話を書いたわけだが、

逆に暗号化されていないからこそできることというのもある。

それがGoogle Chromeのデータセーバー機能である。

これはWebサイトのアクセス時、中間にGoogleのサーバーを介して、データを圧縮することで通信量を削減する仕組みだ。

Googleのサーバーが中間に入り、データの圧縮(ある種の改ざん)を行うということで、中間者攻撃と同じ仕組みである。

なので、この機能はEnd to Endでの暗号化を行う、HTTPSでのアクセス時は無効化されることになっている。

End to Endでデータの完全性を保証するということは、途中にデータセーバーの入る隙はないということである。


SSLを使わないと、データセーバーの恩恵は受けられるが、データセーバーと同様に中間者攻撃が入る隙がある。

逆に常時SSLを使うことで、盗聴防止・改ざん防止に強い効果があるが、その一方でデータセーバーのような存在は認められない。

常時SSL化の意味を理解するには、これがいい説明なんじゃないかなぁ。

その上でどっちがよいかというのは各自考えるべきということである。

世の中はGoogleの方針もあって、常時SSL化に傾いているようだけど。


Author : hidemaro
Date : 2017/03/24(Fri) 23:27
Linux・Net・Web | Comment | trackback (0)

Tools