tech

TL;DR 楽天モバイルは、公式サイトのエリア図で赤く表示されている地域でも地下、マンションなどでは届きづらいことが結構あります(2021.09現在)。普段使いでの利用はまだ避けた方がよいかもしれません。 経緯 私のスマホの利用は、Wifi環境がある自宅での利用がほとんどで、友達も少なくて電話連絡など月に1,2回あるかどうかです。 名古屋市内に住んでいますが、公式サイトの通信エリアを見ると真っ赤になっているため、まぁ問題ないだろうと判断し、楽天モバイルに切り替えました。 友達が少ないことが幸いし全く問題を感じていなかったのですが、先日、マンション6階以上の自宅に電話がかかってきたので出たところ、相手の音が聞こえなくなる事象が10-30秒おきに発生し、最終的に2-3分の通話で通信が切れてしまいました。iPhoneのアンテナ表示を見ると1本だけ何とか立っている状況… 慌てて1Fに降りるとMAX4本立って問題なく通話できるようになりました。 公式サイトのエリア図はあくまで障害物がない地上エリアの面積としてのカバー率で、マンションの上層階といった高さ方向や、建物の中、地下といった障害物のある環境での通信環境では大手携帯会社にはまだまだ及ばないのだと推測しています。 パートナー回線エリアであれば逆に良かったのかもしれませんが、自宅を含む名古屋市が楽天回線エリアのため発生する問題なのかもしれません。 ちなみに、別契約しているdocomo回線では自宅でもアンテナMAX4本立っています。 使用頻度が低い私のような人は運用でカバーできますが、そうでない人が、公式サイトのエリア状況だけをもとにメイン回線を楽天モバイルに切り替えるのは、まだ早いかなと思いました。

TL;DR Ubuntuサーバ20.04で、重複しているIPを持つサーバから重複しているかどうかを検知する場合は arping -I eth0 -0 -c 2 (IPアドレス) (eth0は適宜置き換え)を実行し、応答がある(戻り値:0)場合は重複あり、応答がない(戻り値:1)の場合は重複なしと判断します。 経緯 Ubuntu20.04 サーバ上で使用しているIPアドレスが重複しているかどうかを、そのIPアドレスを使用するサーバから検知したいと考えました。 arping, arp-scan等のコマンドを使うと説明するサイトが多数見つかるのですが、ほとんどが重複しているIPを持つ可能性のあるサーバとは別のサーバで実行することが前提のようで、うまくいきませんでした。 自身が同じIPアドレスを持っていると、そのIPアドレスを対象としたARPリクエストを送ってくれないようでTIMEOUTになってしまいます。 そこで、-0(数字のゼロ)オプションをつけると、ARPリクエストを送ってくれるようになりました。ただし、自分自身からは応答が帰ってきませんので、応答がある(戻り値:0)場合は重複あり、応答がない(戻り値:1)場合は重複なしと判断することになります。 このオプションは、ARPリクエスト送信時の送信元IPアドレスを0.0.0.0にするもののようで、これによりARPリクエスト自体が送られない問題を回避できるようです。 参考: Ubuntu20.04にインストールされるThomas Habetsさんのarpingのマニュアル

TL;DR Windowsをファイルサーバ等の目的でフォルダを共有する際は、共有アクセス権を「フルコントロール」にはせず、「変更」+「読取」にする。 「フルコントロール」にすると、作成したファイル、フォルダに対して権限の変更が可能になってしまう。 経緯 Windowsをファイルサーバ等の目的でフォルダを共有する際、共有フォルダ権限とNTFS権限の2つがあり、どのように設定するか迷うことも多いです。 NTFS権限のほうが細かく設定できるため、共有アクセス権限は「フルコントロール」にしてNTFS権限で制限すればよいとしているサイトを多く見かけます。当社もそのように設定していました。 ですが、このように設定すると、利用者が作成したファイルやフォルダに対して利用者自身がアクセス権の変更を行うことができてしまいます。作成したファイル・フォルダの「所有者」は利用者が設定されてしまうためです。 対応としては、NTFS権限はそのままで共有アクセス権限を「変更」+「読み取り」に変更すればよいです。

TL;DR WindowsでHDDからSSD換装などでシステムディスクを入れ替える際は コピー先のディスク容量(パーティションサイズではなく)がコピー元より大きい場合: Windows標準のイメージバックアップからシステム修復ディスクによる復旧でOK コピー先のディスク容量(パーティションサイズではなく)がコピー元より小さい場合: 素直に有償のクローンソフトを使おう 経緯 HDDで動作しているWindows 10をSSDに入れ替える作業を行いました。この手の作業でベストなのは、　HDDで必要なデータをバックアップしておき、　SSD側ではWindowsをクリーンインストールしてバックアップからデータを復旧、必要なプログラムは再度インストールしてもらうことです。 ですが、インストール済みのソフトを再インストールする手段がない、バックアップで必要な設定が復旧できるかわからない、等の理由でできないことがあります。今回もそうでした。 Windows 10にはイメージバックアップを取る機能がありますが、復旧時に同じサイズのパーティションを作成します。コピー先のディスクサイズがコピー元より大きければ問題ないのですが、そうでないと一筋縄では行きません。今回、以下の作業を行いましたが、問題を解消できませんでした。 Windowsで使用しているドライブ(今回はCドライブのみ)を「ディスクの管理」でサイズを縮小し、コピー先より小さいサイズにした ディスクの最後尾に設定されていた回復ドライブを削除し、縮小したCドライブのパーティション以降はすべて空き領域とした 回復ドライブを削除すると、イメージバックアップからの復旧に必要となるシステム修復ディスクが作成できなくなるうことがあるので、事前に作成しておく 一旦再起動し、イメージバックアップを取得、復旧を試みた。 有償ソフトの存在はもちろん知っていましたが、なんとかお金をかけずにといろいろ行い、ディスクの読み書きを伴う作業なのでとにかく時間がかかってしまいました。が、数千円の有償ソフト使ってあっという間に解消しました。 自分の作業の時間単価を冷静に考えないとだめですね。

TL;DR DNSサーバのフォワーダをプロバイダ推奨の設定にしないと思わぬ障害に遭います 経緯 利用者より、ある取引先のWEBサイトがエラーで見られないとの連絡がありました。確認すると、Chrome,Edge,Firefox,IEのいずれもエラー。Chromeの場合はERR_SSL_PROTOCOL_ERR と表示されます。 10日ほど前にUTM(Fortigate)のFWのバージョンアップを行っていたので、まぁこれだろうと思って通信経路から外しても障害が解消しません。 SIMを搭載したiPad, iPhoneでキャリア網経由だと問題がなく、社内ネットワークに問題があることは分かりました。 ルータ直下にPCをつないでも症状は変わらず。ルータか、ONUより上流のキャリア側か、その間のLANケーブルか… WireSharkでパケットキャプチャをしてみましたが、私の技術力では原因を特定できず… ルータではフィルタリングをかけています。切り分けのため、予備機にフィルタリングを一切しない設定を実施。その配下にWindowsをつなぐのは怖いため、Linux(Lubuntu20.04)をセットアップし、IP固定、DNSは8.8.8.8としました。 Lubuntuで予備機に切り替える前に動作確認したところ症状が解消されていることを確認できました!!! そこで、もともと問題が発生してたPC(Windows10)でnslookupをDNSサーバ指定なしで実行した結果と、8.8.8.8を指定した結果が異なっていることが判明… 社内ではActive DirectoryのDNSを利用しています。DNSのキャッシュをクリアしましたが症状変わらず。フォワーダを確認したところ、かなり前にプロバイダから提供されて設定したグローバルアドレスでした。しかも現在はプロバイダを変更しています… 現在のプロバイダではDNSはルータでのPPPoEによる自動取得となっているので、フォワーダとして社内のルータを指定し、キャッシュを削除したところ症状が解消しました。 ちなみに変更前のプロバイダも現在は自動取得を推奨しているので、だいぶ前から設定が正しくなかったことが分りました。 結論として、誤ったDNS情報をもとに異なったサーバを見に行き、そのサーバはおそらく古いサーバでTLSのバージョンが古く冒頭のエラーとなったものと思われます。 サーバとの通信経路上の問題かと思ったら、通信を始める前の社内DNSの問題というオチ。改めてDNSは通信の基盤であり障害時には真っ先に調査・切り分けしないといけないことを実感しました。