博士の学位を取得する意味と、取得までのプロセス概要（理工系分野を中心として）

時期的に、卒論／修論／博論のラストスパートで死にそうな方々が多い頃だと思いますが、今から目の前に差し迫る締切までに、「ゼロからそういうものを書き上げる」のは多分不可能、と思う私が、「博士の学位を取得するにはどうする？」を、ざっと書いてみました。

言う以上、私自身は博士の学位を取得していますし、よかったことダメだったことを振り返って、以下にまとめています。

博士の学位を取得する意味と、おおまかな取得条件

博士号を取得できる＝「独力で研究テーマを決定し、結論を出す能力を有する」ことを認められることかなと考えてます。これは、学術研究を行う者としては必要な能力であり、自称研究者か、きちんとした研究者かを見分けるための指標の1つ*1とも考えています。

落ちこぼれ寸前で博士号を取得した者（5年かかったｗ）が言えることは…以下を客観的かつ論理の飛躍を起こすことなく説明出来ることが最低条件、ということですかね。具体的に何がどんだけ必要か*2は、大学や専攻によって異なるので、そちらを確認のこと。

0. 現状や世の中的な課題を俯瞰し、さらにその中から自分が取り組むテーマの無理のない切り出し
1. 取り組む事項や意義
2. 取り組むプロセスや結果、吟味の過程
3. 最終的な結論や残課題

ちなみに上で「論理の飛躍」と書いてますが、これはたいそうなことを書いてるわけではなく、通常の議論でよく見られる「このくらい分からないのか」「勉強すればわかる」「～は自明である」というような表現の多用や、「説明もないのに唐突に『これまで説明してきたように』というような書き出しで始まるまとめ」を極力排し、自分で説明するまでもなく他の文献で説明されていることは、「参考文献を提示」することで説明に替え、簡潔かつ過不足ない議論を展開することと理解しています。

考え方や議論に多様性を認めるのは大事です。しかし自身が主張する結論、それも工学的な意味を持たせたいものに対し、結論を多様に解釈されても困ります。なので、「多様な解釈を与えるスキを作らない」のがポイントであり、最終的な結論に行くまでに、多様な解釈を行う余地を、合理的かつ客観的に確かと判断できる「理由や根拠で削って」いき、本当に「自分が論じたいこと」に持っていく必要があるわけです。

博士号取得までのプロセス概要

個人的にやってきたかな、と思うことは…以下のような感じですかね。

0. 現状や世の中的な課題を俯瞰して切り出す過程は、自身できっちり悩み、客観的に表現することに加え、指導教官様や研究室のゼミ等を通じて磨き上げることを意識しましょう。ある意味博士研究の大前提とも言えます。
1. 取り組む事項や意義を、他者に説明して理解してもらえるかどうか？を確認するのが研究会報告の意義かと思います。なので、こうしてこうしてこうなった、という話を自由に出せる（＝査読がない）のは大事です。
2. 取り組むプロセスや結果、吟味の過程あたりを切り出して、正しく説明出来ているかどうかを検証してもらうのが、査読論文の意義です。これは正しさを評価していただき、よければ採録（ほとんどないｗ）、内容に飛躍や疑義があったら条件付き採録もしくは不採録
3. 0～2を積み上げて、最終的に何を見出したかを客観的に論ずる。(0)～(2)までをくまなくやっていれば、何を論ずるかは見えてくるはずです。

具体的にどうすればプロセス実践できるか？

具体的にどうやったら上記のプロセスを実践出来るか？は、教えたくても教えられません。体得するしか無い（あくまで個人の意見です）。

これは、「教えられても聞いた側は理解できない」からであり、「身を以て理解する時は一瞬」だからです。自分自身の経験と、他の方から伺った話を総合したら、こういう表現にしかならないよなぁ…という限界も感じてます。

これを「上から目線」とか「取った立場だから言える」というように言われたとしても、言われた側は困ってしまいます。単に「取った立場」から、これまでの行動を整理したらこうだった、と言ってるだけで、そこに立場の上下なんてないですし、仮に博士号を取れてない人から「こうすれば取れる」と根拠レスに言われても、それ何の裏付けもないですし無責任です。

やっちゃいけないこと

これまた難しいんですが、一番やっちゃいけないことは「論理の飛躍」を容認することだと考えてます。これは、自分の研究でも他者の研究でもあてはまりますし、偉大な研究者と称される方でもやってはならないことです。

例えば、Prof. Andrew John Wiles は、Fermat's Last Theoremを証明した人物として知られており、それ以前も数論の研究者として業績を積み重ねていますが、Fermat's Last Theoremの証明に係る論文の査読で、一度は致命的なギャップを指摘され、そのギャップを認めた上で、ギャップ解消を実現されました。この「ギャップ」こそが前述の「論理の飛躍」であり、これを認めてしまうと、荒唐無稽な説だろうとなんであろうと、全部「正しい」と言い切ることすら可能になります。

また、論理の飛躍を解消するために、飛躍した部分を「偽造」「改ざん」した結果で埋めるのは、最悪です。正しい結果で論理の飛躍を解消するのは当然よいのですが、そのために「偽造」「改ざん」した結果をひねり出すのは、当然ですがアカンことです。

やっちゃいけないことの例

本当はここで「自明だろう」と書きたいのですが、自分がすでに「それはアカン」と書いてしまってるので、1つだけ例示します。STAP細胞に係る一連の論文なんかが、私が今思い浮かぶ典型例だったりします。

STAP細胞が実在するしないの話はさておき（する派が相応にいると考えているため）、実在することを論ずる過程で改ざんがあるのは、改ざん部分がギャップである、と言ってるようなものです（ギャップがなければ、改ざんされた結果をそこに貼る必要もないし、ギャップがないのに改ざんするのはリスクが高すぎる）。

むすび

博士の学位を取得する意味とプロセス概要、やっちゃいけないこととその例をざっと書きましたが、別に新しいことは何もありません。

単にこれまで諸先輩方が実践されてきたことで、私も実践してきたことをまとめたものであり、意識することでより「後進の方々が研究のマイルストンを立てやすくなる」と考えて、ここに記しています。

これから研究される方が、実りある研究生活を送られることを、祈念しております。

*1:名乗れば誰でも研究者

*2:査読論文何編とか、そういう具体的に必要とされる成果の話

PrintNightmareその後（といっても1日しか経過してないけど）

PrintNightmare（CVE-2021-34527）は、修正ファイルがリリースされた模様

以下の記事を書いてから半日も経たないうちに、修正ファイルがリリースされた。

wakatono.hatenablog.com

修正ファイルは以下のところに。

修正プログラム名のところにSecurity Rollupと書かれてはいるが、これ立派にOOBリリース（定例外リリース）なので、見間違えないように。

msrc.microsoft.com

Print Spoolerサービスが止まるとPDFでの保存ができなくなる理由

自分も忘れていたが、PDFは「どんな紙に印刷されるのか」を想定した設定を行える。それこそA4縦とかA4横とか。

これらの設定は、Microsoft write to PDFの場合はPDFプリンタに設定に、Microsoft Office Professional Plus 2019の場合は（多分だけど）文書ファイル中の設定に記載され、PDF保存の際にはこちらの内容が使われる。

しかし、Microsoft 365 apps for enterpriseで使えるOfficeアプリの場合は、この設定をどうもPrint Spoolerサービスが稼働している時に見えるプリンタ（多分Microsoft write to PDF）からAPI経由で読み出しており、これがPrint Spoolerサービスが止まっている時には（プリンタが見えないから用紙の設定を読み出せない→）保存できない、というからくりのようだ。

でもこれ、明らかにavailabilityを落とす要因にしかならないので*1、改善したほうがよいとは思う。

*1:印刷するのとファイルを保存するのが関係するなんて、普通はあまり思わない

PrintNightmareめんどくせえ…

Print Nightmare（CVE-2021-34527）、修正プログラムがまだ出ておらず、Workaroundだけが出てる状態だけど（2021年7月7日 1:26時点）、この2つあるWorkaroundのうちの1つが一見面倒に見えて、1つがお手軽だけどいろいろと大変なことになる、という話し。

追記：修正公開されたようです（2021年7月7日 10:00時点の情報）。が、こんだけ迅速だと地雷埋まってないか心配。

Workaround自体は、以下のページに記述されている。

msrc.microsoft.com

Workaroundは2つ。Print Spoolerサービスを停止するか、ローカルポリシーを変更するか～Print Spoolerサービス停止は大いなる罠～

Print Spoolerサービスの停止はものすごい罠で、「Print Spoolerサービスを停止する＝ローカルにつながってるプリンタがリモートから見えなくなる」のは正しいんだが、ローカルのプリンタも見えなくなる。それもリアルなプリンタだけではなく、仮想プリンタ（例：Microsoft Print to PDFとかMicrosoft XPS writeとか）も見えなくなる。

とはいえ、仮想プリンタが見えないだけならば、WordとかExcelとかPowerPointの「保存する」で、「PDF形式」で保存すりゃいいんじゃね？と思うわけだが、これが大いなる罠だった（一部の環境の人にとって）。

• Print Spooler停止→WordとかでPDF保存出来ない（まじか）

Print Spoolerを停止したら、保存→PDF形式を指定してファイル保存できないと嘆いていた友人A。一方で、Print Spoolerを停止してもPDF形式を指定してファイル保存できるオレ。話を聞くと、にわかには信じがたい事実が判明してくる…。

検証開始～環境の差異はMicrosoft Officeのバージョンとアドオン有無

基本は環境の差異の確認なので、確認してみたら、わりかしあっさり出てきた（もっと面倒だと思ってた）。

• オレが使ってるOffice：Microsoft Office Professional Plus 2019
• 友人Aが使ってるOffice：Microsoft 365 apps for enterpriseで使えるOfficeアプリ。どうもAdobe Acrobatも入ってるっぽく、OfficeのAcrobatアドオンも含まれているっぽい。

Microsoft 365で使えるOfficeのアプリのせいか、Acrobatアドオンが悪さしているのかわからないが、友人Aの環境では、Microsoft 365 apps for enterpriseで使えるOfficeアプリケーションは（少なくともWordとExcelは）、PDFに印刷もPDFに保存もPDFにエクスポートも「全部同じコンポーネント（＝印刷）を通るっぽく、そりゃ使えないわ、という結論に。

Acrobatアドオンが悪さをしているのか、Microsoft 365 apps for enterpriseで使えるOfficeで挙動が変わったのかわからないが、PDF作成時の使用コンポーネントが統一されたっぽく、それでPDF作成が出来ない、と考えられる。

ちなみにMicrosoft Office Professional Plus 2019では、以下のような感じ。

• 「Microsoft Print to PDFへ印刷」と「PDFへエクスポート」は同じコンポーネントを使う
• 「保存」→PDFを選択、は、上記とは異なるコンポーネントを使う

よろしい。ならばローカルポリシーを変更だ

ということで、ローカルポリシーを変更する方法を提示*1。

mmc.exeを管理者権限で実行

→「ローカルコンピューターポリシー」のスナップイン追加

ローカルコンピューターポリシー

→コンピューターの構成

→管理用テンプレート

→プリンター

と進んで、右に出てきた項目から「印刷スプーラーにクライアント接続の受け入れを許可する」を選択して右クリック、編集→「無効」を選んで「適用」を押す。

→Print Spooler を再起動

文章にすると長いが、実際にやってしまえばすぐに終わる*2。

以下が、「印刷スプーラーにクライアント接続の受け入れを許可する」まで選択して、右クリックでメニューまで出した画面。

mmc.exe実行→スナップイン追加→該当ポリシー選択まですませた画面

で、編集を選択すると、以下のような画面が表示される。

ポリシー編集画面

オレの場合は、すでに「無効」にした後なのでこうなっているが、何もしてないと「未構成」になっている。ここは潔く「無効」にすることに。

ポリシーを変更したら、忘れずPrint Spoolerを再起動だ。お兄さんとの約束だぞ！

ここまでやってもPrint Spoolerサービスを再起動しないと無駄なので、サービス再起動をしよう。Print Spoolerを停止できる人ならば再起動もできるとは思うが、念のため画面は以下に。

サービス管理画面

上記はmmc.exeを実行→「サービス」スナップインを追加→サービス一覧表示→Print Spooler選択→右クリックまで済ませた画面。

ここで「再起動」を選んで左クリックでことたりる。

むすび～サービス停止は罠が多い＆慣れればポリシーいじるほうがラクだが、いじったことを忘れないように

今回、Print Spoolerサービスの停止が何気に罠が多いという知見と、ポリシーいじるのが意外にラクだという知見（の確認）の両方を得た（後者はドメイン環境だと当たり前なんだけど、あまり個人環境では使わないんだよね）。

ただ、あくまでこれはWorkaroundなので、修正プログラムが公開されたら早めの適用を。そして修正プログラムを適用したら、ポリシーをもとに戻すことも考慮するように*3。でないと、このポリシー変更でまた無用なトラブルを引き起こす、ということも考えられるので…。

*1:Print Spoolerを停止するのに比べれば手間はかかるが、やれば数分で終わる

*2:オレ自身は、mmc.exeを叩いてイベントログ見たりサービス一覧みたりというのをわりかししょっちゅうやるので、すぐに終わると錯覚しているだけかもしれんｗ

*3:リモートから印刷などさせないという話だったらそれでOK

smacircle S1に乗ってみた

我が家に来たsmacircle S1、やっと乗ってみた。徒歩10分くらい圏内をぐるりとまわった感じ。

簡単ではあるけど所感を…。

現時点の結論

感覚的には、今の時点では以下のような感じ

• まるでA-bike electricのような、相当癖のある乗り心地
• 現時点では、とてもじゃないけど万人には勧められない
• きちんと乗りこなすならば、結構慣れが必要

あくまで「現時点では」と前置いてますが、これらは小径車の宿命でもあるかなと思ってたりします。

www.wheelingtokyo.com

インプレッション

感覚的には以下のような感じ。

• 展開／収納はやっぱきつい
• 乗り味はかなり独特
• 幹線道路で乗るのはかなりリスキー

それぞれについて、詳細は以下に。

展開／収納はやっぱきつい

これだけど、やっぱ12kgくらいある本体を保持しながら、ロックボタンを押し込んで～というのはかなり厳しいと感じた。

さらにバックミラーとかウインカー／ナンバープレートとかの着け外しが、何気に煩わしい。

どんだけ慣れても、展開／収納で1分切るのはかなり難しそう（というか、バックミラーとナンバープレートがある時点で無理目）。

乗り味はかなり独特

アクセル／ブレーキが普通のスクーター等とは違うので、ホントに慣れが必要。

それこそ、ひとけのないところで運転練習するくらいの気持ちでいないと、相当危ないし、実際そういう道路で慣らし運転（？）してて一度こけた*1。自転車や普通の原付なんかでは、無意識で操作出来ているところを意識しなきゃいけないので*2、周囲を意識的に注意する＋運転を意識的に注意する、というダブルの気遣いで、かなり気疲れする。

普通の自転車に慣れてる／普通の原付*3に慣れてるという人たちがこれ乗ると、多分「こわい」と思う。なんというか、従前の車種とは全然別のモノだと思ったほうがいい。A-bike electricみたいなキワモノ自転車のほうが、種としては近い感じ。

ちなみにブレーキについては、摩擦音が全くしないわりにはよく効くので、結構気持ちがいい。

幹線道路で乗るのはかなりリスキー

最高速度が20km/hくらいだけど、これで20km/h出すのはかなり勇気がいる。

慣れれば～とも思ったけど、小径車でコントロール失いやすいのは、乗ったことある人ならばわかる話だと思う。

結び

悪くはないとは思うけど、きちんと乗りこなすには相当の慣れが必要。

特に、アクセルブレーキの操作が全く異なるのは、これまでのものと全く違うので、ここを承知の上で乗りこなす必要がある。

電動キックボードで5kmとか10kmとか乗りたいか？というのとノリはいっしょかなと*4。

*1:速度はほとんど出てなかったので、左ひざに擦過傷だけで済んだけど、速度が出てたら（たぶん）これだけでは済まないと思う

*2:普通のハンドルレバーやアクセルでないから、相当の操作をきちんと意識的にやらないとダメ

*3:スクーターやカブなど

*4:これだと正直、2～3km圏くらいがいいところではないか、と思うけど、慣れれば10kmでも20kmでも行ける人はいるかなとも

我が家にsmacircle S1がやってきた

我が家にsmacircle S1がやってきた。

まだ乗車してはいないが、やったことを淡々とメモしていく。

smacircle S1とは何か？

最近いろんな種類が出ている電動モビリティの1つ。

kibidango.com現物はすでに海外では販売されているが、日本で乗るためには保安部品の装着＆ナンバー取得が必須。

今回のkibidangoさんのやつは、この保安部品～具体的には、ウインカー、ナンバー灯、バックミラーなんかか～をつけて、日本でのレギュレーションを満足したものを販売してたり。

smacircle S1の最大の特徴

折りたたみ時のサイズが小さいこと。

あとで述べるけど、畳むと専用（？）のバックパックにバッテリー、ナンバー、バックミラーなんか含めて全部入ってしまうレベルの小ささはもはや反則。

買う前に留意すべき事項

それは、あなたの体重。

この電動モビリティ、耐荷重が100kgなのですが、これは当然持ち物着る物全部あわせてこの重さに収まっていないといけない。

乗りたいならば体重を減らそう。そうでもなければ別のものを選ぶのもアリかと思う。

現物が到着

紆余曲折して、現物が到着した。

現物（が入ってる箱）はこんな感じ。

現物が来たらやること（手続き）

大まかに以下のとおり。

なお前提は、乗る人が（最低限）原付免許を持っていること＆ヘルメットを所有していること。

1. 公道で走りたいのであれば、何はともかくナンバー取得
2. ナンバー取るならば、自賠責保険加入
3. まさかに備えて任意保険加入

オレの場合は、3は自家用車の任意保険に、ファミリーバイク特約を追加する手配をしていたので、1と2だけで済んだ。

ナンバーは区役所で取得可能（書類が揃っていれば、ものの10分で発行してもらえた）。任意保険はコンビニで10分でできた（ローソンでLoppi使って手続き）。

なお、当然といえば当然だが、順序は「ナンバー取得」→「自賠責保険加入」の順序でなければならない。

これは自賠責保険に加入するためには、車台番号とナンバープレートの情報が必要なため。ちなみに自賠責保険に加入していないと各種法律により罰せられるので、自賠責加入サボるな。

現物が来たらやること（車体関係）

1. ナンバー取り付け
2. ひととおりの組み上げ（展開）
3. 展開時の自分のスマートフォンとsmacircle S1の対応付け
4. 折り畳み

ナンバー取り付けが一番の壁。

交付されたナンバープレートに付属するネジが、smacircle S1についてくるナンバー取付用のステーのネジ穴よりも微妙に大きい感じで、取り付けだけでかなり難儀。

ネジについては、ひとまわり小さいボルトとナットの組を用意しておいてもいいレベル。

折り畳んでオプションのバックパックに全部詰めたあと

こんな感じになった。バックパックには、ナンバーがついたウインカー等のユニットと、シート兼用のバッテリーも入ってる。なお、カートは自分が前から持ってたやつ。

展開と折り畳みの印象

ナンバーの着け外しとミラーの着け外しが、結構面倒。

ほかはまぁ許容だけど、この2つが結構面倒。慣れればいいのかもしれないけど、という感じ。

とりあえず事前にチェックした感はこんなところ。

明日以降、乗った後の簡単なインプレッションを（書けたら）書くよ。

コインチェックのインシデント対応報告を読み解く

久々に（技術的にも実務的にも）良い意味で考えさせられる対応報告書を読んだ。

コインチェックの対応報告書がそれ。

読み解いてみたけど、存外に大変なことに（主にオレが書いた文の分量が）…。

コインチェックからリリースされたたインシデント対応報告

読んでいて、真面目な意味で面白く、かつ自分で考えようと思えばいろいろと考えられる報告書は、久しぶりに出会った。オレもこういう報告書を書けるようになりたい…。

corporate.coincheck.com

真面目な意味で「どこが」面白いのか？（あくまで私見）

あくまで私見ではあるが、「監視業務にてレスポンスの遅延を検知し関連システムの調査を開始」という1行が、ものすごく興味をそそられた。

その次に「第三者によりドメイン登録情報が変更されていたことを確認」という結果につながるのが面白い。

この間の経過時間は、おおよそ7時間ちょっと。

その7時間にどんな調査／確認が行われたのか？は、いろいろと考える価値があるのだが、「レスポンス遅延」から「ドメイン登録情報が変更されていた」という経緯が、「風が吹けば桶屋が儲かる」を連想するレベルで「？」となり、その後に「レスポンスの内容を考える」ことにつながった。

その結果、自分の知見の総動員とまではいかないまでも、結構な勢いで自身の知見から仮説の再構成をするに至った。正直相当疲れたけど、ものすごく面白かった。

調査開始から事案確認までに実施したことを想定する

 

以降は、調査開始から事案確認までに、コインチェックで実施したのではないか？という調査の内容を考えていたりする。

レスポンスの遅延を検知

こういう話が出てくると、レスポンスの遅延が何に起因して発生するのか？が気になってくる。

オレとかは、Webサーバ／Webアプリケーションサーバへのアクセス時に発生する処理を並べて、遅延が発生するとしたらどこ？というのを考える。例えば以下のような処理がざっと並びますが、それぞれでどうなったら遅延が発生するのか？を考えてみることに。例えば、遅延という話だと、以下のような話が考えられる。

• Webサーバ／アプリケーションサーバの性能不足
• Webアプリケーションの処理遅延
• 名前解決の処理遅延

次に、遅くなる傾向（一斉に遅くなる／偏って遅くなる／遅くなることもある）などから、例えば以下のような話が考えられる。実際の対応現場では、もしかしたらもっと多岐にわたった検討を実施したかもしれないが、オレが考えられるのはさしあたり以下のような感じ。

• 一斉にまんべんなく遅くなる場合
  単純にリソース不足。
  ロードバランサ等に異常はなく、均等に処理を割り振って、サーバ側の負荷が均等に上昇・処理量が増えている
  回線の帯域が逼迫している
  DNSの処理が遅延している
• 特定のサーバに偏って遅くなる場合
  リソースが少ない特定のサーバが遅くなっていたり、ロードバランサのバランシングポリシーが誤っている（Webサーバ／アプリケーションサーバのリソース搭載状態によって、バランシングポリシーを均等ではなく30%:70%に振り分けるなどはありえる、もしくは同じリソースを持っているWebサーバ／アプリケーションサーバに、アクセスを均等に割り振らなければいけないはずが、なぜかバランシングポリシーがそうなっていないか）
  特定のサーバに至る回線が逼迫している
  特定のDNSレコードのみ名前解決が遅くなることがある
• 特定の処理に偏って遅くなる場合
  特定処理（例えばDBMSトランザクションが入る処理）で処理遅延が発生する
  排他処理でリソース解放を待って遅くなる
  その他、希少リソースを取り合うなどの理由で遅くなることも
• ばらついて遅くなる場合
  サーバ側に上記のような問題がある
  ユーザからサーバまでの通信経路に（局所的に）問題が出ている
  DNSの応答が時々遅くなる

上記の項目を全部一人で～となるとさすがに死ぬし、解決までの時間がかかりかねないので、それぞれに詳しいメンバが調査にあたったはず。とはいえ、Webサーバ／アプリケーションサーバ、DBサーバ、DNS、ネットワークの負荷がどんだけかかってるか？というレベルのチェックであれば、きちんとした運用をやっているところであれば、（時間はともかく）確実に状況を把握できるはず。

この時点で、DNSはあくまで疑義があるパーツの1つであり、ましてやレジストラの登録情報が改ざんされているなんて普通は考えない*1。

Webサーバ／アプリケーションサーバのリソースも処理負荷も回線帯域も問題ない場合に見るところ～例えばNWの遅延

次に見るべきところは、NW上の（TCP/UDPレベルの）レスポンス遅延がどれだけあるか？という（わりかし）ミクロなところかなと思う。TCPはOSのプロトコルスタックが、UDPはアプリケーションが返すものだが、負荷に問題がない以上、おおよそのレスポンスを見積もるのはそんなに難しい話ではない。特に、国内のデータセンタ等に情報を置いているサービスであれば、海をまたぐレベルでの遅延はほぼ起こり得ない（除く沖縄）。

おそらくだが、ここで遅延をミクロに見ていたエンジニアが「おかしい」と気付いたのが、DNSのレスポンス遅延なのではないか。

原因はともかく、DNSのレスポンス遅延（フルリゾルバがキャッシュする前の、権威DNSからのレスポンスが遅い）は、遅くともこの段階で見つかる可能性が高い。ただ、DNSの負荷や経路に異常がない（DNS側から見たら、インターネット上の通信経路に異常がない）可能性は非常に高いので、システム側からではこういう話は気づきづらい。

権威DNSからのレスポンスが何故遅れる？～ここでDNSの配置が問題に？

権威DNSからのレスポンスが遅れる、でも権威DNSの負荷は問題なく、経路も問題ない、となると、レスポンスの内容を確認する動きになる。知らないDNSがいる、という話は、この段階でわかる可能性が高い。

権威サーバは、リクエストに応じてレスポンスを返すが、このレスポンスは通常は、途中に存在するフルリゾルバ（DNSキャッシュサーバ）に一定時間留め置かれる。フルリゾルバがDNSからのレスポンスをキャッシュしている場合には、遅延が発生せず、そうでない場合には遅延が発生するのではないか？と考えるに至る。

DNSの配置がなぜ問題に？

ここで、DNSの配置がなぜ問題になるのか？を述べておく。

DNS自体は、クエリをさばいてレスポンスを返す単純なしくみであり、不明な内容があると、（権威DNSであっても）それを知っていると思われるDNSにリクエストを送る。例えばだが、あるドメインにおいて、サブドメインまるごと委任した場合なぞは、委任された先にもDNSが設置され、あるドメインの権威DNSが情報を持っていないサブドメインに対するリクエストと判断された場合には、サブドメインの情報を持つDNSに問い合わせを送り、応答をクエリ元に返す。

当然この場合、単独のDNSのみで処理を完結するよりも時間を要する。さらに、国外にあるDNSが、国内にあるDNSにリクエストを転送するような処理を考えると、

国内→国外→国内という感じで、一度国内にある（委任先の）DNSにリクエストを送る。

なお面白いことに、ここで何気に「距離」が効いてくる*2。
物理的な距離が1000kmほど離れているところだとどの程度の時間がかかるか？だが、単純に委任先のDNSにリクエストが到達するだけでも、「国内→1000km→国外→1000km→国内」というように、2000km程度の時間がかかる。そして、光速度は30万km/秒と言われているが、光ファイバ内だとおおよそ6～70%程度まで低下するため、20万km/秒となる。この光速度で2000kmを移動するためには、0.01秒（＝10m秒）を要する。光速度不変の法則とかいわずにもっと根性出せや、と思うかもしれないが、これが物理法則から導き出される限界の1つである。

そういう目でDNSのレスポンスを見て、レジストラへの登録情報に目が行く

システムを運用してる側からしたら、システムが順風満帆に動作していることのほうが稀で、実際には小さいトラブルや不具合が発生しながらも問題ないレベルに局所化していることのほうが（多分）圧倒的に多い。

となると、まず「自分とこの不具合」を疑って、徹底的に調査を行い、不具合がないところでやっと外に目が行き始める。

そこで「外部要因の1つ」であるレジストラの登録情報に注目し、そこで改ざんに気がついた、というオチになったのではないか。

レジストラの登録情報が改ざんされていると発生する懸念

レジストラの登録情報～今回の場合はDNSの情報～が改ざんされていたわけだが、これはかなり重大で、ドメインを乗っ取られるのに等しい。

Webサーバが乗っ取られるのは、それはそれで困るが、ドメインが乗っ取られることは、リクエストそのものの最初の行き先を操られるというさらに困った事態に陥る。

レジストラの登録情報が改ざんされる＝DNSの情報が改ざんされる、と考えると、メールの行き先も改ざん者が自由に変えられる。改ざんされて登録されたDNS上のMXレコードを攻撃者が持つホストにすれば、coincheck.com宛のメールを受け取り放題になる。ここで報告書の「問い合わせメール～」につながる。

別にコインチェックを擁護するわけではないが、この件は事象から原因にたどり着くまでが難しい…

後からはどうとも言えるかもしれないが、オレはこの机上検証を行うことで、「レスポンス遅延」から「レジストラの登録情報改ざん」を突き止めた方々の努力に敬意を表したい。そして、多岐にわたるレスポンス遅延の要因を1つ1つ潰し、レジストラの登録情報改ざんに至るまでの（想定）プロセスが、相当大変だという結論に至ったのは、1つの知見を得たとか考えている。

それこそここまでのことを10秒でトレースできる人がいれば～という話なのかもしれないが、そんな人はそうそういるわけではないし、オレもスタートとゴール（そしてその後）を見るまでは、そんなこと思いもしなかった。

結び～適切な仮説設定と、仮説に基づいた地道な調査が一番重要

ここまでにいろんなことを書いたが、最も重要なのは「適切な仮説設定」と「地道な調査」ということ。仮説設定が間違っていると、調査はあさっての方向に行きがちだし、地道な調査を行わないと、積み重ねる事実が瓦解しかねない。

自分も気をつけないとなぁ…と感じた瞬間である。

*1:もしかしたら考えていたかもしれないが、遅延という事象に結びつくか？といわれるとそこは謎。

*2:実はTCPなどでも同じだが

みんなVPN死ね症候群にかかってないか？

極端なテレワーク推奨期間に入ってはや数ヶ月（？）、VPNについて「クラウドベースに移行するのを視野に入れて」とかなんとかいろいろと出てるけど、別にVPNが悪いわけじゃないぞ。使うVPNの種類と使い所を間違っているだけだ。

ということで、本日はざっくりとしたVPNの種類と使い所を、自分の記憶と理解の範囲だけで説明してみよう*1。

VPN is 何？～種類の前にまずはここから

VPNとは、「専用線とみなして使うことができる回線であり、「専用線のようなもの」である。」という以上の意味しかない。ちなみに対義語はPN（Private Network）。技術的には、「接続される2点もしくはそれ以上をつなぐ」専用に使われる回線である。しかしVPNは、技術的に専用線のようなものと言えるかもしれないけど、厳密には専用線ではない。それっくらいの意味しかない。

IP-VPN is 何？

IP専用のVPN。網は通信事業者が準備しているものを使う。機密性、完全製、可用性（この場合は利用可能な帯域）は、通信事業者がサービス内容に応じて設定する。結構お高い。

インターネットVPN is 何？

IPsecやSSLなどを用いて、機密性と完全製を担保するタイプのVPN。可用性（帯域）は、通る経路によってだいぶ異なるため、まず保証はされない。ただ、トポロジにもよるが、IP-VPNよりは安価にすむことが多い*2。

テレワークで使われるのは？～当然インターネットVPNだが…

インターネットVPNの場合は、接続されるのはエンドユーザと（例えば）会社であり、そこからさらに「別のサービスを使う」ための接続が走る。

ユーザ - 職場 - サービスサイト、というような構成になる。

サービスサイトは、なんでも適当なものを想定すればよい。例えばどこかのWebサイトでもよいし、Zoomなどのオンライン会議サービスなどでもよい。

インターネットVPNの問題は？～インターネット技術のよさをある意味全く無効化してしまっていること

テレワークで使われるのは、インターネットVPNだが、別にインターネットVPNが悪いわけではない。ユースケースが悪いのだ。

多くの場合、ユーザは手元の端末（コンピュータなど）から職場などに置いてあるコンピュータににVPN経由で接続し、そこからさらに外部のサービスに接続することになると思うのだが、このときに「通信が必ず職場を通る」ことになる。インターネットは、経路制御プロトコルなどの働きにより、できるだけ高速に通信ができる／通信ができやすい経路をユーザが意識しなくても使用することが可能である。

しかし、テレワークの場合、必ず「職場」を通り、そこからサービスに接続することから、「職場」がボトルネックになる。ボトルネックになっても、仕組み上しょうがない状態であり、もはやどうしようもない。

解決法の案～サービスはサービスに、会社の中は会社に、という形でTPOに応じた通信を実現する必要があるが、問題も。

解決法はいたってシンプルで、会社であろうと外部サービスであろうと、最適な経路を使えるようにすることだ。しかし、会社を通らないとガバナンス上（情報管理上）のリスクを抱えることになる。例えば「社員の私物PCに、業務上の機密資料が複製される」などがそのひとつである。

なので、テレワークを行う社員に配布するコンピュータは、そういうことを行えないような仕掛けを施す必要がある。

むすび～テレワーク時の情報管理に留意する必要はあるが、なるべく必要なサービスにはユーザの手元コンピュータから直接利用できるようにしよう

例で情報持ち出しのリスクの話を挙げたが、このあたりは別にテレワーク云々関係なく考えなければ行けない話である。

通信のボトルネックになるのが職場、というケースが多いことを勘案すると、そこは通らないが、情報管理をきっちりとやる、ということを考えるのがよい。

*1:恐ろしいチャレンジだ…

*2:そうでないと困る