piu lentoの日々 (piu lento days)

起こりうる問題の検討と対処が終わったので、このドメインをIPv4/v6両対応にしました。当然ながら、このブログも両方対応です。

とは言え、アクセスする側からは何も変化はありません(何もする必要もないです)。あったら駄目ですｗ IPv6が使えて、IPv4より優先されているクライアントからは、IPv6でアクセスされます。もし問題がありましたら、お知らせ下さい。

なお、確認のため、当面、ブログのページ最下部にサーバとクライアントのIPアドレスを表示するようにしています。アドレスがなんか見慣れなくて : が含まれている場合はIPv6で繋がっています。

 

PS. やっぱり、個人的には、鳴り物＊も、したり顔でユーザーに押し付ける下らねえ作業(例: 良く、「Aにしたら最初にすること10個」みたいなクソページにある、「AではBはこうする」)もなしの、「気付いたら なってた」ってのが一番いい。(v6追加なんて全然ローンチじゃないが※、)「シームレスローンチ」とでも言うのだろうか?

＊ファンファーレ、「パフパフ」、「ドンドン」とかティーザーとかカウントダウンとかシャンパンとかクラッカーとか花火? それはそれで面白そうだｗｗｗ

※もちろん、日本語で「ローンチ」って言うのすら嫌いで、ここに書くのも嫌だったｗ そういう人たちとは住む世界が違うと思っている。

そういう意味では、IPv6はなかなかうまいことやっている(運がいい)。IPv6自体は全くうまくなかったが、手をこまねいているうちにOSなどが対応していて、日本に限ってだが、フレッツのPPPoEがクソになったという無関係な方向から圧力が掛かって、意外にうまい具合に移行が進んでいる感じだ(棚ぼた?)。

こんなの、当時は全然思ってもいなかったｗ (「こんな複雑なの、永遠に使われねーよ」と思って居た。: まあ、先見の明がなかったな)

サーバのIPv6対応の一環でブログ関係の対応チェックと調整をしたついでに、ページ表示が遅いのを改善してみた。

実は、今までにも、MySQLの調整をしてわずかに速くなった「気が」していたｗ

無駄な処理やコメントを省いたら、気のせいか少し速くなった。

それから ちょっと調べたら、想像どおり、OGP(Open Graph Protocol, 説明)の画像の読み込みでの遅れがかなり効いていたので、LazyLoadというプラグインを使って画像を遅延読み込みにした。スクロールさせると画像がワラワラ出るのは個人的には余り好きでないが、遅いよりは良かろう。

最初は、画像が大き過ぎる場合(OGPに幅1000画素以上とかサイズ数MBの画像が指定されている、馬鹿みたいなサイトが多い)は使わないことを考えたが、画像のサイズを取得する時に読み込むので速くならない。

あと、OGPの処理(+画像取得・表示)をJS(= ブラウザ)にやらせて非同期にすれば綺麗だしかっこいいし軽い(仕事を押し付けられたブラウザにすれば迷惑かもｗ)が、JSは苦手でなかなか面倒なので※、上記の遅延読み込みにして、結果的に非同期に近くなるようにした。

※探せば、OGPを上記のようにJSでやるようなプラグインがあるかも知れない。 → ちょっと探した限りでは、なさそうだ。

そうしたら随分速くなって、今までは最初に表示する時は1秒を超えることがほとんどだったのに、新しいページなら0.3秒くらいで出るようになった。まあ、処理を後回しにしているので当たり前ではあるが、余り手間を掛けずに3倍速くなったｗ

↓

(12/2 18:41) その後、やっぱり遅いことがあることが分かった。1秒以上掛かることがある。画像の遅延読み込みでOGPは速くなっても、MySQLが遅い場合がありそうだ。別のDBに換えたいが、なかなかいいものがない・・・

Ceronに出ていて読んだら、爆笑した上に感心した。

宮崎駿が38歳で監督デビューした時の鬼畜エピソードクソワロタｗｗｗｗｗｗｗ

彼のことはほとんど知らない(し、作品を好きでもなかった)が、読む限り(あと、あの老舗K書店のトップをクビになった太ったお兄さんを一喝した件も合わせて)、こういう人は「ジジイ」ではあるが、きっと、「老害」ではなさそうだ。

全くの想像だが、スズキの爺さんも近そうだ。

でも、一緒に居たら、きっとムカつくだろうから、「うるせージジイ!」って言いそうだｗ

 

(と、無事にネタを消化。今日のネタは今日消化する、まさに、地産地消。じゃないかｗ)

(題は微妙に違うかも。題と「毒を喰らわば−」と「背に腹は−」を足して3で割った感じかｗ)

先日の、IPv4(以下v4)だけがネットに繋がらなくなったトラブルの予防的対処のため、仕方なく、IPv6(以下v6)が使えるところは使って行くことにした。

いや、僕はそんな仕様はどっちでも良くて、そもそも「アドレス枯渇する・した」とか「遅いからv6にする」なんてのがおかしいと思って居るので、積極的にIPv6を使う気持ちはさらさらなかったのだが、ああいうトラブルがあると、さすがに全面移行とまでは行かないが、代替手段を用意して可用性を高めておく必要性を痛感したのだ。※ それが無料(自分の時間は別)で実現できるし、各アプリ・プロセスの通信速度が向上・安定する可能性がある(といっても、IPoEにしてから全体でも個々でも速度が遅いと感じたことはほとんどないが)から、まあ悪い話ではない。

※そもそも、可用性を高めることが必要なことをしているかどうかは別でｗ、「気分の問題」であろう。

それで、まずは、自分のサーバから始めた。サーバは、プロバイダがv6対応の環境で提供してくれていて、OSも対応しているので、設定すれば使える状態だったが、面倒なので今までは有効にしていなかった。

最初にサーバのv6関係の設定をした。普通にできて、デスクトップPCからpingが通った(v6のアドレスを直接指定した)。試しにwebサーバにアクセスしてみたが、通らなかった。Webサーバの設定をしていないので、v6では接続を受け付けていないためだ。

次に、設定を誤ると面倒なことになるwebサーバの、比較的単純な部分をv6対応の設定にした。試しにブラウザからv6のアドレスでアクセスしたら、例によって「怪しいサーバです。これ以上は駄目よんｗ」みたいなのが返って来て(HTTPSでSSL証明書がおかしいため)、めでたく繋がった。

それからDNSサーバにv6用のホスト名(サブドメイン)を登録した。今はv4とv6のホスト名を共通化する(同じ名前で両方に対応)のが一般的だろうが、予期できないさまざまな問題が起こりそうだったので(実際に問題は起こった(後述))、ひとまず別にした。作業としては、v6用のサブドメインにAAAAレコードだけを設定した。設定してから数分で反映され、ホスト名の検索(nslookupコマンドなど)に出るようになった。

次に、HTTPSをちゃんと使えるようにするために、Let's EncryptのSSL証明書にv6用のサブドメインを追加した。証明書の生成時にサーバの設定の調整が必要だった。証明書を作る時には、確認のためそのサーバにアクセスされるのだが、それを忘れていてwebサーバはHTTPSだけ有効にしていたが、真っ当な証明書(これを作ろうとしている!)がないのでアクセスされず、HTTP接続しようとして失敗した。それで、仕方なくHTTPも有効にして、無事(でもないけど)作れた。新しい証明書を作ってからブラウザでアクセスしてみたら、ちゃんと"404 Not found"が返って来た。

設定が複雑なので間違うと面倒なことになるブログは落ち着いてからにすることにして、まずは、普通のweb(BNoteを含む)とDAV(カレンダー・アドレス帳やJoplinで使っている)をv6対応にすることにした。とは言え、webサーバに関しては証明書を作るために調整してほとんど出来ているので、DAVサーバやクライアントアプリなどの設定変更や追加がほとんどだった。クライアント側の機器やアプリが多いので手間は掛かったものの、ほとんど問題なく終わり、ちゃんとv6でアクセスできるようになった。

とりあえずできたので、しばらく使って問題がないかをチェックすることにした。使っているうちに、以前から気になって居た、v6のプライバシーの問題※の解決策が見付かった。デスクトップPC(Linux)のv6の設定に、"IPv6 privacy extensions"というものがあるのに気付き、調べてみたら、僕の懸念を解消できそうなものだった。

※IPv6のアドレスは全世界でユニーク(かつ、不変なものもある)なので、そのクライアント(PCなど)からアクセスしている個人の特定や追跡が容易そうだという僕の懸念。

その機能を有効にし、モードを"Prefer temp. addr."にしたら、PCのv6のアドレスが増えた。今までのもの(通常のグローバルアドレス)に加え、一時アドレスが表示されている。このアドレスは通常のアドレスより秘匿性(?)が高いらしく、また、定期的に(1日-1週間のようだ※)変わるので、個人の特定や追跡が困難になるとのことだ。

※設定後1日経った今現在でもアドレスが変わっていないので、しばらくは観察する必要がありそうだ。 → 忘れると嫌なので、愛用のcrontabで自動チェックするようにした。

→ (12/2 19:35) 昨日くらいからアドレスが変わるようになった。大体30時間で変わった。設定変更後、OSの再起動またはNW IFの切断と再接続が必要だったようだ。

ただ、これには欠点もある。アドレスがコロコロ変わるので、僕がサーバのログを見て、本当に自分でアクセスしたのか分からないということだ。でもまあ、他の情報から判別できるし、プライバシーの問題の方が重要なので、Privacy extensionsを使うことにした。

一方、Androidはその点はどうなのかと調べたら、結果的には問題なさそうだ。rootになれないのでprivacy extensionsを有効にしたりすることはできないが、挙動を調べたら、v6アドレスが結構頻繁に変化することが分かった。

そもそも、Androidスマフォには2つ(以上)のv6アドレスがある。モバイル(LTE)とWi-Fiである。モバイルは、詳しいタイミングは分からないが、基地局に接続するたび(基地局が変わるたび?)に変わるようだ(機内モードをon/offした前後でアドレスが変わっていた)。Wi-Fiも同様に、APに接続するたびに変わる。

だから、僕の観察が間違っていなければ、Androidに関しても、v6で概ね問題なさそうだということになった。

なお、僕のスマフォ(AQUOS sense lite)はAPN登録時にはv6は無効になっていたが、APN設定でv4/v6のモードに切り替えたら、v6が使えるようになった。MVNOの場合、プロバイダによってはv6が使えないことがあるらしいが、僕は(IIJが下回りらしい)イオンモバイルで、全く問題なく使えた。

随分調子良かったので、このあともこの調子でスルッと行くかと思って気を良くして居たが、やっぱり、そうは問屋が卸してくれなかった。問屋というのは そんなに厳しいのだろうか?ｗ 作業面での手間はなかったが、原因不明で解決が難しそうな問題が残っている。

切っ掛けは、欲を出して早くも(サブ)ドメインをv4/v6両用にしたくなって、v6用に作ったものをそうしてみたところ、一見うまく動いているのだが、Joplinだけがおかしかったことだ。本来の動作は全く問題ないのだが、なぜかサーバのv4のアドレスにアクセスしてしまうのだ。PCのOS(Linux)のv4とv6の優先順位がおかしいせいだろうと考えて、いろいろ調べて調整しても、結局直らなかった。

それで、Joplinのフォーラムに質問を出しつつ、更にJoplinのソースなどを調べたら、確定はできないが、どうやらJoplinの下回りのNode.jsのnode-fetchという通信用モジュールの仕様(または「現状」)によるのではないかと推測している。というのはnode-fetchのcustom agentオプションのうち、v4とv6の切り替えに関係するfamilyは、socket.connectによって以下のように規定されている。

family <number>: Version of IP stack. Must be 4, 6, or 0. The value 0 indicates that both IPv4 and IPv6 addresses are allowed. Default: 0.

字義通り解釈すれば、デフォルトの0で、v4/v6どちらも使える場合に、どちらが使われるか不明(不定)だ。※ 「普通」ならOSの優先順位(Linuxではv6が優先)と同じになると期待するが、実際の動作はそうではない。もちろん、Joplinに「v4優先」という意思や仕様があれば別だが、そうする理由は全くない。また、familyには優先順位が指定できないので、「v4優先」を実装するのは面倒だ。

※Node.jsのそこのソースを読めば分かるだろうが、なかなか面倒だ。一体、Joplinから何階層下がらせるつもりだ!?ｗ

そこで想像してみると、OSまたはシステムコールまたはライブラリからホスト名に対応するIPアドレス一覧を得たあと、familyが0以外ならv4かv6でフィルタリングする。そして、残ったものを使う。複数あっても気にせず、「最初の1個」を使うのだろう。

結局、OSなどからどういうふうにIPアドレス一覧が来るかが問題だ。どうも、単にソートされているだけのような気がする。その場合、v4が先に来る可能性が高そうだ。 (まあ、余計なこと考えてないで、実物を読めば速いのだがｗ)

(11/29 0:01) 書いた後で更に調査・実験して、ほぼ原因が分かった。Node.jsのDNSモジュールのdns.lookupという関数は、ホスト名からIPアドレスを取得する(これをnode-fetchが使っているかは未確認だが、おそらく使っていると思う)。そのデフォルトの動作はDNSリゾルバの結果をv4のアドレスをv6より先に並べ替えて出すため、Joplinはv4/v6両用ホストに対しては(Linuxの標準・通常動作とは逆に)v4のアドレスにアクセスする。参考のため、dns.lookupの設定を行うオプションverbatimの説明を引用する。

verbatim <boolean> When true, the callback receives IPv4 and IPv6 addresses in the order the DNS resolver returned them. When false, IPv4 addresses are placed before IPv6 addresses. Default: currently false (addresses are reordered) but this is expected to change in the not too distant future. New code should use { verbatim: true }.

確認のため、簡単なプログラム(→ 参照: そのページ下部の"Live Demo"から開けるOnline Node Compilerが便利。ただし、そこではDNS検索は失敗してしまう)で、dns.lookupをv4/v6両用ドメインに対して実行したら、本当にv4アドレスが返って来た。そして、オプションを追加してverbatimをtrueにして実行したらv6アドレスが返って来た。。。

どういう理由か知らない(IPv6の実装が今一つだった頃からの経緯?)が、折角OSが苦労して(そのうえ、ユーザから文句を言われたであろう: 例)RFCに準拠して並べ替えたIPアドレスを、ライブラリごときが勝手に並べ替えてしまうなんて、余計なお世話もいいとこだ! 上の説明に「近い将来は逆になる」と書いてあるが、現行版ですらこの勝手な動作なので、当面は直りそうにない。ということは、Joplinの問題も直りそうにない。

直すとすれば、自分でNode.jsに手を入れることだろうが、そもそもビルド環境を作るのが面倒だ。更に、Node.jsは結構更新されそうなので、僕の修正を残すようにするのが難しい(でも、できれば爽快だろうな・・・)。

(11/29 12:57) 直し方を検討したが、「まあ不可能」という結論になった。まず、dns.lookup(DNSモジュール)はNodeに埋め込まれている(コンパイルされているようなので、パッチはまずできない。さらに、NodeはJoplinに埋め込まれている)ので、Node(この場合、Joplinも)をビルドし直さない限り入れ替えられない。

次に、dns.lookupは最終的にはLinuxのgetaddrinfo()を呼ぶが、これはlibcまたはlibnssに入っているようで(未確認)、どちらも大変基本的なライブラリなので安易には改造できない。うまくしてライブラリとNodeの間に割り込めばいいが、さすがに、いくら暇でもクソのためにそんな面倒なことはやってられない。

ってことで、気に入らないけど我慢するのがベストだ。

 

てな訳で、別に大きな問題ではないが、喉に魚の小骨が刺さったような気持ち悪さが残っている。しかし、そもそも論とか現実問題としては全く問題ない。というのは、最初に書いたように、v4が使えなくなった時の代替手段が欲しかった。そして、この仕様では、v4が駄目になったら自動でv6に切り替わる(正確には、アクセスする時に、生きているであろうv6が使われる)はずだからだ。

が、通信速度の向上・安定化とか、前回書いた、JPNEのMAP-Eのv4のポート数の上限の問題も改善したいという欲があるので、気に入らない。それで、今は、v6用に作ったドメインをやっぱりv6専用に戻して使っている(他の方にすれば「は?」って感じだろう)。

まあ、(気分は悪いが、)自分用サーバはv6専用でも何も問題ないから、このままでもいいかという気はしている。一つだけ問題が起こる可能性としては、何らかのトラブルでv6だけ通らなくなった場合にアクセスできなくなることだ(そんなことが本当に起こるのか、検討の余地はあるｗ ただ、ルータ故障時にv6非対応の物に交換したらそうなる)。その時はv4/v6両用の方がいい。ということは、そもそも論で言えば、v4/v6両用にして、Joplin(と他のNode.jsのアプリ?)だけはv4でも見逃すべきなのだろう。もう少し考えよう。

→ 全体的には、しばらくv6用ドメインで試して問題なければ、基本ドメインをv4/v6両用に変更し、v6用ドメインに換えた自分用サーバを使っているアプリの宛先をそっちに戻すのが一番美しそうだ。多くのアプリの設定を戻すのは手間だが、これなら、v6用ドメインは本当にv6用で筋がとおるし、基本ドメインはv4/v6両用で今風になるし、可用性も高まるから、いいことづくめだ。 (本当に?ｗ)

それから、Joplinと似たような問題がEvolution(メーラー)でも起こった。通常時はv6をアクセスするのだが、スリープからの復帰後にv4に戻ってしまうのだ。どうやら、Linuxの動作なのだろうが、復帰時にv6が使えるようになるのが少し遅れるようで、※その関係で先に使えるようになったv4にアクセスしてしまうようだ。

※推測だが、v6の初期化の処理が多いために遅くなるのかも知れない。確かに、普通の処理(v6アドレスの取得・調整?)ですら重そうだし、上に書いたPrivacy extensionsは複雑そうだ。そういう処理はv4には全くないので、時間差ができても不思議はない。

それで、効果確認中だが、Evolutionのネットの設定の"Method to detect online state"を"Always online"にして試している(今まではNet Managerから取得するようにしていた)。これは他の普通のアプリと同じ動作(ネットの状態には関知しない)と考えられるから、一旦v6にアクセスしたら、そのまま使い続けることが期待できる。気になるのは起動時で、その時にv4だったら嫌だから、ログイン時の自動起動では数秒送らせて起動するようにした(ログイン時はスリープと違ってOSは普通に起動しているので、必要ない気もするが・・・)。

 

最後に、v6化した効果というのか、v4のポート数の削減率を調べたところ、当然ながらあった。僕のサーバ以外にもv6対応のサーバ・サイト(例: メールサーバ)があるため、アイドル時(例: Webブラウズしていない時)のv4のポート数が半分くらいに減り、その分がv6になった。以下に例を示す。

デスクトップPCで使っているTCPの全ポート数

• アイドル時
  • v4: 15
  • v6: 15
• アクティブ時
  • v4: 38
  • v6: 14

デスクトップPCで使っているTCPのポート数(自分用サーバとプロバイダのメールサーバ宛のもの)

• アイドル時
  • v4: 3
  • v6: 10
• アクティブ時
  • v4: 15
  • v6: 10

v6を使わない場合に比べ、v4率は、全ポートでは約27-50%減少し、自分用サーバなどに関しては約40-77%減少した。

とはいえ、もちろん、「Webの表示やJoplinの同期が倍速になった!」とかいうことは全くないｗ

 

という訳で、少し前までは使いたくもなかったIPv6を頼まれてもいないのにゴリゴリ使うことになって、いつものように疲れたでござるｗ

今朝、PCを起動したら、いきなりメールがエラーの山になった。ブラウザの各タブも軒並みエラーになった。調べたらネットが繋がっていなかった。「やれやれ」と とりあえずルータを再起動しても直らず、VDSLモデムを再起動しても直らなかったので、ちょっと慌てた。ルータの表示やログにはエラーは出ていなかった。

それで、スマフォ(LTE)でプロバイダ(DTI光)に問い合わせを出した。※ が、まあ、ルータの故障の可能性が高いので、プロバイダに問題がない場合は、一時的にPPPoEに戻してもらって古いルータに交換して、修理依頼しようと思った。

※案の定、サポートのページはPC前提のようで、文字が小さくて見にくいのはいいとしても、なぜか、問い合わせの文字を入れると全体の高さが増えて、フォームの下にある送信のボタンが隠れて送れない(ChromeとOperaどちらも)という謎仕様だった。仕方ないので、非会員用のフォームから送った(なぜか、こちらはまともだった)。

もちろんこれで諦める訳でもなくｗ、もう少し調べたら、IPv6(以下、v6)のサイト(例: v6対応のDNSサーバ, JPNEのIPv6チェック, Googleニュース(ただ、内容が古い), FASTの速度測定)には繋がった。

あと、DTIのサポートサイトも実はv6で繋がるので、上記のようにスマフォで苦労して入力する必要はなかったが、その時は分からなかった。

ちなみに、v6で繋がるかは、Linuxだとnslookupコマンドやhostコマンドで分かる。対応している場合はv6アドレスが出る。ただ、v4でもv6でも繋がらない場合は、そもそも何も出ない。

それで更に調べたら、ルータ(I/Oデータ WN-SX300GR)のファームウェア(以下、ファーム)が今月頭に自動更新されていたことが分かった。それから、今朝(3時頃)、プロバイダが障害を起こしていた。

偶然の一致だとは思うが、丁度その少し前(2:52)からAWS(US)が障害を起こしていた。もし関係しているとすれば、IPv4関係のサーバにAWSを使っているのだろうか。 (18:19)

ということは、プロバイダの障害対応に問題があった可能性はわずかにあるものの、ルータの新しいファームがおかしい可能性が高いので、一つ前のに戻してみることにした。すると、嘘のように問題なく繋がるようになった。

ファームを戻すのに、ルータの「初期化」でできるのか分からなかったので、スマフォでダウンロードした。それをUSBでPCに送り(ネットが駄目なので、最初はどうしたものかと思ったｗ)、EXE形式だったので※、一旦VirtualBoxのWindowsで展開してルータに入れた。

※それにしても、なぜ、単に展開(「解凍」)するだけのものをEXEにするのか意味不明だ。普通にZIPで圧縮すればいいものを・・・ (もしかして、外部ツールを使わずに展開できるようにしたのか)

しかも、笑える(笑えない)のは、そのEXE(EXEpressというもので作ったらしい)の方が中身のファームより大きいことだ。圧縮の意味はなく、単にreadme.txtを同梱したかっただけのようだ・・・ やっぱり、今話題の「暗号化ZIP付きメール」みたいなものだ。

ということは、プロバイダ(実際にはJPNE?)の障害対応で あちらの機器を再起動したので、ルータも接続処理を最初から始めようとして、そのネゴシエーション時にバグとか相性が発現して駄目になったのではないだろうか。だから、新しいファームになってから こちらのルータを再起動したら駄目だったはずだ。

書いたあとで気付いたが、ファームの自動更新後にルータは再起動するはずで、その時に問題が出なかったのは腑に落ちない。プロバイダ側にも、近頃や今回何か変わったなど、問題の原因があるのかも知れない。いまだに回答が来ないので、何とも言えないが。 (18:22)

プロバイダの回答にもよるが、まあ、向こうの機器がおかしかったらもっと大量の苦情が出るはずだから、このルータの問題だろう。時間が経ってから問題が出るのは怖い。とりあえず、ファームの自動更新はoffにした。

でも、他の人は大丈夫なのだろうか? 問題が出ていないのかユーザが少ないのか、これから出るのか(「全然繋がらない」、「突然壊れた」?)。プロバイダの回答が来たら、ルータのメーカーに連絡しようと思う。

↓

プロバイダから回答があり、今回は設定の変更などはないとのこと。上記のように腑に落ちない点はあり、もしかしたら、(今回でなく)近頃変わった可能性はわずかにあるが、90%以上はルータ側の問題だろう。

って訳で、やっぱり時限爆弾だったようだ。 (18:40)

(22:02) ルータのv4通信が駄目になったことの遠因として考えられるのは、上にも書いたようにAWSの障害だ。Downdetectorのグラフ(リンク先はキャプチャ)を見ると、ルータがおかしかった9時頃には日本からの報告が最初のピークになっている。ということは、落ちたAWSに国内からアクセスしている端末が頻繁にリトライを繰り返してフレッツ網が重くなったために、ルータのv4通信が正常に動かなくなってしまった可能性がある。実際、14時頃に速度を測定したら、遅いうえに変動が激しかった。ただ、リトライでそこまで通信量が増えるとは考えにくい。それとも、通信量でなくセッション数がオーバーして駄目になったのだろうか。IPoEのIPv4はそれがないはずだが・・・

(22:58) 寝ようとして もう一個思い付いた。IPoEのIPv4はMAP-Eで、今のプロバイダはJPNEを使っているので、ルータ当たりで使用可能なポート数は225個である。以前検討して通常時は問題ないとしたが、今回は、PC起動時には全く接続できない状態だったため、PCとスマフォからのリトライが多発してポート数が足りなくなって、接続できない状態が続いたのかも知れない。確かに、ルータを再起動した直後の短時間(1分間程度)は通信できていたがすぐに駄目になった。通信が回復した途端に多くのプロセスが通信し出して、また駄目になっていたのかも知れない。特に、ブラウザは多くのタブがあるので、一度に通信し出したらとんでもないことになる。

最初のPC起動時に駄目だった理由は分からないが、ポート数の問題だとすれば、しばらく(結構長い)待てば回復するはずで、それが丁度、ファームを古いものに戻した頃だったのかも知れない。

最初のPC起動時に駄目だった理由として考えられることは、新しいファームは微妙にタイムアウトが短いなどネット(フレッツ網)の輻輳に弱いためかも知れない。

ポート数の問題だったかは、ファームを再度最新にして試すか、今のファームでも、ルータをモデムから切り離してしばらくしてからPCを起動すれば分かるが、どちらもなかなか面倒だ。 → 後者を寝る前に試す。

↓

(11/27 5:49) 完全に同じ状況ではないが、ポート数不足は起こらなそうだ。PCの起動時に一番多いのはメーラー(Evolution)のIMAPでのメール取得で、ブラウザは自分でリロードなどしない限りは接続しない。メール取得中にブラウザでいろいろ開いた時の使用ポート数は81だったから、余裕がある。一方、スマフォはしばらくWi-Fi経由で接続できないと自動で無効にするようなので、接続再開時に一気に接続が増えることはなさそうだ。

つまり、何らかの原因でルータのファームとプロバイダとの相性のようなものが発現した可能性が高い。それをメーカーに指摘しても、大抵は分からず仕舞いな気がする。

それで、ポート数不足の予防や同じ問題が起こった場合に何もできない事態を減らす事前対処として、なるべくv4での接続を減らすようにした。具体的には、Evolutionの各IMAPアカウントの同時接続数を1に減らし、使っているメールサーバ(さくらのメールボックス)のv6対応をonにした(知らなかったが、そういう設定があった)。あと、バックアップに使っているオンラインストレージBackblaze B2もv6対応しているようだが、バックアップソフトduplicacyは使わないようだ。積極的に使わないのでなく、APIで指定されたホストがv4なのかと想像している。※

※近頃のログを見たらいつも同じホストなので、もしかしたら、最初にバケット(記憶領域)を作った時にホストが決まり、それがv4のみに対応しているのかも知れない(ストレージは容易に移動できないので、その可能性が高い)。今後の対応に期待したい。

 

それにしても、僕にとってはネットはライフラインであることを再認識した。今回はスマフォがあって良かったが、もしなかったら、本当に にっちもさっちも行かなかった(電話じゃファームのダウンロードなんてできない!)。だから、無駄なようだけど二重化は意味がある。

そして、そういうすごく重要なところに安いルータを使っているのは良くないことに気付いた。十年近く使えるのだから、1-2万円くらいのにしても良さそうだった。※ が、時既に遅しだ。それに、国内のN社は評判はいいけど(近頃は微妙な感じ)好きじゃないし、Y社はすっごく高いしWi-Fiのはないからな。まあ、問題が頻発したら交換を考えよう。

※思い出した。当時はv6にする効果(高速化)に疑問があったので、とりあえず試すために安い物を買ったのだ。今はv6でないと使い物にならないので、次は高目のものを買えばいい。

 

PS. 今回、意外にIPv6対応のサイトが少ないのを実感した。Googleはまあ優等生だが、tenki.jpとかYahoo!天気など、いかにも対応してそうなところが駄目だった。そもそも このブログも駄目だしｗ

あと、こういう時のために自前でv6→v4変換サービス(プロキシみたいなもの)を作りたくなったが、なかなか面倒だし、今回のようにv4だけ駄目っていう障害は稀だろうし、ファームを戻したら回復したので、早くも「喉元過ぎれば」となって「また今度」にしたｗ

でも、意味があるかは疑問だが、とりあえずこのサーバをv6対応にしたい気もしている。

PS2. ネットが駄目な状況でもJoplinは問題なく使えたので、感心した。PCからもスマフォからも何事もなく読み書き出来(もちろん、同じノートは同時に変更していない)、ネットが繋がったら普通に同期した。某Evernote(web)ではエラーが出て使い物にならなかっただろう。