2019-11-05

イントラネット の速度

改めて家庭内の部屋ごとの速度測定をしました。



LAN ケーブルについては Cat5 / Cat5e はやめて、すべて Cat6 にしました。


VDSL 方式ですので、Gib 対応は実質的なメリットはないのですが、現在光ファイバーを通すための調査をしており、調査途上ですが光ファイバー化のメドがたってきていますので、遅くとも6ヶ月以内にはギガマンションまたはギガマンション・スマートタイプの契約が可能になると思われます。





ネットワーク図は次のようになっています。








間取り図は次のようになっています。





電話線は入居当初から LDK1〜 LDK2に配線済みですので、同じルートで LAN 配線化を試みましたが、CD 管と壁面内の穴とのズレがあって、通せません。


したがって、洋間2から LDK2へは WiFi による中継をおこなっています。


我が家ではここが一番のネックです。


中継機の性能を最大に引き出すために 2.4 Ghz で中継し、5 Ghz でのサービスにしています。




WiFi - AP はそれぞれ次の機種が設置されています。

 ■ 洋間1(書斎): WG1200HP3
 ■ 洋間2    : WXR-1900DHP3
 ■ LDK1    : WG1200HS
 ■ LDK2(中継): WG1200HS2
 ■ 和室2    : WRC-1167GE 



見取り図に示したようにこれらの AP の配置でどの部屋もそれなりの速度確保をしているつもりです。




速度測定は、ルーター位置の Lubuntu PC を LAN 接続で iperf3 のサーバーにし、次のパターンを測定しました。

 ■ Mac による LAN での接続測定/WiFi での接続測定
 ■ iPhone8 での WiFi 接続測定/ speedtest.net によるインターネット速度測定
 ■ P10lite での WiFi 接続測定/ speedtest.net によるインターネット速度測定







書斎(洋間1)、洋間2、3LDK(LDK1)の LAN 接続での速度は転送速度は 914 Mbps(1.06 GB/s)です。


この値は Cat6 にしたおかげです(Cat5e の場合は 830 Mbps くらいでした)。

家庭内の LAN 自体はギガを達成できています。




Mac での WiFi 接続性能がいま一つなのは、この機種が少し古くて 2012/6 購入のモデルで、11a/b/g/n は実装されていますが 11ac はサポートされていないせいでしょう。



iPhone8 では 500 Mbps を超えています。
Android 機は iPhone8 の半分以下の性能です。

機種差でしょう。


実態的には WiFi - AP は 500 Mbps を超えているということです。


理論値は 867 Mbps ですので、まぁまぁですね。


ただし、WiFi 中継区間は Mac で 100 Mbps 超、スマホでは 5、60 Mbps 程度です。 

この速度は speedtest.net によるインターネット速度もほぼ一致しています。




以前は VDSL 方式/ルーター位置で V6プラス接続により 90 Mbps 以上ありましたが、最近は DL:80 Mbps / UP:85 Mbps くらいになっていて、マンション設備側の問題なのか JPNE 問題なのかはわかりません。



10 Mbps 程度の低下ですから、体感的な差異は感じませんので、追求はしていません。




やはり WiFi 中継が隘路になっていますので、ネットワークを見直しこの区間も LAN 接続にします。











2019-11-02

NAS と NAS をサーバー化

Linkstaton を NAS として使うことと、もう1台用意して Debian サーバーにするにあたり、次のような形が一番しっくりくると考えました。



NAS:バッファローネイティブの NAS + アルファ

  ■ 共用ディスク機能
  ■ TimeMachine 機能
  ■ メディアサーバー機能(DLNA + DTCP-IP 機能)
  ■ できれば、パッケージをインストールできる環境
 

Debian サーバー:

  ■ バッファローの Linkstation の中で最適候補は、次の機種です。

     LS-VL / LS-QVL:1.6 Ghz CPU / 256 MB メモリ
     LS-XHL    :1.2 Ghz CPU / 256 MB メモリ

    USB ポートはサーバー化するにあたり必須です。


我が家には元々 LS210D0101C があります。



最初に考えた形の実現のために途中で、LS-AV1.0TL/A も加わりました。

この機種は【 殻 】だけ安価にネットで仕入れて、手持ちの 1.0 TB HDD で、LS-AV1.0TL/A に設定し直したものです。



当初は LS210D0101C と LS-AV1.0TL/A の2台で前述の形にしたいと考えました。



LS-AV1.0TL/A には NAS の3大機能のうちの TimeMachine 機能はありません。

当初はパッケージをインストールできる環境もありませんでしたので、TimeMachine 機能の組み込みもできません。


そうすると、NAS としては LS210D0101C を使うしかありません。


他方の LS-AV1.0TL/A を Debian Server にすることになるのですが、インストーラーが見つかりません。


つまり、

 ① LS210D0101C:NAS として使う(NAS の3大機能は OK )
 ② LS-AV1.0TL/A :Debian サーバー化できない

逆に、

 ① LS210D0101C:Debian サーバー化可能
 ② LS-AV1.0TL/A :NAS の3大機能のうちの TimeMachine 機能がない

という状態でどちらもうまくありません。


そこで、冒頭の LS-VL / LS-QVL / LS-XHL のいずれかを入手できないかと考えたわけです。


新たに Linkstation を入手することと並行して、

 ■ LS-AV1.0TL/A にパッケージインストール環境を何とかする
 ■ または、LS-AV1.0TL/A に Debian インストールを試みる

ということを模索したわけです。




パッケージインストール環境は ipkg を落とし込むことで実現でき、netatalk も avahi もインストールできるようですので、試してはいませんが、おそらくは TimeMachine 機能を作れると思います。



また、debootstrap も落とし込めることがわかりましたから、Debian サーバー構築もできそうなところまできました。



ところが、LS-AV1.0TL/A には肝心の USB ポートがありません。

ですので、サーバーとしてはたとえ Debian を落とせても不向きです。


そうすると、Debiab サーバーは LS210D0101C で、NAS としては TimeMachine 機能を構築して LS-AV1.0TL/A で、という組み合わせになります。







そうこうしていると、ナンと LS-XHL の【 殻 】が手に入り、当初の問題はあっけなく解消したのでした。


つまり、

 ■ LS210D0101C:ネイティブ NAS として使う(ipkg も使う)   
 ■ LS-XH500L   :Debian サーバーとして使う

ことができたわけです。



以上が Linkstation のサーバー化の顛末記です。





さて、LS-AV1.0TL/A は余りました。



どうしましょうかねぇ。











LS-XHL を入手、Deban Stretch をクリーンインストールする

LS-XHL の HDD なし筐体を格安で入手しました。



































この機種は LS210D(600Mhz/256MB)の CPU 性能のちょうど倍の性能です(1.2Ghz/256MB)。



ホントは 1.6Ghz の LS-VL の方がいいのですが、格安ではなかなか手に入れることができず、LS-XHL になりました。



ディスクは 500 GB / 2.5" HDD がありますのでこれに Debian Stretch をクリーンインストールします。



NAS として本格的に使うのではなくサーバー仕立てが目的なので、500 GB で十分です。



NAS である LS210D はオリジナル機能に付け加えて ssh ログインできるようにして、ipkg もインストールし、syslog-ng サーバー機能も持たせていますので、かなりのことはできますが、やはり Debian には劣ります。



ホントは LS-AVL の Debian 化をして、「LS210D オリジナル版  +  LS-AVL Debian 版」での運用を目論んでいましたが、LS-AVL Debian 化に目鼻が付いたところで、やめていました。



LS-AVL をサーバーにするには USB ポートが無いことと、いまひとつ性能的な見劣りがあったためです。




そこで高性能な LS-VL または LS-QVL を第一候補に、LS-XHL を次点候補で【 殻 】を探していたのです。


たまたま LS-XHL の【 殻 】を格安で手に入れることができましたので、ようやくサーバー化が進展する運びとなったわけです。


------------------------------






本題の Debian Stretch のクリーンインストールです。


インストーラーは、下記の url にありますので、Lubuntu PC からブラウザでこのサイトに行き initrd.buffalo / uImage.buffalo の2つのファイルをダウンロードしておきます。


http://ftp.jp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/buffalo/ls-xhl/



500 GB HDD を Lubuntu PC に USB=ATA ケーブルで接続して、パーティション設定とフォーマットをします。


パーティション1(/boot  ):1GB
パーティション2(/     ):+10GB
パーティッション(swap   ):+500MB
パーティション4(/home):残りすべて



パーティションを設定後の fdisk での状態は下のようになっています。







/dev/sdb1/dev/sdb2 および /dev/sdb4ext3 形式でフォーマットします。

 root@Lubuntu:/# mke2fs  -I  128  -j  /dev/sdb1
 root@Lubuntu:/# mke2fs  -j  /dev/sdb2
 root@Lubuntu:/# mke2fs  -j  /dev/sdb4


次に、/boot になる /dev/sdb1 を適当な空のディレクトリにマウントします。



さきほどダウンロードしておいた initrd.buffalo / uImage.buffalo の2つのファイルを、この /dev/sdb1 にコピー(またはムーブ)します。



コピー(またはムーブ)が終わったらマウントを解除し、HDD を Lubuntu PC から外して、LS-XHL に装着します。




そして LS-XHL の電源を入れるとインストールが開始されます。


インストールブートはすぐに終わりますので、ターミナルから ssh でログインします。
 


 root@Lubuntu:/# ssh  installer@1vv.xxx.yyy.zzz



" 1vv.xxx.yyy.zzz " は DHCP サーバーから LS-XHL に割当てられたアドレスです。

DHCP サーバーの割当てリストでアドレスを確認します。


インストーラーのユーザーID は " installer " でパスワードは " install " です。


ログインするとインストール手順が起動しますので、画面の指示にしたがってインストールします。



途中、パーティションの設定は注意します。

「手動」で各パーティションの設定を改めてします。



パーティション1:マウントポイントは /boot です。

 利用方法が「利用しない」になっているので、「ext3 ジャーナリングファイルシステム」
 とします。

 マウントポイントは「なし」になっているので「/boot」にします。

 「パーティションのセットアップを終了」を選択して設定を反映させます。



パーティション2 以下も同様にします。


パーティション2:マウントポイントは /root)です。

パーティション3:swap です。

パーティション4:ユーザー領域です。マウントポイントは /home です。

         ここでマウント設定しておくと、fstab を編集しなくて済みます。




あとは画面指示に従えば約20分程度でインストールが終わりログアウト状態になります。



改めて ssh でログインして各種の設定をします。

このとき以降のログインは、インストール途中で設定した [username] / [password] で行います。


また LS-XHL のアドレスは変わっていると思いますので、改めて DHCP サーバーの割当てリストで確認します。



最低限、以下の設定をします。


1.IP アドレスを割当てをもらうのではなく、固定で付与します。

  /ete/network/interfaces を編集し、設定を反映のために一旦リブートします。


2.改めて新しい固定アドレスでログインします。


3."su" コマンドでシングルユーザーモードにします。

  この時点では sudo はまだインストールされていません。

  " apt install sudo " でインストールします(設定をしないと有効になりませんが、
  具体手順はここでは割愛します)。


4." ifconfig "のインストール

  " ip " に置き換えろ、といいますが Mac も " ifconfig " ですのでインストールします。

   root@Lubuntu:/# apt  install  net-tools


  /sbin/ifconfig なので、ユーザーには PATH が通っておらず、プロンプト ~$ のとき
  not found になるので /home/username 配下に .bash_profile を新しく作成し、
  PATHexport 定義して source コマンドで反映させます。


5.” samba " のインストール


6." idle3ctl(パッケージ名:idle3-tools)" と
  " smartctl(パッケージ名:smartmontools " )のインストール

  これらは WD 製 HDD の IntelliPark 機能を無効化してその状態を見るために使用します。

  この IntelliPark 機能はデフォルトではオンになっており、これが著しくディスクヘッド
  の出し入れを行うためにディスクの寿命を縮める、という悪名高き機能です。


  そこで、idle3ctl コマンドでその設定状況を確認し、オンならばオフにします。

  smartctl はディスクの稼働状況(S.M.A.R.T.情報)をモニターするツールです。




以上のパッケージを入れておけばまずはサーバーとしては初期設定完了となります。




あとは、必要に応じてパッケージを追加で入れていきます。


afp 機能を入れたり、apache を入れたり、dlna を入れたり、自由です。







ファンの振動があり、結構うるさいのでファンは止めました。

止めてもディスク温度は 46 ℃ ですから、限界温度といわれる 50 ℃ 未満なので問題はないと思います。


まぁ壊れたら 256GB 程度の SSD に交換するつもりでいます。












2019-10-31

ルーターに侵入の試みは1日に約4,000件

我が家のルーターにアタックしてくる件数は1日で3,500〜4,200件くらいです。


1分当たりでは3件未満ですので、それほど多い状態ではありませんが、毎日これくらいの件数がルーターでブロックされています。



まぁ、飽きもせずにやってくるヤカラにご苦労さん、といいたくなる程度にはきているということです。


もっともほとんどは自動でキャプチャーしたパケットを解析して機械的にアタックしているだけです。



万一侵入経路が発覚した場合は容赦なく攻めてくるか、踏み台にして利用するか、あるいはほかへの攻撃のためのプログラムを仕込むか、いろいろでしょう。



このブロック数は、使う端末数などが多ければそれに比例して増えると思われます。












IPv4 アドレス枯渇問題について

欧州では本年11月に IPv4 が枯渇するようです。



これまで世界では何度もこのアドレス枯渇問題が議論され、一部には IPv6 に移行したサイトもありますが、まだまだ圧倒的に IPv4 でのサービスになっています。






国内でもプロバイダをはじめ次のような対策が講じられてきました。



1.グローバルアドレスは動的割り当て方式にする。

  これは接続時のみ割り当て、切断時はそのアドレスを「未使用」状態にして
  未使用状態のアドレスを使い回す。

  ほとんどのプロバイダはこの方式です。


2.グローバルアドレスは割り当てないで、プライベートアドレスを割り当てる。

  ソフトバンクなどはこの方式です。

  また、モバイルでもこの方式を採用しているところは年々増えています。


3.ハイブリッド形 ①(PPPoE + IPoE 方式)

  IPv6 との併用ができるようにし、IPv6 の本格的普及時に備える。

  従来の IPv4 サービスサイト(現在は圧倒的にこのタイプのサービス)には IPv4 で
  通信し、IPv6 サービス(まだ極めて少ない)には IPv6 でできるようにする。


4.ハイブリッド形 ②(トンネル方式)

  IPv4 over IPv6 といわれているもので、どちらかというと PPPoE の混雑時の速度
  低下対策としてサービスされてきましたが、3項と似ています。


  速度低下はフレッツネクスト網を PPPoE で使う場合に発生します。


  3項との違いは IPv4 通信を PPPoE ではなく IPv6 のパケット内に入れて、
  ネットワーク・イネイブラーといわれる事業者の設備で IPv4 または IPv6 で接続
  サービスする方式です。

  ただし、ポートの使い方が2項同様、制約を受けますので自局がサービスする場合
  などに影響を受けます。



以上のような対策が講じられてきても IPv4 アドレス枯渇問題は避けようがなく、いつ枯渇するかは時間の問題になっています。



今般、欧州で近々おとずれる枯渇問題は早晩世界中の地域で発生します。


日本とて例外ではありません。


一般ユーザーがどうこうできる問題ではありません。



ただ、3項や4項の対応をすることによって、来たるべき事態に備えることはできます。


現在できているサービスが制約を受けるかも知れませんが、PPPoE との併用で切り抜けるしかありません。



モバイルも IPv4 と IPv6 の両方に対応したデバイスが主流になってきており、意識せずとも3項の状態になってきています。

 (古い機種はこの対応ができないものもまだ少なくありません)。



WiFi スポットはほとんどが「プライベートアドレス割り当て」です。






抜本的にはすべてのサービスサイトが IPv6 に移行し、ユーザーも IPv6 でサービスが受けられるようにすることでしか枯渇問題は解決しないのです。





逆にすべてが IPv6 に移行すると、IPv4 アドレスは一気に未使用状態になりますから、新たな活用方法が議論されるかも知れません。



管理人の場合、そのような時期までこの世にいないと思いますから、余計な心配はしませんが。