今日もまた踏みました

非定期更新:主に何とも言えない事態にあった際に更新しています

ドコモ光10ギガを電話付きルーター無しで契約したらルーターが届いて???になった件について

どの様な状況か
  • 2023/05/31より ドコモ光 10ギガ 向けの ドコモ光電話 が始まった
  • プロバイダはOCNインターネット
  • これまでのフレッツ光から ドコモ光 10ギガに乗り換え手続きを行った
  • ルーターは自分で用意すると伝え、ルーター契約は無し
  • 切り替え当日になって、NTTよりXG-100NE(10G対応Wi-Fiルーター)が届いた
とりあえず結論だけが知りたい人向けの結論
  • ドコモ光 10ギガ 向けの ドコモ光電話を契約した時点で ひかり電話対応の「ルーター」が必須となる
  • 必須なのでXG-100NEが届く
  • ドコモに連絡すると違う事を言われるが、フルスペックのXG-100NEが届く
  • NTT東日本によると、そもそも機能制限したXG-100NEなど存在しない
  • ひかり電話を利用する場合は、550円/月のWi-Fiルーターは多分不要
 
ドコモ光 10ギガを契約するにあたり事前に知っておきたい事

10G対応ルーターは必須。IPoE対応である必要があるっぽい
下記の辺りを調べると良い
【10ギガ】ドコモ光対応プロバイダのルータ対応状況
https://www.docomo.ne.jp/content/dam/corp/jp/ja/binary/pdf/hikari/common/docomo_hikari_10g_router.pdf
OCNバーチャルコネクトサービス(IPoE接続)対応端末
https://www.ntt.com/content/dam/nttcom/hq/jp/business/services/network/internet-connect/ocn-business/option/v-access-ipoe/pdf/bocn_vc_router.pdf
※10gbpsに対応しているかではないので注意が必要

 

どうしてこうなったのかは謎だが経緯はこんな…

ドコモショップでしてきた話

私:550円/月のレンタルルーターは要らない。自分で用意します
ド:その場合、ONUだけが貸し出されます
私:そう言えば、ひかり電話のモジュラージャックはどこに付いてるの? ONUに付いてる認識で良い?
ド:さようでございます
私:(え? マジで…? 本当かなぁ………) 心の叫び…
ド:今回はフレッツからの乗り換えなので、工事は不要で事前に郵送された機器の差し替えをお願いします

そして、郵送物が届いて物語は動き出す
  • 箱を開けると箱が2つ入っている…
  • 1. 10G-EPON こちらはONU
  • 2. XG-100NE どう見てもWi-Fiルータ

ルーターは要らないって言ったし、ONUだけが届くって言ってたのに、ルーターが届いた

とりあえずXG-100NEの設定を見てみる
  • 初期IPは192.168.1.1らしい
  • http://192.168.1.1 を開いてみたら「接続回線探索中」と出ていて何もできない
という事でドコモに電話してみたら こんな感じの内容だった

私:ルーター契約無しのはずなのにルーター来ましたけれど
ド:ひかり電話の契約によりお送りさせて頂いているようです
私:550円/月がかかるので?
ド:不要です。ルーターの様に見えますがWi-Fiルーターの機能は利用できません
私:機能限定版という事?
ド:さようでございます
私:付属されている説明書がフルスペック版のものなので設定や設置方法が
  わからないのだけれども
ド:こちらでもわからないのでNTTに聞いてください

という事でNTTの連絡先を教えていただく

という事でNTTに電話してみたら こんな感じの内容だった

私:ドコモ光10ギガ+ひかり電話を契約し、ルーター不要の契約をした所、
  XG-100NEが届いたのですが…
N:ドコモ光10ギガでひかり電話を利用するならXG-100NEは必須です
  他の選択肢はありません
私:ですよね。ドコモではONUにモジュラージャックあるって言われましたけどね…
N:失笑。ルーター機能が必要なのでルーター必須です
私:ですよね。おかしいとは思ったけれど…
  ああでもドコモからWi-Fiとかルーター機能を使えなくしたXG-100NEだと
  聞いていますけど、ルーター機能無くても大丈夫なんです?
N:え?
私:え?
N:そんな制限を設けたXG-100NEなんて無いはずですけれど…調べてみます
N:確認した結果、制限を設けたXG-100NEはございません
私:なるほど、なのでフルスペック用の説明書が付いていたのですね
N:そうなります。ですので、XG-100NEのルーター機能、Wi-Fi機能全てご利用頂けます

ついでに細かい設定を聞いてみた

私:「接続回線探索中」って出てるのだけれども、これはどうしたら?
N:ONUを光コンセントに繋いで、ONUXG-100NEに繋いで準備できた段階で利用可能になります
私:自前のルーターがある場合は、どの様な設定が必要ですか?
N:特に設定されていない場合、XG-100NEはブリッジ接続になるので、接続して頂ければ問題ありません
私:ONU - 自前ルーター - XG-100NEの順番になると、ひかり電話が使えない認識で良いですよね
N:さようでございます

総括

QNAPのOpenVPNクライアントで接続すると1分おきに接続が再起動される事案が発生

どのような状況か

QNAP にある QVPN Service を利用して OpenVPN サーバーへ接続していたのだが、どうにも通信が安定しない。ログを見ると約1分おきに切断・再接続が繰り返されている。たまたま6台の全く同じ QNAP を全く同じように構築していた時に発生していたため、なぜか大丈夫な QNAP がある事に気が付いた

1分周期という状況と、大丈夫な QNAP は全く問題ないので何か設定があるのではと追いかけて、問題点がわかったので、メモを残す事にします

 

とりあえず解決方法だけ知りたい人向けの、行った QNAP への変更点
  1. コントロールパネル → ネットワークとファイルサービス → ネットワークと仮想スイッチ → システムの規定のゲートウェイを開く
  2. システム規定のゲートウェイを選択してくださいと出るので、「システムのデフォルトゲートウェイを自動選択」になっていたら、「システムのデフォルトゲートウェイを選択」に変更して、「固定ゲートウェイ」を自分で選択する
  3. これで解決されない方は、ごめんなさい

 

現象が出ていた当時の環境(参考)

モデル : TS-233
ファームウェア :  QTS 5.0.1.2277

 

原因と思わしきことへの考察

環境にもよりけりなのだと思うけれども、そもそもに今回の QNAP 構築において、このシステム規定のゲートウェイゲートウェイがうまく設定されず、手動で選択してから自動に戻すということを行っていた

一度、手動で設定すると自動に戻しても安定するので、それでよしとしていたが、どうやら良くなかったらしい…

SSHで入ってみて、dmesgを入れてみると、
!@[/etc/init.d/net_event_setup.sh]rename_trct_nic() called
という内容が大量に出ていた。およそ1分おきに…

なにをやってるのかを調べる気にはならなかったものの、名前から上記の作業をやっていた事を思い出して、変更してみた結果、解決に至った

つまり、1分おきにデフォルトゲートウェイを自動で再設定してるのかな?
デフォルトゲートウェイが瞬間消える → インターネットが瞬断される → OpenVPN が切断される → OpenVPN の再接続が発生する
こんなコンボが繰り返されている様な気がする

さとふるから寄付金控除に関する証明書のダウンロードを行おうとすると、電子交付サービス利用規約が繰り返し表示される事案が発生

e-taxを利用した確定申告で利用できる寄付金控除に関する証明書の電子交付を申し込みを行い、「寄付金控除に関する証明書」電子交付完了のお知らせを受け取り、メールに記載されているさとふるのサイトを開くと、電子交付サービス利用規約が表示される
利用規約に同意する」にチェックを入れた後、「利用規約に同意して進む」を選択するが、また電子交付サービス利用規約のページが表示されてしまい、対処に悩んだので対応方法を記載しておく

 

結論

右ではない左を見ろ!

 

実の所、xmlがダウンロードできるe-私書箱のページが別のタブで開いている
だが、e-私書箱のページを開いた後に、さとふるの電子交付サービス利用規約ページが再度開かれてしまうため、e-私書箱のページが、さとふるの電子交付サービス利用規約ページの左側に開いている状態になってしまう

新しいタブが右側に開くものと思い込んでいると、開かれているe-私書箱のページに気が付けないので気を付けたい

GitLabをReverse Proxy越しに利用する設定を確認したら迷走する事案が発生

GitLab CEを さくらインターネットVPSで使おうと思ったのだけれども、重くて我慢できる感じがしなかった。とはいえスケールアップしても、まともに動くかわからなかったので、GitLabは社内のサーバーに入れ、VPSにReverse Proxyを立てて、Reverse Proxyを経由して使用する方向で作業を進めていたが、色々と迷走してしまったので、メモを残す事にします

 

超ざっくりとした前提条件
  • Reverse Proxy側のURLは、https://reverseproxy.aaa.com:12345/で接続可能
  • GitLab側のURLは、http://gitlab.aaa.com:23456/で接続可能

 

途中はどうでも良い人向け、最終的に行ったGitLabの設定

Reverse Proxyに対応するための /etc/gitlab/gitlab.rb の修正箇所は下記

  • external_url
    ここには、GitLab側のURLではなく、Reverse ProxyへのURLを記載する
    上記前提に沿うと、'https://reverseproxy.aaa.com:12345' になる
  • nginx['redirect_http_to_https']
    GitLab側をhttpにする場合には false を設定する

  • nginx['listen_port']
    GitLab側のポート番号を指定、上記前提に沿うと 23456 になる

  • nginx['listen_https']
    GitLab側をhttpにする場合には false を設定する

設定例

external_url 'https://reverseproxy.aaa.com:12345'
nginx['redirect_http_to_https'] = false
nginx['listen_port'] = 23456
nginx['listen_https'] = false

 

参考にさせて頂いたサイトなど

GitLabサーバーを構築してみる【AlmaLinux8】 – supilog
ubuntuにGitLabをインストールしてnginxのリバースプロキシで接続する | 人と情報

 

社内サーバー側で行った手順(必要な箇所のみ抜粋)
  1. AlmaLinux 8.5をインストール
  2. dnfでepelをインストール
  3. GitLab CEをインストール
  4. GitLabを設定(ローカルでの動作確認用設定)
  5. 動作確認
  6. GitLabを設定(Reverse Proxy設定後の最終設定)
VPS側で行った手順(必要な箇所のみ抜粋)
  1. AlmaLinux 8.5をインストール(これは契約時に選択)
  2. dnfを最新に変更
  3. dnfでnginxをインストール
  4. nginxを設定
  5. 動作確認

 

上記、手順の問題点

上記の手順で進めた場合、社内サーバーに入れたGitLabの動作確認。ここで迷走しやすいので手順に注意が必要になります
最終的なGitLabの設定は上に記載させて頂いた形になるが、社内サーバーのみでの動作確認を行う際の設定は下記になります

external_url 'https://gitlab.aaa.com:23456/'
#external_url 'https://reverseproxy.aaa.com:12345'
#nginx['redirect_http_to_https'] = false
nginx['listen_port'] = 23456
#nginx['listen_https'] = false

 
ざっくりとした理由

まず、external_urlを'https://reverseproxy.aaa.com:12345'のまま、社内LAN環境より、http://gitlab.aaa.com:23456へアクセスした場合、突然 https にリダイレクトされて落ちる事がある。また、ログイン時に「422 he change you requested was rejected.」で落ちるため、動作確認ができず、色々と設定を変更して迷走することとなった
それを回避するため、最初から https でGitLabのインストールができている事を確認するのが無難な選択となります

GitLabが正常に動作しているのを確認した後、Reverse Proxyの設定を終わらせ、Reverse Proxy経由でGitLabに接続できる状態になってから、最終的な設定例に変更し、gitlab-ctl reconfigure で設定を変更します
設定変更後は、gitlab.aaa.com 側に接続しても、上記の通りログイン時に「422 he change you requested was rejected.」で落ちます
代わりに https://reverseproxy.aaa.com:12345 からの接続が可能になります

Reverse Proxyを利用する場合、external_urlには、Reverse Proxy側のURLを設定する。設定した後は、直接つないでの確認はできない。これを知っているかが迷走するかしないかの境目になりそうです

このご時世にEdgeさんがフィッシングサイトに拘束される事案が発生…

姪っ子からヘルプ要請が入り見に行った所、フィッシングサイトにEdgeさんが拘束され、二進も三進も行かない状態になっていた

どんな状況か
  • フィッシングサイトが開かれ、フィッシングサイトのOKボタン以外の操作がEdge上でできなくなった
  • 内容は不正利用しているから支払え系の内容
  • OKボタンを押すと印刷のダイアログが表示される
  • ×ボタンで閉じる事ができない(各ページ及びEdgeそのものも不可)
  • F12で開発ツールも開けない

基本的に何も操作ができません…

何が問題か
  • ×で閉じれないため、Windowsをシャットダウンするなり再起動するなりしていた
  • Edgeのクラッシュ対策機能により、次回のEdgeは強制的に閉じたページをまた開く仕様になっている
  • 結果、Edgeを開くとフィッシングサイトがまた開く

簡単に言うと無限ループします

さらに何が問題か
  • Edgeのキャッシュクリアなどの作業はEdgeにあるメニューを選択する必要がある
    ※今の所、ショートカットする手段は見つからず
  • フィッシングサイトが開いているとEdgeの設定が開けない

EdgeのキャッシュをクリアするにはEdgeを開かなければならないがEdgeが操作できない…みたいな感じです

対応方法

色々と考えましたが、おまじないが必要です

  1. Edgeを閉じます。閉じ方がわからない場合はWindowsを再起動します
  2. コマンドプロンプトを起動して頂き、下記をコピペします
    %LOCALAPPDATA:~0,2%
    cd "%LOCALAPPDATA%\Packages\Microsoft.MicrosoftEdge_*\AC\MicrosoftEdge\User\Default\Recovery\Active\"
    start .\
  3. Activeというディレクトリが開かれます
  4. Activeの中のファイルを削除します
  5. Edgeを起動します

という手順で基本的に大丈夫なはずです

 

全てが終わってから、実はもう一つEdgeを立ち上げて、そちらでキャッシュをクリアすれば良いのではとも思いましたが、問題のページを見失ったのと、ページ復帰機能はキャッシュのクリアと連動しない様な気もしたので、手堅い方法として記載しておきます

Excel で URL をクリックした場合とブラウザに URL を貼り付けた場合で違うページが開かれる事案が発生

前提条件です

基本的なところですが、下記の様な手順で URL のリンクを作成し、クリックにて URL を開いた時の事になります
また、Excel と記載していますが、Word や PowerPoint など Office 製品全般に言える様ですが、ここでは代表して Excel にて説明をします

1. Excel を開きますf:id:itrident_kumakawa:20160309120125p:plain

2. セルに URL を入力しますf:id:itrident_kumakawa:20160309120129p:plain

3. Enter キーなどで入力内容を確定します ( 入力内容がリンクになります )f:id:itrident_kumakawa:20160309120133p:plain

4. このリンクをダブルクリックして開きますf:id:itrident_kumakawa:20160309120137p:plain

上記の様な手順を実行したときに直接ブラウザで開いた場合と異なるページが開かれる場合があります

「お断り事項」
当内容は、2016/01/01時点でのExcel 2010 および 2013にて確認を行っております。
この動作が Microsoft 社の想定している動作か否かはわかりません。
よって知らぬ間に修正されている可能性はあります

 

どの様な事が起きるのか

参考用サイトを作成しました(誤って消してしまっていたらごめんなさい)
http://www.hhsb.jp/exceltest/subpage.php

 普通の操作Excel リンククリック

ログインページが開く
User:hoge
Password:hogehoge
を入力しログイン

f:id:itrident_kumakawa:20160309121103p:plain f:id:itrident_kumakawa:20160309121103p:plain

 

ログイン後のページへ遷移する
f:id:itrident_kumakawa:20160309121453p:plain f:id:itrident_kumakawa:20160309121544p:plain

このサイトはサブページを参照する際にログインを必要としています
そのため、普通の操作および Excel リンククリックでの操作ともに最初はログインの画面が表示されます。本来であればログイン後にサブページへと画面が移りますが、Excelのリンクをクリックした場合は、サブページではないページへと移ってしまいます

 

どの様なサイトで発生するのか

下記の様な構成になっている場合に発生します

f:id:itrident_kumakawa:20160329174519p:plain

特徴として、ログインしていない場合の画面遷移を Forward ではなく Redirect で行っているところです(処理として間違っている訳ではないです)
そして Excel で開いたリンク先でリダイレクトが発生した場合に想定と異なります

 

なぜ、このような現象が発生するのか

Excel にて リンクをクリックした場合、まずは Excel 内部で持っているブラウザにて URL へのアクセスを試みます
特にリダイレクトされている訳でもなく、また初めて開く URL の場合は、次の様な流れとなります

内部ブラウザにて URL のヘッダーを確認 (HEAD リクエスト)
→ 内部ブラウザにて URL のダウンロードを実施 (GET リクエスト)
→ デフォルトブラウザを URL 指定で起動

具体的に何をやっているのかはわかりませんが、HEAD リクエスト後に GET リクエストが発生している関係上、内部でキャッシュを持っており、そのキャッシュの更新確認を行っていると思われます
あくまでも推測の域を出ませんが、URL の信頼性などの確認を行っている様です

 

問題のケースとなりますが、間にリダイレクトが入ると下記の様な動作に変わります

内部ブラウザにて URL1 のヘッダーを確認 (HEAD リクエスト)
→ レスポンスにより URL2 への 302 リダイレクトを受けとる
→ 内部ブラウザにて URL2 のヘッダーを確認 (HEAD リクエスト)
→ 内部ブラウザにて URL1 のダウンロードを実施 (GET リクエスト)
→ レスポンスにより URL2 への 302 リダイレクトを受けとる
→ 内部ブラウザにて URL2 のダウンロードを実施 (GET リクエスト)
→ デフォルトブラウザを URL2 指定で起動

なぜか途中でリダイレクトを受け取ると、最後にデフォルトブラウザを呼び出す段階になって、リダイレクト先の URL を渡してしまっています
上記のサンプルもそうですが、ログイン後にアクセスされた URL へと戻る様に作成してありますが、Excel のリンククリックより起動した場合は、最初からリダイレクト先の URL で渡されてしまうため、戻る先がわからなくなります
そのため、普通に開いた場合と Excel のリンクを開いた場合で動作が異なってしまう事になります

この動作を狙って作ってあるのか、それとも何らかミスなのかはわかりませんが、現象としては、この様に動くようです
狙ったページが開かれない場合は、URL をコピペして開く様にした方が良いです

 

ついでにこの現象を経てわかった事

Excel のリンクをクリックした場合は、ダウンロードが 2 回発生する…
1GB のファイルがダウンロードされる URL をクリックしたら、1GB のファイルを 2 回ダウンロードする様です…

また、URL の先が無い場合は、タイムアウト待ちを行った後にブラウザが起動されます…たまにもっさりとした動作になるのは、これが原因の様です

こういった事より、基本的に Office 製品に貼りついている URL のリンクはクリックで開かずにコピペにて直接開いた方が良さそうです

e-Tax ソフトのインストールが途中で止まって先に進まないという事案が発生

どのような状況か

e-Taxソフトが新しいソフトウェアのインストールを構成中です。」のまま止まってしまう。という現象が出る場合の事です ( 下記画像の様な状況です )

f:id:itrident_kumakawa:20160227040018p:plain

『追記』
公的個人認証サービス ( jpki )のインストールプログラムでも同様の現象が出ている様な気がします。同じ対応で対処できましたので参考にしてください

細かい事はいいんだよ。結論を言え結論をという方へ
  1. アプリを閉じる
    動いているアプリケーションを閉じましょう
    まずはタスクバーで動いているアプリケーションを順次閉じます

    f:id:itrident_kumakawa:20160227040815p:plain

    セットアッププログラム以外をすべて閉じ終わったら少し待ちます

  2. まだ動かない場合は、さらにアプリを閉じる
    引き続き動いているアプリケーションを閉じましょう
    タスクトレイで動いているアプリケーションを順次閉じます

    f:id:itrident_kumakawa:20160227041216p:plain
    概ね閉じ終わったら少し待ちます

  3. まだ動かない場合は、さらにアプリを閉じる
    ダメな場合は、ここに居るアプリケーションも忘れずに閉じましょう

    f:id:itrident_kumakawa:20160227041433p:plain

  4. 数分待ちます

それでもダメな場合はセーフモードで起動しなおして入れてみると良いです

 
なぜこんな事が?という方へ ( ここからは推察です )

≪おことわり≫
アセンブルなどをして解析した訳ではなく現象からの推察です
従いまして情報に誤りがある場合があります

 

このインストールプログラムは、複数のインストールプログラムを順次実行し、アプリケーションを構成していきます

この作りは、1 つ 1 つのインストールプログラムが小さくなりますし、不要なものを入れないため使い勝手が良くなりますので良い作りと言えましょう

問題は、この『順次』の部分になります
順次処理を行うには、動いているプログラムが終わるのを待つ必要があります

色々とやり方はありますが、メジャーな所では
・プログラムのタイトルに特定の文字が含まれるかをチェックする
・特定のプログラム名に特定の文字が含まれるかをチェックする
などを行います

上記の様なルールに合致するアプリケーションが起動していますと、誤判定をしてしまい、いつまで待っても終了しないという事象が発生します

なお待ち時間が必要なのは、上記チェックを行うタイミングが不明なためです。これは数ミリ秒~数秒、まれに 1 分周期などのケースもあります。よってコーヒーブレイクするぐらいが無難です

判定ルールの調査を行っておりませんので、具体的にダメなルールはわかっていませんが、インストール作業の時のみの現象ですので、片っ端からアプリケーションを閉じるのが良いと思われます