Archive for 6月, 2023

マイナンバーカードを保険証としても使えるシステム(以下、「マイナンバーカード保険証」など)が すご過ぎて※げんなりした。僕の常識が ことごとく覆された。一体、どういう お利口さんが考えたのだろうか。江戸時代でも もっとマトモなものが出来そうだが・・・

※「ヤバイ」のように逆の意味

背景

マイナンバーカード保険証のサービスが開始され、紙だと数円高くなるようなので使ってみたのだが、2回(別の医院)使って どちらも顔認証に失敗した。1回目はカードのカバー(透明なやつ)を外さないと認証できず、もう1回はどうしてもできず、紙の保険証を使わされた。

どちらも、カードリーダーには「カードの置き方が悪い」のように出た。

疑念

それで、以下のような疑問が生まれた。

  • なぜカードが読めない??
    • 非接触カードなんだから、普通に置けば読めるはず。
  • なぜカードのカバーを外して挿れる?? (そんなの知らなかった)
    • 上と同様に、カバーなんて関係なく読めるはず。
  • なぜ、挿れる(正確には穴に置く)向き(方向、裏表)がある?? (馬鹿じゃね?)
    • これも上と同様。

想像

少し調べたら、カードリーダーは なぜかカードを光学的に読んでいるようだ。というのは、メーカーのページには、失敗した時に光源の明るさを調整するなどと書いてあったからだ。

は? 何を読んでいるんだろうか?

全く理解不能だけど考えてみたら、カードのチップに記録されたマイナンバーなどの情報は、暗証番号を入れなければ読めないはずなで、チップに顔写真が記録されているにしても、(ただリーダーに挿れただけでは)同様に読めないだろうから、カードに印刷された顔写真で認証しているのではないかと想像した。

でも、少し考えてみると、写真などの、カードに印刷されている情報は保護なしで読めてもいい気がする。まあ、保護したほうが良いのは確かだが。実際、運転免許証にも暗証番号がある(何が読めるかは忘れた)。

推測 (実際には正しくなかった)

カードリーダーは、カード表面に印刷された顔写真と顔を比較して認証してマイナンバーを読み出す。

根拠

  • 認証装置にはカードを読むためのカメラが付いている。
    • 装置のマニュアルやFAQより
      • 例: パナのリーダーXC-STFR1J-MNには券面読み取り用カメラが付いている。 (→ 参照, DLページ(左が駄目な時に))
  • カードはケースを外して、顔のある面を上にして入れることになっている。
    • 実際、外さないと読めなかった。
    • 外しても読めなかったのは、外からの光の影響?
      • 装置のFAQより (→ 参照)

どうしてこんな下らないことをしているか考えたら、保険証は当初は想定していなかった使い方(ユースケース)なのに、無理して実現したからだろうかと思った。

調査と結果

上の どうにも信じられない推測を確かめるために更に調査したら、大分分かって脱力した・・・

一番スパっと来た情報(カードリーダーの仕組みが分かりやすい)は、厚労省の資料「顔認証付きカードリーダーの概要」(c. 2020)だ。その2ページ目の「マイナンバーカード券面スキャン機能」に、以下のようにある。

マイナンバーカード内の顔写真データを取得するため、マイナンバーカードの券面情報を読み取る。

<仕様例> 顔写真データを取得するために必要な券面情報(生年月日、有効期限の西暦、セキュリティコード)のスキャンの認識率99%以上

つまり、以下の処理だろうか。

  1. カードの表面の生年月日などをカメラで読んで文字認識し、
  2. それを元にカードかサーバから本人の顔画像を取得する。※
  3. その画像とカメラで撮影した顔を比較して認証する。

※ここは想像で、生年月日, 有効期限, セキュリティコードから簡易なアクセスキーを生成して、カードかサーバから顔の画像を取得しているのではないか。サーバだと時間が掛かりそうなので、カードだろうか?

高度な画像認識技術を使ってカード表面の文字を読む!!!

えぇ・・・ 普通にカード(チップ)から読めよ。こんなのアナログそのもので、お前らの好きなデジタルじゃない!

海外の人が知ったら絶句するだろうな。台湾の有名な人に作り直して欲しい。

カードに印刷された顔写真と比べて認証するよりはマシかも知れないが※、五十歩百歩だ。* 昔、「まだやってんの?」と常に偉そうな友人に馬鹿にされた、紙の本の「自炊」レベルだ。@

※実際、大企業様による そういう石器時代的なシステムがあった。すごいね、こんなのを使う気になる人は。

*個人的には、印刷された顔写真と比較するほうが まだ使えそうな気がする。というのは、写真には冗長性があるためだ。写真の一部が汚れたり欠けても まず使えるが、文字だと1文字欠けたら分からないじゃないか? 推測したら「他人の―」問題になっちゃいそうだ。

@だけど、自炊は他に手段がないから やっているので仕方ないが、これは最初の設計が悪くて、マトモな やり方ができないから無理くりやっている点で、かなりレベルが低い。

いろいろ突っ込みどころはあるが、少し経験のある人なら分かるが、文字認識なんてカタログどおり100%は成功しないので、こんな やり方では失敗が多発することは やる前から分かるから、進んで こんな作りにする人は居ない。

はずだったが、国の上のほうには居たようだ。

更に、そもそも、使うところは医療機関だから、簡単に確実に迅速に使えることが必須で、こんなシステムは机上の空論でしかない。素人でも考えないレベルだ。今後使う人が増えたら、問題が どんどん出て来るはずだ。

実際、上の仕様例に"99%"と誇らしく書いてあるのが笑える。99%じゃ全然足りない。素人なので分からないが、少なくとも99.99%くらいは要るのではないか? それでも、1億回だと1万回は失敗する。(なお、99%だと100万回)

更に、特定の条件のカードが常に失敗するとすれば(下を参照)、99%では約100万人が使えないことになる。

調べると、少し古い(2022/12まで)ながらも実際の利用数・率があり、約100万件(登録数の1.3%程度)とのことだ。すると、認識率が99%であれば失敗するのは約1万件となる。実際の失敗(苦情)の数は分からないが、問題になりつつあることを見ると、数千件 はあるのではないか。

まだ利用率が少ないから 持っているものの、10%とか20%とかになった場合はどうなることやら・・・

 

考察・意見

そういうことなら、2回目に僕が失敗した理由も分かる。おそらく、リーダー周囲の光(外からの光が入っていた※)の影響か、カード自体の印刷の劣化(かすれなど)ではないか。

※次回、もしやる気が出たら、なるべく身体(顔)をリーダーに近づけて、外光の影響を減らしてみたい。が暗証番号でいい。やる気なんて出る訳ない!

常識的に考えれば、ICカード(非接触対応)の表面は人が見るだけなので、多少傷付いたり汚れても問題ないはずだ。実際、最初は「大切に保管しろ」とは言われていたものの、表面を傷付けるなということは言われておらず、今は「(いろいろなところで使えるのだから、どんどん)持参しろ」とすら言っているのに、表面を光学的に読むのは余りにもおかしい。

カードを見ると印刷は弱い感じで、強く擦ったら消えそうな感じだ。僕の場合、電子証明書の期限の更新で書き換えられた(消しゴムなどで擦って消した?)ために、生年月日辺りに かすれや歪みが出ていそうだし、住所変更もしたので 下の方に手書きの文字が書いてあるのも、文字認識の妨げに なりそうな気がする。

ひどいのは、こういうシビアなことが全く知らされておらず、単に「カードに記録された顔画像で認証する」(→ ※)と言われていることだ。

※この記事にしたって随分大雑把だ。技術サイトの癖に、(上にも書いたように、)その顔画像をどうやってカードから取り出すのか考えていない。単に言われたことを書いてるだけ?

僕が知る限り、上述の仕組みや そこから起こる問題は世間では知られて居ない。: 例えば、カードの表面を傷つけたり、ペンなどで書いたり色を塗ったりした人、シール類を貼った人は確実にアウトになりそうだ。あと、差し込み式リーダーで繰り返し使った人や、非接触でもスマフォの背面に何度も接触させるうちに表面の劣化がひどくなって、駄目になるのではないか。

もしかして、問題が炎上してから、大臣辺りが「表面保護のためにカバーを用意した。(だから、丁寧に扱わなかった国民が悪い)」とか言い出すだろうか?: 当たったらおもしろいけど、ものすごくムカつく。

しかも、更に怖いのは、顔認証でも連続10回失敗するとカードが無効になるらしいことだ。メーカーのFAQには以下のようにある。

※なお外部認証に連続10回失敗したエラーが出ると顔認証がロックされます。

「ロックされる」のがカードなのかリーダーなのか分からないが、いずれにしても怖い・ひどいことは確かで、そもそも顔認証ができにくいなら、暗証番号のほうが便利・安全そうだ。

「だったら意味なくね?」である。

 

嘆き

という訳で、日本は今までの想像以上に馬鹿になったものだと、暗澹たる思いが増した。そして、近頃言われているカードの「改良」は、盛大にお金を使って ものすごいものが出て来る気がしてならない。

「馬鹿は頑張らなくいいから、そこらで寝てていいよ」って言いたい。

 

PS. まあ、現場の人は素人でないので「無理だ」と言ったはずだ。が、何も分かってないノータリン偉い連中が、「それは通らない。(僕が困るから)何とかしろ」とか言ったから仕方なく何とかしたんだろうが、全く詰まらない無駄なことだ。技術と金と開発者のメンタルの浪費だ。

まあ、そういう開発者も砂糖水を売り続けるみたいなもので、同罪だ。遊びじゃないので、それらしいものを作ればいいってものではない!

PS2. それでは、どうすれば良かったか(、あるいは全く無理だったのか)考えると、

顔画像の認証用の情報(特徴のようなもの? あるいは画像そのもの)は、カードからパスワードなしで読める。

であれば良かったのではないか。が、最初にそんな考え(ユースケースの想定、設計)がなかったので無理なのか。

だったら、(本文に書いたように)カード表面の顔写真でのアナログ認証が良かったと思う。

でも、そもそも、カードリーダーは「顔で認証できた」という情報をカードに与えて情報を取得するはずなので(カードに顔画像データでの認証機能があるとは思えない)、認証しなくても中身が読めるようにできる気がする。だから、

  1. 認証なしで(認証が通ったとして)カード内の顔画像を取る。
  2. 顔と比較して認証する。
  3. 認証できたら、カードから本来必要な情報を取得する。

でいいのではないか?

きっと、頭の悪い硬い連中が「駄目だ」とか言って却下されたのだろう。

PS3. もっと怖いことは、僕が書いたのは単にカードで顔認証するだけの話で、それ以外に、ニュースになっているように、いろいろな問題が山ほどあることだ。顔認証と同様に、「そもそも無理だけど、それらしくでっち上げて しばらく(異動になるまで?)動けば良い」スタンスでやっている気がしてならない。

 

書いたあとで分かったこと

(7/1 10:24) 上を公開後に更に調べて分かったことを書く。もし本文と異なる内容があっても、本文を変更・修正しない(初出の本文を保存するため)。

  • カード内の顔画像へのアクセス: 「券面AP」というもので取得する。: 暗証番号(4桁)でなく、「照合番号B」というもの(14桁: 生年月日: 6, 有効期限: 4, セキュリティコード: 4)で取得可能。 (→ 参照)
    • 照合番号Bを得るために、カードをカメラで読んで文字認識しているのだろう。
    • 顔認証できたあと、医療情報(サーバ?)へのアクセスをどうしているかは不明だが、顔認証(券面AP+「券面事項入力補助AP」)と暗証番号(券面事項入力補助AP)のどちらでも取得できる、住所, 氏名, 生年月日, 性別(「4情報」と呼ばれている)と その電子署名データをキーにしているのではないか(下の「券面AP以外のアクセスについて」を参照)。
      • 4情報では他人との重複が避けられないが、電子署名データも合わせることで防いでいるのだろうか(ハッシュのような感じ?)。
      • カードを入手すれば医療情報にアクセスするキーを得られてしまうが、実際にアクセスするにはサーバに接続しなければならないから、医療機関がハッキングされなければ大丈夫だろう・・・
      • 券面AP以外のアクセスについて
        • 「JPKI-AP」, 「住基AP」: 暗証番号(4桁または6-16桁)が必要
        • 券面事項入力補助AP: 種類によって暗証番号(4桁), 「照合番号A」(マイナンバー), 照合番号Bが必要
          • 照合番号Bでアクセスできるのは、4情報と その電子署名データ
          • また、暗証番号(4桁)では、マイナンバー, 4情報と その電子署名データ(マイナンバーを含む署名かは不明)
  • カード表面の文字の印刷: レーザーで刻印してあるとのことで、通常の使用で消滅することはなさそうだ。 (→ 参照)
    • ただ、色が抜けて見えなくなる可能性はありそうだし、あのフォントは細くて文字認識に向いていないように思う。
  • (参考) カードとの通信: APDUコマンドというもので行うとのこと。 (→ 参照)

書かなくてもいいことだが、資料を見て、随分複雑な仕組みだと思った。セキュリティの仕組みは複雑なのは仕方ないが、独特な用語やAPなるものが4種類もあることが拍車を掛けている。後者は本当に必要なのだろうか?

あと、「カードの空き領域を活用」とあるが、具体的に空き領域が どのくらいあるか明記されていないので、いざ使おうとしたら足りなくて駄目になる可能性があり、その場合どうするのか疑問だ(セキュリティでどうしても必要だから入れる訳で、基本的に入れない選択肢はない)。使って欲しいと言う割には見通しが甘い感じがする。

 

(7/1 13:28 「書いたあとで分かったこと」はPSのあとに書いたためPSと整合せず混乱するため、最後に移動した。内容は何も変えていない。)

  •  0
  •  0
Keys: , , , , , ,

先日から「ちょっと試す」程度のつもりだったCloudflare(以下、CF)のプロキシなど(正式な名前は 調べたが忘れた)。噛めば噛むほど味が出て食べ応えがあるため^^、ちょっとのつもりが本腰を入れてしまい、近頃では珍しく 楽しく使って居る。(とは言え、分からないことが多いので苦労はある。)

昔のGogleも似たような感じだった印象があるが、飽きっぽくて(作っては捨て)信用できないうえに、いつからか悪魔になってしまった・・・

そして、無料版で制限はあるものの充分使えるので、このまま(「駄目」になるまで)使い続けようと思っており、今までに試した概要や感想を書く。

 

ネットワークの接続構成

以下のように、CFがプロキシとしてブラウザとサーバの間に入る。

Cloudflareを使う際のNW接続構成: クライアント(ブラウザ) ―(HTTPS)― CF(プロキシ) ―(HTTPS)― サーバ

そのため、ホスト名(blog.piulento.netなど)でアクセスすると、実際のサーバでなくCFに繋がる(IPアドレスを検索してwhoisすると分かる)。

参考までに実行例(適宜省略。OrganizationがCloudflare):

$ host blog.piulento.net

blog.piulento.net has address 104.21.50.89
blog.piulento.net has IPv6 address 2606:4700:3035::ac43:9fa1

$ whois 104.21.50.89

# Copyright 1997-2023, American Registry for Internet Numbers, Ltd.

NetRange: 104.16.0.0 - 104.31.255.255
NetName: CLOUDFLARENET
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)

なお、「プロキシ」とは書いているが、中継サーバ的なもので、SSL証明書も入れ換えている(ブラウザで見ると分かる。: 「本物」はLet's Encryptだが、違うもの(Google)になっている)。

使って居る機能・用例

最初はそんなに凝るつもりはなかったが、管理ページを見て試しているうちに、以下のように結構多くなった。他にも使いたいが、興味とか趣味の領域だ(まあ、そもそも趣味だがw)。

  • ドメイン管理(DNS)
    • 権威サーバ
  • プロキシ
  • リダイレクト
    • ポートスキャンの拒否
    • 不正ログインの拒否
    • 悪質なボットの拒否
    • サービスの転送
  • サーバの保護※ (どれも詳細は不明)
    • セキュリティレベル: 高
      • 何らかの条件で悪質なアクセスを拒否するようだ。
        • ただ、それほど厳しくない。悪いアクセスが通過することは多い。
    • ボットからの保護?: Bot Fight Mode
      • 「悪いボット」を拒否しているようだが、条件は不明。
        • 上と同様に、もっと悪いボットが通過することは多い。
    • DDoSからの保護
    • ブラウザの整合性チェック
  • WAF (Web application firewall): 無料版なので機能は少ない。
    • チャレンジ(いわゆる「キャプチャ」(CAPTCHA))
      • どうやって人間か判断しているかは不明。
      • ボットからのアクセス(非インタラクティブ(自動)アクセス)を ほぼ遮断できる。
        • 人間からのアクセス(挑戦)を防ぐのは無理だが、ブルートフォース攻撃は難しいだろう。
        • おそらく、人間が挑戦すべき対象をボットで見付けているのではないか。
      • キャプチャの例
      • ブログのログインページやコメント投稿時などに出すようにしたら、かなり安心できる感じだ。
        • (今のところ)スパムコメントを根絶できて居る。
        • 当初はCFのAPIを使って、自分でログインページなどにキャプチャを出そうと思って居たが、WAFの設定だけでできた。
      • また、非インタラクティブアクセス(例: アプリ, ボット)を許可するURLのホワイトリストを作り、許可しないものにはチャレンジを出すようにした。
        • Managedというチャレンジは、基本的には人がアクセスした場合は待つだけで良いので利便性は損なわれない。
          • どうやって判断しているかは不明
        • 無料版のWAFが弱いので、自分でルールを作って強化した。
    •  「引っ掛かった馬鹿」はイベントログで確認できる。
      • ただ、多いと確認が大変なので、明らかな不正アクセスはリダイレクトでブロックすることにして、チャレンジは減らした。
  • スピードの最適化
    • クライアントへのHTTP/2, HTTP/3
      • HTTP/3はHTTP/2よりは良さそうなので、サーバも対応させたい。
      • なお、サーバへのHTTP/2は、以前試したときに効果がなかったのでoffにしている。
    • Brotli圧縮: 詳細不明
    • Early Hints: 詳細不明
    • Rocket Loader: JSの高速化。詳細不明
      • Nextcloudの管理ページでは無効にしないと正しく表示できなかったので、そういうルールを設定した。
    • Auto Minify: HTML, CSS, JSのサイズの縮小。本当に効いているか不明。
    • 常時HTTPS (勝手にHTTP→HTTPS)
      • WPのHTTPSにリダイレクトするプラグインが不要になる(が、CFを使わない場合に備えて入れておく必要がある)。
  • キャッシュ
    • ヒット率を向上させるためにルールを設定してみたが、余り意味がなさそう(CFのデフォルト設定で充分良さそう)。
      • キャッシュできない情報は そういう指定がHTTPヘッダに書かれており、無理にキャッシュしてはいけない(意味がない)。
      • キャッシュ可能なものは、上と同様に、CFがヘッダで判断して自動的にキャッシュするはず。
  • IP Geolocation
    • サーバへの要求HTTPヘッダにクライアントの位置情報(国、県、市など)が入れられるので便利
      • サーバや自分で検索すると重いし面倒なので、手軽で良い。
        • 同様に、CFのイベントログにIPアドレスから検索された主なwhois情報が載っているのも、自分で検索しなくて済むので助かる。
      • 参考までに、国と県をログに記録している。
        • 例(一部伏せた。先頭のアドレスはCFのもので実際の位置とは関係なく、最後のほうの2409::xxxxがクライアントのアドレス):

162.158.118.114 - - [28/Jun/2023:21:02:02 +0900] "GET / HTTP/1.1" 200 44340 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36" "JP/Tochigi" "2409::xxxx" https:blog.piulento.net:443

  • Scrape Shield
    • Email Address Obfuscation: 効いているのか不明
    • Server-side Excludes: 自分でページを対応させないと無意味
  • アクセス解析
    • 出すページによって集計条件が違うようだが、それなりに分かる(傾向が分かれば良いので、それで良い)。
      • アクセス(訪問者)数は(以前調べた時と同様に)100件/日程度。
      • ページアクセス速度(所要時間)が分かるのが便利
        • 描画完了までの時間のせいか、結構遅い。: 約1.5秒前後
          • 時間は分かっても、なかなか高速化できない。
          • たまに、すごく遅い場合がある(以前からあった)のが謎。
    • 「有料」と書かれているものと同等な(と思われる)機能が別のページにあって無料で使えている??
      • 違うにしても、僕にはそれで充分
    • WPの(無料)プラグインには まともなものがなかったので、随分有用だ。
    • アクセス解析の例

※サーバの保護について

安全性を向上させるため、上記の他に、HTTPとHTTPSはCFからの接続だけを許可するようにした。*: DNSの設定でサーバの公式な名前(例: blog.piulento.net)に対応するIPアドレスをCFのプロキシのものにし、サーバのHTTP/HTTPSのポートへの接続をCFからだけ許可した。

*当初はCFとのトンネリング("Zero Trust": 大変難解)を使う必要があると思って居たが、とりあえず不要になった。

なお、SSHは(CFの無料版ではサポートされていないため、)サーバに直接接続する必要があるが、そのためのDNSレコードを用意した。そのため、SSHについては、従来どおり、サーバのパケットフィルタの機能(iptables)で防御している。

良い点

  • サーバと自分の負荷軽減・手間の削減にすごく良い。
    • クソなアクセス(不正アクセスや攻撃の試行やクソなボット)にサーバで対応しなくて良い。
      • 自分の設定漏れ・ミスを心配しなくて良い。あるいは、自分のセキュリティ設定が補強される。
    • セキュリティ関連の設定を変更する場合、CFだけで済む(サーバを変更しなくて良い)ため、手間と間違う可能性が減るのが助かる。
      • ただ、CFを止めた時のため、同様の設定をサーバにもすべきである。
  • CFがフィルタリングするのかCFを敬遠するのか、ひどい不正アクセスが減った(なくなった訳ではない)。
    • おかしな(例: 中身の不明なバイナリデータでHTTP 400になるもの)HTTP要求がCFのプロキシで破棄されて全く来なくなるのも良い。
  • キャッシュの効きは まあまあ?
    • ヒット率は10%程度
    • WPは動的にページを生成しているためにキャッシュできず、表示時間は短縮できなさそうだ。
      • 古いページを固定するような機能があると良さそう。でも、古いページの内容が表示時の条件によって変わる可能性があるので、難しそうだ。
        • CSSは良いとして、例えばWPのショートコードは問題だ。
    • ただ、何となく表示が軽くなった気はする。
  • ドキュメントを丹念に調べると、いろいろな機能が使える。
  • Backblaze B2(クラウドストレージ)と接続した場合、B2の通信料(egress)が掛からないので、何かに使えそう。

欠点

  • 機能・設定箇所が分散していて分かりにくい。場所ごとに、同様のことでも出来ることと出来ないことが違う場合がある。
    • 設定方法がドキュメントにも書いてないことがある。 ← 更に検索(Google)したりAPIなどのドキュメントを見ると分かることがある。
      • 参照先を書き切れていない感じ。
    • 資料に書いてないことが出来る場合と出来ない場合がある。
      • 書いてないことは出来なくて良いのだが、他の機能で出来ていることが出来なくて惜しいので試してみる。
  • 結構 未完成な管理ページ(例: 表示が残念)がある。
    • でも、ちゃんと使えるので許せる。
  • 有料でしか使えない機能がある。
    • WAFなどの条件に正規表現が使えないのが痛い・・・
    • WAFなどで使えるルール数も少ない。: 3個とか10個とか。
      • ただ、それぞれのルールに多くの条件が書けるので、今は問題ない。
  • 自分の使って居るサービスのすべての設定をまとめてダウンロードして保存(バックアップ)する機能がない。(フォーラムにも文句が書かれている)
    • 同様に、「自分が使って居る機能は何か」が一目で分からない。
      • 他社の"Overview"に相当するものがない。Overviewのページはあるが、違う。
  • (プロキシなので仕方ないが、)サーバのアクセスログのアクセス元アドレス(通常は行の先頭)にはCFのアドレスが書かれるので、誤解しやすい。また、集計処理するプログラムの対応が要る。
    • クライアントの本当のアドレスはヘッダのX-Forwarded-Forの値(通常は行の最後のほう)として書かれるので、忘れずにそこを見れば良いのだが、習慣のために良く誤解する。

その他

  • CFの動作など
    • 動作確認でポートスキャンをしたら、HTTP/HTTPSの待ち受けポートは80, 443だけでなく他に いくつか使えることが分かり、ブログ以外の機能に使って居る。
    • CFのプロキシのIPアドレスの位置はUSと出るが、拠点は国内にあるようで、pingの応答は速い。: 僕のPCからだとサーバに直接するのの1/2くらい(30ms→15ms)になる。
      • ただし、サーバ(北海道)からCFの拠点は遠いようで、サーバからCFまでは約20msとなり、キャッシュされていない場合には速くならなそうだ。
    • CFのイベントログで分かったが、ブログ検索(サイドバーの下の方)への攻撃の手始めらしきもの※もある。以前から気になって居たが、なかなか確認出来ずに居た。これからはチャレンジ(キャプチャ)で保護できそうだ。
      • ※ボット(しかも海外)が検索することは余り考えられない。
    • 上述の、ページ表示時間がものすごく長い場合(10秒前後)は、キャプチャが出て(タイムアウトして)いる時かも知れない。
  • CFへの懸念など
    • そのうち無料プランの機能が制限されたりすると、困る。年間3000円くらいなら出してもいいが、今の有料プランはUSD 20/月くらいからと、なかなか高い。
      • サーバの機能もあるのだが、今のVPSのようには使えなさそうなので、完全に移行するのは無理だ。
    • CFに関する心配としては、サーバへのアクセスを全部CF経由にしているため、もしCFが落ちたら何もできなくなってしまうことだ。
      • それを想定して、いつでも容易にCFなしに戻せるようにしている(つもり: やってみないと分からない)。
      • それに、GoogleやAWSなどと違い、今までCFが落ちてトラブルになったという話を聞いたことがないので、信頼性は高そうだ。
        • 単に僕が知らないだけとか大口ユーザの影に隠れている可能性はある。
    • 気になるけど気にしないことは、CFで中継する時にSSL/TLSの暗号化が解除されるので、そこから情報が漏洩・改ざん される可能性があることだ。
      • まあ、そういうことがあれば、まず僕より大口のユーザで問題になって大騒ぎになる(なって居た)だろうが、そういう話は聞いたことがないので、とりあえずは気にしない。
      • でも、たまにショップサイトなどである「他人の会員情報が見えてしまう」トラブルはCDN(キャッシュ)が原因という話もあるので、全く安全という訳ではなさそうだ。
      • そういうことも想定して、Nextcloudのデータはend-to-endで暗号化している。
        • でも、いろいろ抜けはあるんだろう・・・
  • CFに(余り)関係なさそうなこと
    • なぜか、CFのプロキシを使うようになってから、デスクトップのNextclouldアプリが1日に1回程度落ちるようになった。PCのIPv6の一時アドレスが更新される時かと想像しているが、(← ログを調べたら、起こるタイミングがズレていたので違う) 以前は起こらなかったので不思議だ。
      • ログにエラーは出ず原因が分からないので、落ちたら再起動するスクリプトを作った。
      • (6/30 7:55) PCのログ(syslog)を調べたら、落ちるのは1日1回より多く、落ちる時にlibglibがtrap int3というエラーを出していることが分かった。
        • 調べたら、他のプログラムでも起こるようだが、解決策は なかった。ちょっと気になる。
      • (7/2 15:09) 原因は確定していないが、解決方法は分かった。: Nextclould(以下、NC)アプリの接続先のIPアドレスを固定すれば良い。
        • 推測した原因
          • CFのプロキシを使う場合、DNSに現れるサーバのアドレスは、IPv4, v6それぞれ2個ずつの計4個となる。
          • NCアプリが同期する時に前回とアドレス(特にv4/v6?)が変わると、想定外に なって落ちるのではないか。
            • trap int 3は異常な場合にプログラムが自分を落とす場合に多いとのこと。
          • また、サーバへの接続にプロキシ(下記)を使うと接続数が1/2くらいに減るので、NCアプリはサーバに同時接続していて、それらのアドレスやタイプが異なると落ちるのかも知れない。
        • 検証と結果: sshで仮のSOCKS5プロキシを作り、NCアプリの接続先のアドレスが変わらないようにしたところ、約6時間経過しても落ちなかった。
          • sshをプロキシにするコマンド例(PCのIPアドレスが192.168.0.123の場合)

ssh -N -D 192.168.0.123:8940 localhost

          • NCアプリのプロキシ設定: SOCKS5, 192.168.0.123:8940
          • 接続概要: NCアプリ → 192.168.0.123:8940 [ssh] → [CF] → [サーバ]
        • ただ、実際には、NCアプリだけのためにプロキシを動かすのは煩雑(もったいない)だし、他の方法(例: プライベートなDNSサーバ, NW namespace, LD_PRELOAD, firejail)も同様に手軽でないので、現状のまま 落ちたら再起動することにした。
      • なお、NCのフォーラムで聞こうと思って探したが それらしいものは見付からず、NCアプリからドキュメントを開いたら「ファイルなし」になったため、サポートは期待できないと考えて止めた。
      • (7/2 15:52) その後、もしやと思ってNCのサイトで最新版アプリを探したらV3.9と、今まで使っていた2.6(Ubuntuのリポジトリにないので、どこからインストールしたか不明・・・※)より随分違うので、それを試している。
        • ※今までのアプリはNCのサイトからダウンロードしたのだろうが、更新チェック機能がなかったので、ずっと古いままだったようだ。 ← 良く調べたらUbuntuのリポジトリからインストールしたものだった。 (7/3 4:40)
      • (7/3 4:40) 最新版アプリを使って居る時は、通常時の(PC全体での)接続数が かなり少ないことが分かった(10個前後 → 4個)。ということは、古いアプリは使い終わった接続を切断せずに残すなどするため、時間が経つとテーブルがフルになって(想定外で)落ちるのかも知れない。
        • (CFを使う前には起こらず)CF経由にして発現したのは、CFが接続を切断せずに残すからだろうか。
    • 同様に、Seamonkeyもスケジュールのアカウント作成が できなくなってしまったが、最新版(同じ頃に更新した)に問題があるようで、以前の版に戻したら直った。
      • まだ直っていないのを見ると、使う人が少ないのか。あと、新しくアカウントを登録するのが失敗するようなので発覚していないのかも知れない。
      • Thunderbirdなら大丈夫だったが、以前気に入らなかった点がまだ直っていないので、使わないことにした。
    • もう一つ、ログを見て居て気付いたのは、1日に1回、サーバ内から自分に変なアクセス(HTTP 400: 要求文字列などが空)があることだ。
      • 一見ウイルスのように思えるが、調べたらサーバのSSL証明書の自動更新に使って居るプログラムgetsslが、更新チェックする時にopenssl s_clientコマンドでサーバの証明書を取得しており、それが異常なアクセスをしていることが分かった。
        • 綺麗でないが、opensslコマンドをHTTPに対応させるのは本質的でないので、それでいいのだろうと理解した。
        • opensslにもgetsslにも そこらに関する設定がないので、放置することにした。

 

現在の結論

なかなか良いし、いじるのが おもしろいが、以前も書いたようにCF(CFだけでなく、特定企業・団体に固有のサービス)に依存するのは良くないので、ほどほどにする必要がありそうだ。例えば、ここが使えなくなっても容易に他に移れるように、一般的な概念で進めて「どういう機能を どう使ったか」を記録しておけば良さそうだ。そして、CF特有の機能は余り追うべきではない(おもしろいけど)。

 

(-6/29 15:09 修正、加筆; 6/30 7:55 Nextcloudアプリが落ちる件に追記, 8:04 「その他」の構成を改良)

  •  1
  •  0
Keys: , , , , ,

確証は ないのだが、結構前から、USBケーブルのCコネクタ(プラグまたはジャック)はmicro Bなどに比べて弱いように思う。というのは、今までに何度か接触不良が起こっているからだ。

一つはオーディオインタフェース(Scarlett Solo Gen 3)、もう一つはスマフォ(AQUOS sense lite)である。

前者は明らかに差し込みが緩くなって上下にグラついて居た(それで時々接続が切れる)ので、プラグの金属部に薄いテープ(ポリエステル)を貼って差し込みをキツくした。

後者は差し込みは問題なさそうだが、時々 ものすごく充電が遅くなる(数時間経っても終わらない)。近頃、どうしたのかと画面を見たら「低速充電中」とか出て居たので気付いた。

まずは「素直に」ケーブルを買い換えるのがいいのだろうが、本当にケーブルが悪いのか確かめたくて、手持ちのケーブルで試すことにした。ただ、同じもの(A-C, 約1m)は ないので、延長コード(A-A(ジャック))と短いA-Cケーブルを組み合わせて試している。

短いA-Cケーブルだけで届けば良いが無理なので、延長コードを使った。

今のところ問題はない(「低速充電」にはならない)。

ただ、低速充電とは出ないものの充電が遅いような気がする。それは、時計の秒針の動きを追っていると停まって見えることがあるのと同様に、気にするから長く感じるのだろうか?

 

Cコネクタが弱い理由を考えてみると、形状が悪いように思う。特に、裏表がないようにしたためか※、中の端子部の接触が弱くなってしまうのではないか。

※どういう仕組みかは知らないが、裏表は ないものの、差し込んだ時にジャック側の端子に接触するのは片面(例: 上)だけなのではないか。そうすると、プラグ(ケーブル)側の端子が接触しない側に動く(ジャック側の端子から離れる)可能性があって、それで接触不良になりそうだ。

↑AQUOSのCジャックを見たら、中央に板状のベースがあり、その両面に端子があるようだ。一方、プラグには両面に端子があるので、プラグが上下に動いても大丈夫そうだが、動く時点で弱いのだろう。

ジャックを穴のようにして穴の上下に端子を付けるべきだが、難しいのだろうか。それがLightningなのか。

Lightningとの比較という点では、まとめサイトに、Cは本体側(ジャック)が弱くて壊れやすい(上記の板が折れるのだろう)ので(クソ!で)、Lightningのようにすべきだったという意見を見たことがある。

あと、外側の金属部にはmicro B(やmini BやB)のような角がないため、固定が甘くて動きやすく、それでグラついて接触不良が起こるのではないかと思う。

コネクタは小さいので、ケーブルが長くて硬いとテコの原理で動きやすそうだ。

もし上が正しければ、何とも しょうもないものを作ったものだと思う。でも、それほど文句を聞かないのを見ると、僕のケーブルが今一つなものだった可能性がある。

ただ、今まで(Cでないもので)は、どんなにテキトー(に見える)なケーブルでも こんなことはなかった。

 

そしてスマフォのケーブルの交換の話に戻るが、同じような(強くない= 高くない)A-Cケーブルを買ったら またCプラグが駄目になる気がするので、今の暫定ケーブルと同様に、A-micro Bのケーブルとmicro B-Cのアダプタ(100円ショップで買う)でA-Cケーブルにし、アダプタのCプラグが駄目になったらアダプタだけを交換するのがいいかと思っている。

高くて強い(という)ケーブルを買っても、本当に強いかは分からないし、そもそも充電にしか使わないので もったいない。

ただ、接触部が増える点で弱いので、必ずしも最良とは言えない(見た目も良くない)。それれもあって、もう少し暫定ケーブルを試したい。もし これでも駄目なら、本体(コネクタや電池)が悪いことがわかる。

まあ、暫定ケーブルで問題なければ(少し長いのだけが嫌だ)、そのまま使うのが一番良いのかも知れない。

(7/12 9:07) ちょっと期待していたが、残念ながら暫定ケーブルでも低速充電になってしまった。

更に、画面を見ようと本体を持ち上げたら、ケーブルが自重で抜けてしまった。また、コネクタが左右に(上下も少し)グラついて緩い感じだ。

試しに、AQUOSにCプラグのSDカードリーダーを挿してみたら、左右のグラつきは同様だが、挿さる・抜く力が少し大きそうだった。最後に強く(堅く)なるが、ケーブルはそれが少し弱い感じだ。とは言え、何度も・長時間試していないので、カードリーダーのコネクタが安定かは分からない。

  • 考えられる原因
    • ○? 短いA-Cケーブルのコネクタ(Cプラグ)が悪い。
      • 元の駄目になったケーブルと同じメーカーのもの。
      • 挿抜力が弱目。
    • △? AQUOSのコネクタ(Cジャック)が悪い・劣化した。
      • 挿抜力が弱目。
      • 長く使って居る。
    • ○? AQUOSとケーブルの相性が悪い。
      • 挿抜力が弱目。
    • △ AQUOSの電池が寿命になった。
      • 電池の減りが早いことは余りない。
  • 対処案
    • ? 新しいケーブルや変換コネクタ(例: micro B-C)を買う。: 大丈夫な保証はない。挿して確かめればいいが、できる場合は ほとんどない。
    • ? コネクタ(Cプラグ)に加工? (例: 上に書いたように、コネクタに薄いテープを貼る): 効果は不明。本体のコネクタを壊す可能性もある。

全然いい案がないので、考える(保留する)しかない・・・

  •  1
  •  0
Keys: , ,

数日前に、僕が このブログのドメイン(piulento.net)の管理(ドメインの登録やDNSサーバ: 正式には「レジストラ」と言うのか)に使って居るGoogle domains(以下、Google)が終了するという記事を見た。年末辺りから、聞いたこともない別の会社(Squarespace)に自動的に移るそうだ。

最初は、Squarespaceに移管された後、価格や使い勝手を見て考えようと思って居た※が、頭に来るのと7/6がドメインの更新日でGoogleに支払いになるが、下記のようにCloudflare(以下、CF)なら(少し)安くなるので、間に合うなら移って無駄な出費と個人情報の流出とイライラを減らそうと考え、うまい具合に成功した。

※そもそも、(Googleを信用していないため、)Googleのサービスに依存していないので、どこに移行することになっても大きな問題はないから、遅かれ早かれ移行することは確実だった。

 

レジストラの移管作業

移転(移管)作業は難しくはないが、(僕が詳しくない)いろいろな要素が絡み合うため、とても面倒かつ神経を遣った。※ 携帯電話のMNPに似ているが、サクッとは行かない。全部手作業だ。以下、その流れを簡単に書く。

※想像だが、GoogleもCFも(英語版でなく)日本語版ページを見て作業するとしたら10倍くらい分かりにくい気がする。

全く関係ないが、たまたま見たGoDaddyの日本語のページは ひどくて、検討する気を失わせた・・・

  1. 行き先の検討 → Cloudflareにした。
    • 検索すると価格比較ページが結構あるが、やっぱり広告記事のようで、最安と思われるCF(下を参照)については まず書いてなかった。
      • そのため、Googleに移った時は検討すらしなかった。
      • CFも検索で見付けたのだが、どういう検索だったかは覚えていない。「最安」とかで出て来たページに書いてあったのか、比較ページに書いてあったのか。
    • CFは自社での手数料を取らず原価でドメイン管理サービスを提供しているので、最安だと思われる。
      • 料金の比較 (.netドメインの更新料, 年額): 為替によるが、CFはGoogleより少し安そうだ。
        • Cloudflare: USD 9.95 (→ 約1500円)
          • 注: 上は以前の価格で、今はUSD 10.1になっている。また、上のレートは実際と異なる。 (詳細は後述)
        • Google domains: 1400円+消費税 → 1540円
    • CFの落とし穴を調べたが、特になさそうだった。
      • 検討時に参照したページ: 1, 2, 3
      • ※実際には、後述のように、通常の「プライバシー保護」と違って登録者の県と国が公開されるという、思い込みとの違いがあった。
  2. Cloudflareの試用 → 分かりにくい・面倒なことはあるものの、悪くなさそうだった。
    1. アカウントの作成
    2. 「サイト」の登録
      • CFはドメイン管理だけをすることはできず、そのドメインで使うサイトを登録する必要がある。
        • ここがCFの面倒・分かりにくいところだと感じた。
      • 下のDNSの移行を完了しないと、サイトは有効にならない。
    3. DNS(ドメイン情報の大本のサーバ(権威DNSサーバ?, SOAやNSレコードに書かれるもの))を移行してみた。
      • この作業をしないと、ドメインがCFに移管可能にならない。
        • 作業後、CFでドメインが移管可能と表示されるようになった。
      • GoogleとCFの設定を同時に変更するので、面倒なうえに神経を遣った。
        • 失敗するとサイト(piulento.net)にアクセスできなくなる可能性があるため。
      • CFにDNSを設定開始すると、ほとんどの情報がGoogleからコピーされるが、されないものもあるので、チェックして手で追加する必要がある。
        • また、CFには不要な情報(_domainconnectレコード)もあるので、取捨選択する。
        • あと、CFではSOAとNSレコードは変更できないようだ(必ずCFのDNSが権威サーバになる)。
          • → CFのDNSの設定を確定後、GoogleのDNSのSOAとNSレコードをCFに変更する
            • これを変更するまでは、大本(Google)のDNSとCF(1.1.1.1)が異なる状態なのだろうかと推測した。
      • また、DNSの移行前に移行元(Google)のDNSSECを解除する必要がある。
        • 普通に解除を要求しても反映されるのは約24時間後だが、"Unsign zone now"(→ )の操作をしたら即座に反映された。
          • DNSSECの設定時も24時間掛かるが、"publish"すると即座に反映される。
          • その代わり、一時的にサイトにアクセスできなくなる可能性があるようだ。
        • DNSをCFに移行後、改めてGoogleでDNSSECを有効にする必要がある。
      • CFの設定で重要なのは、proxyという機能(一般的なプロキシと同じかは不明)で、onにするとサイトへのアクセスがCFを経由するようになる。
      • この作業で便利だったのはdigコマンドで、例えば dig @1.1.1.1 piulento.net +trace を実行すると、通常では出ないSOAやNSレコードも出る。
  1. Cloudflareへの移転 → 無事に終わった。
    1. ドメインの状態が移管可能(移管できない状態でないこと)か確認した。 → OKだった。
      • ドメインの状態はwhoisコマンドで分かる。: "Domain Status"で出る。
        • 通常は"clientTransferProhibited"(いわゆるロックされた状態)で、ロックを解除すれば移管可能なようだ。
        • 移管できないのは、例えば、レジストラントの連絡先の変更後(60日間不可)、更新日まで15日以下という場合である。
          • たまたま、少し前にドメインの連絡先を変更した(Squarespaceへの移管に備えた)ので移管できないかも知れないと思っていたが、大丈夫だった。ドメインのプライバシー設定をしているため、Google内だけの変更だったからだろうか。
          • 更新期限は偶然・ギリギリ間に合った。
    2. DNSSECを解除した。
      • DNSの移行後に有効にして居たが、CFの資料に従い、再度解除した。
        • 具体的には、(上で設定した)GoogleのDNSSECの設定を削除した。
    3. Googleでドメインロックを解除し、移管の認証コードを取得した。
      • なお、CFのドキュメントではドメインのプライバシー設定を解除する必要があるかも知れないとのことだったが(僕も、解除するのが普通と思って居た)、解除せずに試したら大丈夫だった。
        • その代わり、ドメインの連絡先はCFで改めて設定した。
    4. CFに支払い情報を登録した。
    5. CFで(CFに)ドメインが移管可能になるまで待ち、移管を開始し、認証コードを入力した。
      • 上のDNSSECの解除と支払い情報の登録を忘れて居たためか、移管可能になるまで少し(30分くらい?)時間が掛かった。
      • 移管のためか、料金が想定と若干異なり、ドメイン更新料と合わせてUSD 10.1 (1468円)だった。
        • 今は(移管でない)更新も同じ値段で、なぜか案内ページの料金表の画像(altが"Cloudflare Registrar Pricing")が表示できないので、近頃どこかが値上げしたのかも知れない。
          • ↑検討時に見た(USD 9.95)のは古い情報(2018)だったようで、今回の請求と比べると、卸値?(wholesale cost)がUSD 9.77から9.92に値上がりしている。
          • また、今年更新された参照ページでもUSD 9.95なので、わずかにタイミングが遅かったのかも知れない。まあ、1年だけの違いだ。
    6. CFにドメインの連絡先を設定した。
      • 上記のように、移管前にプライバシー設定を解除しなかったため。
        • 手間ではあるが、一時的にでもプライバシー情報が全世界に公開されるのが防げるので、これが良い。
    7. Googleから移管を受理するかの確認メールが来たので、受理した。
    8. CFから移管完了のメールが来た。
    9. CFでDNSSECを有効にした。
      • 意外にCFのドキュメントに説明がないので、忘れそうだ。
    10. Googleの支払いを止めた。
      • Google側のドメイン情報を「削除」していいのか不明だったが、移管後少ししたら自動的に削除されていた。
    11. PCやモバイルからサイトへのアクセスを確認し、問題なかった。
      • SPF(メールに関係)もチェックしたが、問題なかった。

作業のメモ・感想

  • CFの試行とCFへの移管作業は4時間くらい(概ね半日)で終わった(意外に短かった)。
  • CFがDomain Connect(_domainconnectレコード)に対応していれば、作業が もう少し楽だったのかも知れないが、詳しくないので、移管時に使えるのかは分からない。
  • 以前の会社(お名前.com)からGoogleに移管した時は一時的にプライバシー設定を解除する必要があったが、今回は不要だったので随分安心だった。
  • whoisを見ると、CFはプライバシー設定で隠している個人情報を"DATA REDACTED"と書いていて、Googleなどのように仮の情報(レジストラの連絡先)を書くより ずっと分かりやすくスマートな気がする。
    • と思って居たが、書いたあとで見直していたら、なぜか登録者の国と県が公開されていることに気付いた。このサイトでは どちらも非公開ではないので、それくらいは良いだろう。
      • ↑書いたあとで少し調べたら、CFのプライバシー保護と従来のもの(各レジストラが提供している)の仕組み・仕様が違うようで、CFのは近頃できたらしいWHOIS redactionというものに従っているようだ。
        • それで、"DATA REDACTED"と出る。
      • また、CFはICANNのポリシーに従って県(state/province)と国を公開しているとのこと。 (→ 参照: CFの資料; フォーラム: 1, 2(質問者はCFの資料・仕様を良く理解できていない?))
        • 結局、僕が使う前に良く確かめなかったために齟齬(?)が生じた。
        • 今考えると、試用のあとに いろいろ調べずに、(元々翌日にしようと思って居たのに)すぐに移管し出したのが良くなかった感じだ。 (いつもの、思い付きが失敗した例)
  • ドメインとは関係ないが、移管後はGoogle search consoleが無効になり、(CFで)ドメインアクセス(?)への再承認が必要だった。
    • 承認処理をしないと、他人が勝手に他人のサイトの検索統計を見ることができるからか。
    • 承認の時にCFのweb画面が出て来て、承認したら自動的にCFに承認のレコードが追加されたのには感心した。

 

余談・感情的な話

Googleに移る時、Googleらしく勝手に終了するかも知れないとは思ったが、Google自体が公開DNS(8.8.8.8)をやっているくらいなので本当にそうなるとは思っていなかったし※、予想外に早かった(移ってから4年しか経っていない)。

※公開DNSは お金になる(いろいろなサイトのアクセス情報が得られる)が、ドメイン管理は そうでないと見たのか。

そもそも、サービス終了という重要なことをニュースやサイト(FAQ)に書くだけで、ユーザーにメールで知らせないのはおかしい(それがGoogleのやり方?)し、簡単にユーザー情報を売り渡す(決定をする)のは意識が低いし余りにも勝手だ。どうせ規約には書いてあるんだろうけど、それも許せない。

だから、僕がGoogleで他に使って居るCloud Storageも、急に終わるとか変更とか値上げが あってもおかしくないので、その覚悟や準備を怠っては いけない。

とは言え、(最安で悪くなさそうなので)移転先にしたCFも信用し過ぎてはいけない。そのうち、「ぶっちゃけ、無料でドメイン管理にだけ使われても困る」とか言い出しそうだwが、その時は また考えれば良い。CFに依存しなければ良いのだ。

無料でもファイアウォール(WAF)などが結構使えそうなものの、ちょっと高度なことは有料になって、(気になるものの、)高い(USD20/月から)から縁はなさそうだ。

それから、WAF(良く見る、「ブラウザをチェックしています」なのだろう)については、サイトのサーバがCFの中で動いていないため、ドメイン名でのアクセスは防御できるが、IPアドレスを直接指定して来る不正アクセス・攻撃は全く防御できない気がする。それでも、ないよりはずっと良いとは思う。

 

おまけ: Cloudflareのプロキシを少し試した。 (6/20 16:43)

本文に書いたように、CFのWAFなどの機能が気になったので試してみたが、予想どおり、今一つ使えない感じだった。有料版なら可能性はあるので、CFがこの機能を出している意図は そこへの誘導だろうか。一番の問題は以下である。

http(ポート80)とhttps(ポート443)しか通さない。 → sshなどや標準ポート以外のhttp/httpsは使えない。

※ただし、pingは応答が来る。

他の方が どう運用しているか分からないが、sshはプロキシを通さない別のホスト名かIPアドレスにしているのだろうか。標準ポート以外のhttp/httpsも同様だろうか。※ とすれば、結局、それらが穴になってしまい、元々のサーバでも不正アクセス対策が必要なので、CFのファイアウォール(WAF)のメリットは減る。本文に書いたように、サーバがCFにないための欠点である。

※標準ポート以外のhttp/httpsは止め、sshだけ開ける(サーバで直接受ける)のが現実的で、そうすればWAFも有効だろうけど、物足りない感じだ。例えば、メールも諦めるのだろうか。それもサーバで不正アクセス対策するのか。

不正アクセス対策をするのは当たり前のことだが、であれば、いろいろな我慢や設定変更をして わざわざCFのプロキシ(のWAF)を使うメリットが どこまであるのかという感じだ。

他に、プロキシなので、http/httpsのアクセス元のIPアドレスがCFのものになるため、サーバでアクセス制御・分析などをする時の対応・修正も必要だ。あと、WAFを有効に使うためには、本当にCFのプロキシからのアクセスであるかの確認が必要で、どこまでそれが確実にできるかも問題になるかも知れない。

(6/21 19:50) その後、(例によって)寝て居る時の思い付きで気が変わり、ちょっと試して見て居る。というのは、CFのセキュリティ機能が ある程度使えるなら、脆弱なWPの保護に少しは役立つかも知れないと思ったからだ。

使ってみたら、無料でも思ったより多くの機能が使えることが分かった。ただ、それらが分散気味で結構分かりにくいのが惜しい。でも、ドキュメントは豊富なので、読んで試す気になれる。

設定には なかなか手間取ったが、ひとまず、概ね普通に使えるように できて、試している。

普通に使えないのは(上述のとおり)sshで、良い方法を思い付けなかったので、CFを通さないホスト名でアクセスするようにした。また、標準ポート以外のhttp/httpsも そうしていたのだが、調べているうちに、Origin rulesという書き換えルールで、指定した条件に合うものを別のポートに転送するようにできることが分かった。ただ、それで有用なのか(意味があるのか)今一つ分からないので、様子を見ている。

上に書いたように、さまざまな機能を試していて、すぐには効果や感想などを書けないので、少ししてから別途書くことにしたい。

  •  0
  •  1
Keys: , , , , , ,

早いもので、また車検をした。今回は いつもと違い(?)、大きな問題は起こらなかった。一番大変だったのはディーラーへの往復で、混んで居たり危ない車が多かったりして 随分疲れた・・・

買ってから11年経過したが、走行距離は約6.1万kmと 延びて居ない。※

※そのため、ディーラーのおっちゃんに乗っていないことがバレて(去年の点検から1200kmくらい)、通勤に使ってないのか聞かれたたため、「今は近く・自宅で(ムニャムニャ)」と言っておいた。

実は、偶然だが、先日、ようやく床屋のおっちゃんにもカミングアウトできた。ボーナスの話が出たので、これ幸いと白状した。「去年から」と言うつもりだったが、「1年くらい?」と聞かれたので そういうことにしておいた。でも、「いつから?」でなく そう聞いてきたってことは、前から勘付かれていた気がする。

いずれにしても、騙して悪いことをするつもりはなかったので良しだ。

費用は合計約12万円(うち整備費: 約6.3万円)と、下記のように作業が多かったものの、意外に高くならずに済んだ。

今回の整備内容

  • ブレーキオイル, LLC, 発煙筒の交換
  • 前の車軸のギアボックスのオイル漏れの修理 (冬に気付いた問題1)
    • オイルシールとオイルの交換
      • 漏れたほうだけの交換だったが、もう片方も そのうち漏れないか気には なっている。が、もう遅いので「その時は その時」だ。
        • でも、今考えると、シールが劣化して漏れたのだから、もう片方も劣化しているはずだから、そのうち漏れそうだ。修理時にはオイルも交換になるので、工賃もそうだが、無駄な出費になるのが馬鹿らしい・・・
          • こっちは「片方」とは指定して居ないのだから聞いてくれればいいのに、そういうところがイマイチだ。
  • エンジンのベルトの交換 (2本: オルタネータ, エアコン) (冬に気付いた問題2: エンジンからの異音)
    • その後異音は出なかったので、問題のない可能性もある。それでも、10年以上経っているので、交換するのが安心と考えた。
  • エンジンオイル・フィルタの交換
  • ワイパーゴムの交換

事前に調べたら、定期的にエアクリーナーも交換したほうが良いようだが、乗っていて問題を感じないし、点検項目にあるから駄目なら言ってくるだろうし、点検時に清掃してくれると期待して頼まなかった。また、調べては居ないが、これくらいは自分でもできそうなので、駄目なら やるつもりで居る。

大きな問題は なし

せいぜい以下だ。

  • 前後のタイヤが入れ変わって居る気がする。
    • 自主的にローテートしてくれた? (いつものように)テキトーに付けた?
    • まあ、毎回ランダムに付けているとすれば、適宜ローテートして居るようなものだから、悪くないと考えた。
      • ホイールバランスがどうか気になるが、今まで(思い起こすと前後入れ替わったことがある気がする)は問題なかった。
  • ハンドルなどが少しベトつく。
    • まあ仕方ない。変な臭いは ないから問題ない。
  • シートのポジション(→ ハンドル、ペダル類)が決まらず。
    • 受け取って帰る時に、代車(ワゴンR)に慣れた影響か、設定が変わったと思って動かしたのが悪かった?
    • あと、身体の不調・疲れの影響も大きいように思う。
  • 帰路、なぜか、エアコンから熱風が出て来て、どうしても直らず慌てた。
    • 表示を見ると、温度が最高("HI")になっていたけど意味が分からず(風量だと思い込んだ)、いくら風量を変えたりon/offしても直らなかった。
    • ベルト交換でミスしたのか、作業時に点検用モード(実際には なさそうだ)にしたままなのかと思って電話しようと思ったが、コンビニに停めて落ち着いて試行錯誤したら分かった。
    • まあ、あのディーラーのテキトーなところではある。 (「しゃーない」)

自分ですること(予定)

結構疲れたので、やる気が出たら・車で買い物に行ったついでにする。

  • ハンドルなどのべトつきを拭く。 → (6/28 8:07記) 済み。
  • バンパー()の塗装ハゲの補修具合の確認 → (6/28 8:07記) 補修した部位は大丈夫だったが、後ろの近くに小さい点状のハゲが数個出来ていた。塗装の劣化か。様子を見ることにした。
  • 助手席フィルムの傷の補修具合の確認 → (6/28 8:07記) 何となく塗った塗料が弱い感じだが、すぐに駄目にはならなそうだった。

なお、先日交換したエアコンのフィルタは大丈夫そうだ。

  • 交換後少ししたら ちょっと埃っぽくなったが、窓を開けて しばらく強目の風を出して走ったら直った。
    • フィルタの後ろのダクトなどに埃などが溜まって居たのかと想像している。
  • フィルタ自体の臭いは わずかにある(前回も書いた、ワサビ・ヒノキ系)。

 

その他

  • 天気が悪かった(雨が降ったり止んだり)ので、洗車は してもらえないかと諦めていたが、作業が終わった頃に降っていなかったのか、運良くしてくれていたので、綺麗になって うれしかった。
  • 今回は、なぜか以前よりディーラーの対応が丁寧な感じがした。客・売上が減っている?
    • オイル漏れとベルト交換の件は、冬に見てもらった時のメモが残って居て、こちらから言わなくても分かっていたのが意外だった。
    • 走行距離が短いので、いつもはこちらから頼まないとエンジンオイルとフィルタの交換をしないが、今回は向こうから推奨して来た。
  • 代車はワゴンRだったのにソリオと思い込んで、ガソリンを補充する量を計算してしまった。
    • 実際、どういう違いがあるのか分からない。
    • ワゴンRの運転は楽だった。: パワーはあるし、視界が広い。オートライトも結構便利だ。
      • 気に入らないのは、ハンドルやサスがフニャフニャな程度。
      • CVTは まあまあ。: 停まる時に気を遣う(回生の影響だろう)のと、超低速で走るのが難しい(慣れないと25km/hが最低?)程度。
  • 下記のようにディーラーへの往復が大変だったので、車検証は郵送にしてもらった。 → (6/28 8:07記) 無事届いた。当然のことではあるが、一安心だ。 → (6/28 14:23) ところが、シールを貼るのを失敗した。意味不明な説明を誤解して、裏表逆(?)のシールになり掛けたのに気付き、運良く剥がして作り直せた。なんであんなに複雑な仕組み・説明なんだろうか? 良くある役人の仕事?
    • 以前は郵送で行方不明になったが、再発は しないと期待している。
      • 再発したとしても、今は(体力的な問題で)ディーラーに行くよりはコスト・リスクが安い・小さい。
      • 追加料金を払って配達記録などにしてもらおうかとも思って居たが、疲れて居て説明が面倒なので止めた。
    • 今回はギリギリ、シールを(視界の邪魔という話のある)運転席側に貼らなくて良いが、たった1回(2年)だけなので余り意味はない。
    • あと、(報道されて居たように)車検証が小さくなるとのことだが、見ても重要なこと(例: 期限)が分からない※とのことで、ディーラーの方も困った顔をしていた。
      • ※そのために紙が追加されているという、馬鹿さ加減!!! しかも、なぜか手数料が増えたし。
  • ディーラーまでの往復が危なくて疲労困憊した。: 5・10日, 朝・夕, 雨と揃ったせいか、混んでいたうえに危ない車が すごく多かった。ひどかったのは以下だ。
    • 交差点の手前で脇道から入れるようになるのを待っている車の右(逆走)や僕の前を すり抜けて、右側車線へ頭と長い胴を突っ込んだセンチュリー
      • 僕は1台入れたが、赤信号で進まないから その次が頭を入れて来たのでそれも待っていたら、上のような輩が出て来た。
      • あそこでは以前、似たように危ない外車(大きかった, アメ車?)を見たが、同じ奴? (いかにもな風体だった)
    • 30km/hくらいでノロノロ・フラフラと走り、青になっても 僕が催促するまで出なかったタクシー
      • もし僕らがそうしたら、クラクションを鳴らしまくるだろうに!!!
    • 交差点の直前で自転車(おそらく直進)を抜いて強引に左折した黒ナンバーの軽
      • 余りにも民度が低い・・・
      • 僕の右折を制したかったのか? (もちろん、こっちは余裕で待っていたが)
    • スーパーの駐車場の出入口の手前で、車線の反対側にある枠にバックで停め出した赤のパッソかポルテ
      • 空いてればいいが、混んでいる時に反対車線の車を止めてまでしてすること??
        • なぜ、うまくもないのに頭から入らないのだろうか?
      • そういう動きをするとは全く想像出来ずに(ハザードは出してなかったように思う)横を通過したら、あっちは こちらに全く気付いておらず、危うく接触されるところだった。
        • 薄暗い時に そういうふうに気付かれなかったことは今までに何度かあるので、ライトを点けていても全く効果がないことがあることが分かった。
          • 馬鹿には何しても無駄ってことか・・・
      • 車で運転者の属性は想像できるが、具体的に書くと差別になるので書かない(決め付けは良くないし)。: まあ、下手糞な馬鹿であることは確かだ。
  •  1
  •  1
Keys: , , , , ,