WiFi中継器の先につながる有線デバイス
WiFiルータの更新で、WEX-733Dを再利用した。
WiFi-router – – – WEX733D=(ether)-REGZA+Raspberry-Pi
当初、中継器WEX 733D の先につながる TV,ラズパイが最初は繋がっていたけど、接続が切れる。確認をしてみると、ルータ配下から中継器の先のデバイスは、どれも中継器のMACアドレスに見える。このため、我が家でのDHCPでMACアドレスに紐づけた固定アドレスを割り振る方式では、中継器でアドレスがすり替えられているために、MACアドレスが DHCP サーバ側で正しく把握できない。このため、正しくIPアドレスが取れない。
しかたがないので、中継器の先の有線デバイスは固定IPアドレスを割り振る。中継器をWiFiアダプターとして使う場合、DHCPで動的アドレスを振ったとしても、IPアドレスは変な状態になるだろうなぁ。固定IPアドレスにしないかぎりは、使い物にならないだろうなぁ。
WEX733DのMACアドレスが変化
メッシュネットワークも一通り設定が終わり、安定して使えるように…と思ったら、1F居間と2FをつなぐWEX733Dから返答がない。(icingaを使って主要なデバイスの生死監視をしている)
確かめてみると、親機に設定した際のMACアドレスと、違ったMACアドレスになっている。このため、こちらが想定しているWEX733DのIPアドレスと異なるため、ping などが取れなかった。
WEX733D-前 60:xx:xx:29:xx:xx WEX733D-後 62:xx:xx:28:xx:xx
この症状は、他の Buffalo のルータでも確認していて、WZR-1166DHP2では、
WZR1166DHP2 B0:xx:xx:xx:xx:xx WZR1166DHP2 B2:xx:xx:xx:xx:xx
のような値が取れていた。今回 WEX733D には、DHCP の fixed-address の設定を使っているため、これを正しく登録しておかないと、IPアドレスが変化してしまう。
今回のMACアドレスを確認すると、第1オクテットのBit1は、グローバルアドレスとローカルアドレスを区別するビットみたい。
そこで、60…と62…では、それぞれ違うIPアドレスを対応づけて、死活管理で以下のように設定した。
確認用の script では、2つの check_ping を || で連結し、本来のIPアドレスで返答がなければ、予備のIPアドレスの返答を確認することとした。
define command{ command_name check_host_alive_multi command_line /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w 5000,100% -c 5000,100% -p 1 || /usr/lib/nagios/plugins/check_ping -H '$ARG1$' -w 5000,100% -c 5000,100% -p 1 } define host{ use generic-host host_name wex733d alias wex733d address 192.168.xx.xx check_command check_host_alive_multi!192.168.xx.yy }
WRM-D2133HPとWEX733D
自宅のWiFi環境の改善ということで、5年ぶりにルータを WRM-D2133HPに更新。
メッシュネット型なので、同梱のWiFi中継器WEM-1266によって、通信エリアが広がって、端末の移動に合わせて電波を調整してくれるので、家の中を移動しながらでもネット接続が切れにくい。SSID も 1つしかないので設定も解りやすい。
今回更新したのは、2Fの居間と1Fをつなぐ EthernetとPLCを使った接続が故障したのが発端。そこで1Fとの接続も以前購入して使い物にならなかったWiFi中継器のWEX733Dを発掘させた。不安定の原因と思われる中継器がAPとなる機能は無効化させ、元々あったPLCと差し替え。
今の所、ネットワークは安定動作しているかな。
新しいルータは、L2TP の VPN 機能も内蔵しており、VPNのために運用していた EdgeRouter-ERX が不要になりそう。
メッシュネットの導入を検討
先日から、子供の部屋にWiFiが使えるように1Fに設置していたアクセスポイントが調子が悪いようで撤去した。
でも、同じ1F居間のTVやらRaspberry-Piやらがネットワークにつながらなくなり、どうも1FまでのEthernetか、その先のPLC(電力線経由ネットワーク)が壊れたようで、その先のWiFi-AP,TV,RPiが相倒れとなった様子。
かといって、PLCは元々通信速度もあんまり出ないし、壊れたとしても再購入も疑問。
WiFi環境の見直し
WiFi-APで自宅内どこでもWiFiが使えるようにしていたけど、再接続の性能も悪いし、ルータの更新を検討した。今までにも、WEX-733D とかを試したけど、接続がよく切れるし使用を断念していた。そこで、専用にメッシュネットWiFiルータとして売られている製品を検討してみた。
Buffalo で最新のものは、WTR-M2133HP/E2S だけど、値段も高い割に Amazon のレビューではうまく動いていない報告が目立つ。そこで値段も手ごろで、Amazon レビューでもトラブルの報告の少ない WRM-D2133HP/E1S を選択。
予想される問題
問題点としては WRM-D2133HP は、ルータのLANポートが3ポートに減る。現在のルータには、Linuxサーバ,メインWindows機, VPNルータ, 8ポートHUBと繋がっているので、ポート不足になるはず。ひとまずはVPNルータの空きポートを使うかな…。
たぶん壊れた1Fにつながるネットワークは、なんとか復活させたい。今の所、メッシュネットでつながるようになるなら、WEX-733Dを復活させようと検討中。ただし、中継機能を使うとネットが切れやすくなるような症状が予想されるので、無線LANアダプターとして使い、中継器のWiFi親機機能を無効化したほうがいいだろうな。
VPNルータの気絶で、自宅内ネットワーク総倒れ
今朝置きたら、”OK, Google”と呼びかけると、”インターネットに接続されていない”と悲鳴をあげてくれた。色々調べると、ネットワークが機能していない。我が家はDHCPやDNSを自宅サーバで運用しているから、サーバと繋がらないだけで、全機能麻痺。
状況分析
システムがトラブって、PCから ping を打つけど、どれにも繋がらない。このため、WiFiルータ(Buffalo-WZR-1166DHP2)の故障を想定した。
しかし、手持ちの代替え用WiFiルータにServer,PCとつなぐと簡単に復旧。これでWiFiルータ故障決定かと、HUB,VPNルータ(EdgeRouter-X)とつなげたら、またネットワークが落ちてしまった。そこで、HUBだけつなげたら…VPNルータだけつなげたら…と実験したら、VPNルータがつながるとネットワークが落ちることが判明。
VPNルータの故障かと思い、ひとまず電源リセットを行ったら、あっさり復旧。原因がWiFiルータでもないため、故障を疑ったWiFiルータをもとに戻したら、これまた正常動作。ということで、原因はVPNルータが気絶して、同一セグメントの機器を巻き込むような異常パケットを垂れ流していたのだろう…という結論に至る。
EdgeRouter-X のファームウェアを 1.10.9 に戻す/2019-05-10
今回の EdgeRouter-X のトラブルだけど、前回ファーム更新で、2.0.1 があったので、適用したけどその後すぐに消えてしまった。
たぶん、ファームが不安定だったのかと思われる。ということで、不安定の原因も考えられるので、1.10.9 に戻した。
ER-X EdgeOS v2.0.1
EdgeRouter-X の新しいファームウェアが、2019/3/29 にリリースされたみたいということで、早速インストール。特にどんな機能が増えたのか、よくわからないけれど無事更新完了。
ただ、更新が終わって改めて、何が新しくなったのかとファームウェアのページを見たら、v2.0.1の情報が消えている。どーゆーことぉ?
he.net を使った IPv6 トンネル
IPv6 の導入の実験として、IPv6トンネルを無料で利用できる he.net を使って設定してみた。
現在、自宅サーバ自体を IPv6 対応することはできたけど、サーバ配下のパソコンもこのトンネルを使うようにできていないので、まだ目標の半分。
he.netへの登録
Hurricane Electric(he.net)の接続方法を紹介しているサイトの記事を見ながら、he.net に利用者登録をして、トンネルの割り当てを受ける。
トンネル起動の設定
he.netのサイトで、上記の登録が終わると、”Example of Configuration”のタブで、OSを選べば、接続するための設定ファイルのサンプルが表示される。
ただ、Debian/Ubuntu を選ぶと、/etc/network/interfaces 用の設定が示された。自宅サーバは systemd を使っているので、このままでは使えない。ほかのサイトで調べて、最終的に以下に落ち着いた。
(( /etc/systemd/system/he-ipv6.service )) [Unit] Description=he.net IPv6 tunnel After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/ip tunnel add he-ipv6 mode sit remote 74.82.xx.xx local 192.168.yy.yy ttl 255 ExecStart=/bin/ip link set he-ipv6 up mtu 1480 ExecStartPost=/bin/sleep 0.3 ; /bin/ip -6 route add ::/0 dev he-ipv6 Execstop=-/bin/ip -6 route del ::/0 dev he-ipv6 ExecStop=/bin/ip link set he-ipv6 down ExecStop=/bin/ip tunnel del he-ipv6 [Install] WantedBy=multi-user.target
systemd の サービス として設定するために、he-ipv6.service ファイルを作成する。
systemd ではサービスの処理を起動/停止するためのコマンドは、ExecStart / ExecStop に記載する。
“ip tunnel add” の remote 欄は、割り当てられたhe.net のIPアドレス、localには自分のグローバルアドレスを指定する。ただし、自宅サイトはルータ内にサーバがあるので、ポートフォワードされたプライベートのアドレスを指定する。
トンネル開通後のIPv6のデフォルトゲートウェイを設定する “ip -6 route add” の実行は、少し間を置かないと失敗するようなので、若干の sleep を挟んだ。ExecStart 行は、通常1行1コマンドしか使えないが、ExecStartPost は、複数コマンドが書けるので、こういう時には便利。
ExecStop でのデフォルトゲートウェイ削除の処理 “ip -6 route del ::/0″では、前述のsleepが無い場合、エラーが出ることがあるので、コマンドの先頭に”-“をつけエラーで止まらないようにしておいた。
# サービスの登録 $ sudo systemctl enable he-ipv6.service # サービスの起動 $ sudo systemctl start he-ipv6.service # サービスの停止 $ sudo systemctl stop he-ipv6.service
ただし、後にも述べるように常時 IPv6 化は現状では問題があるので、systemctl enable は行わないでおく。
RAの設定(ルーティング広告)
ルータ周りの他のパソコンがグローバルなIPv6アドレスが割り当てられるように、RAの設定を行う。実は、リンクローカル”fe80::”での自宅内IPv6ネットワークの運用では、グローバルIPv6が無いので RA が不要だけど、IPv6の DNS をアナウンスが必要なので、今までは DHCPv6 を使っていた。でも、radvd.conf の設定を調べると、アナウンスするプレフィックス設定の欄を “prefix ::/64” と記載すれば、”fe80::”のリンクローカルはアナウンスされないようなので、radvd に変更。”RDNSS”の欄で、自宅内 IPv6 対応なDNSサーバを指定することで、IPv6経由で名前解決をできるようにしておく。
interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; # 非リンクローカルなアドレスだけアナウンス prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; # DNSは、リンクローカルなDNSサーバをアナウンス RDNSS fe80::xxxx:xxxx:xxxx:xxxx { AdvRDNSSLifetime 30; }; DNSSL example.jp { AdvDNSSLLifetime 30; }; };
この段階で、IPv6 のファイアウォールの設定(ferm)の設定が間違っているのが判明したので、別途修正。
常時IPv6対外接続は問題あり
よく、IPv6 を使うとネット通信速度が速くなると言われているけど、現時点では IPv6 利用者が少ないので、上流が詰まらないだけ。今回のような、IPv4 を使ったIPv6トンネリングでは、IPv4 以上には速くなるはずもないし、IPv6 も無料でサービスを提供している he.net では、上流の輻輳もあるだろうし高速通信も期待できない。
このため、上記の IPv6 接続は単なる自分の勉強用で、必要な時だけ”systemctl start he-ipv6.service”でトンネル接続させる予定。。当面、常時 IPv6 運用はしないだろう。
WiFi 2.4Gのチャンネル変更
最近、子供からWiFiがよく切れるとのクレーム。調べてみたら、お隣さんのWiFiのチャンネルと被っているみたい。
2.4G [Hz] / 11n,11g,11b
何度かスキャンをかけると、2.4GHz帯のチャンネル選択は自動にしておいた状態で、自宅の1F用,2F用が3ch,11chを使っていて、しかもお隣さんも同じものを使ってる。倍速モードの拡張チャンネルも5chとか使われていて、これもかぶってる。
そこで、3ch,5ch,11chを避けるために固定チャンネルの設定を探し、お隣さんに近い WiFi-AP を 13ch(拡張9ch)、自室 WiFi-AP を 7ch(拡張11ch) にしてみた。
WiFi 場所 | メインch | 拡張ch |
---|---|---|
お隣近接側AP | 13ch | 9ch |
自室AP | 7ch | 11ch |
5G [Hz] / 11ac,11n,11a
5GHz の方は、電波が遮蔽物越しでは飛ばないようで、あんまりお隣さんが見えない。ということで、そのまま自動選択にしておこう。