Aterm WG1200HP イーサネットコンバータ設定方法など_02
前記事からの続きです。問題点や設定時の留意点など。
まず、前記事で言及したこいつの設定ページのIPアドレスの変更について。
これはどうやら
筆者のゲートウェイであるルータのDHCPサーバ機能がオンであり
こいつの「DHCPクライアント機能」なるものが初期値でオンになっていることが
原因であるようです。
コンバータモードにおいての「DHCPクライアント機能」が
何のために使うものなのかよくわからなかったので軽く調べてみました。
一部、他機能はモードや設定次第でブランクになる中でそのままだったので。
直接、こいつのマニュアルからは見つからなかったので別製品から。
DHCPクライアント機能(初期値：使用する)
「使用する」のチェックボックスにチェックすると、無線LANアクセスポイント(親機)のWAN側がDHCPクライアントとして動作するようになります。通常、接続網のサーバからIPアドレスなどが自動取得されます。この項目だけチェックすると無線LANアクセスポイント(親機)が電源ONのときに自動取得を行います。
http://www.aterm.jp/function/guide7/web-data/type2_70/main/8w_m3.html
どうやら、ローカルルータとして使用する場合に
よりWAN側にあるルータに対して、ISPからIPアドレスが割り振られるような環境で
IPアドレスの自動取得を促すようなものらしいです。間違ってたらごめんなさい。
まず、イーサネットコンバータとしてはIPアドレスを持ってなくてよいのですが
本記事の目的である、こいつの設定ページへのアクセスのためには必要です。
このIPアドレス自体は、設定を行うPCからのみ見えればよいので
パブリックな範囲以外であれば、完全に任意です。
ただ、こいつ自体もインターネットへ接続、LANに参加できると
時刻の設定、ファームウェアの更新などが行えるため便利です。
ーーーなので結論としては
ゲートウェイであるルータサイドで厳格にLAN内クライアント管理をしており
DHCPを通してしか通信ができないような運用をしている場合を除けば、
こいつのIPアドレスはLAN内セグメントの範囲で任意で固定して
「DHCPクライアント機能」はオフにしておく、がベストなのかなと思います。
ということで、設定方法の続き
6. 変更されたIPアドレスを特定する。
筆者の場合はルータのDHCPテーブルからわかりましたが
そうでない場合は別の方法で。(総当たり以外の方法を模索中*1、いつか別記事で。)
最悪再度電源の抜き差しを行って、192.168.1.245に戻しましょう。
7. こいつの設定画面、左上の「詳細モードへ切り替え」で詳細モードへ。
左のメニューにプルダウンでいくつか項目が追加されます。
8. 「基本設定」内の「詳細設定」へ。
下のような画面が出てきます。
ここの「DHCPクライアント機能」がオンになっていると思うので、オフへ。
そして、こいつへアクセスするための任意のIPアドレスを割り振っておきましょう。
ゲートウェイその他なども自動で設定されていると思うので確認を。
こいつ自身はルータのAPだけ理解してくれればいいですが
インターネットへの情報も渡しておいた方が何かと便利です。
「送信元検証機能」もオンになっていますが、これもオフに。
偽装が疑われたり、挙動の怪しい不正な相手に対するセキュリティですが
基準がよくわからないので、イーサネットコンバータには不要かと思います。
9. 「メンテナンス」項目から各種管理設定
パスワードの設定やファームウェアの確認など。
設定ファイルも作っておくと便利です。
以上です。ここまでやっておけば、もう許してもらえるでしょう。
こいつの設定に関してはこれで大体全部です。
その他環境による留意点
筆者は、IODATAのWN-AC1167DGRというルータを使っています。
きちんと同系列AtermシリーズやNEC製品で揃えれば大丈夫かも知れませんが
筆者の環境ではステルスSSID設定を行うと、上手くいきませんでした。
セキュリティ的にも、どの道クライアント中からSSIDはばら撒かれるので
そこまで大した差はないと考えます。
- 親機であるルータへのアクセス手段を別に確保しておく
ノートPCなどで、直接有線でルータと接続できるのがベストですが
USBタイプなどの無線LANクライアントなどでもいいです。
接続が上手くいかない場合や、インターネットと繋がらない場合など
何がネックなのか調べたり、設定を確認するのに必要です。
今時であればスマホでも十分かと思います。
あの小さい画面でルータ設定をピタピタ弄るのが大変でしたが・・・。
やっと終わった・・・通常の使用であればもうここまでやれば大丈夫でしょう。
しかし、まだ気になった点はいくつかあるので、次の記事に。
*1:
以下、模索中の余談です
arpなどを使うのが正当な方法なのかな、と思っていましたが
あれは一度でも通信した相手との対応テーブルなので、今回は違いますね・・・。
ならばrarpは、と思いましたが、あれは自身のIPアドレスを要求するもので
かつ、rarpサーバに相当するものも必要なのでこれも違う・・・。
同一セグメント内どころか、直接有線で接続されており
そいつのmacアドレスは分かってるけどIPアドレスがわからない場合って
どうすればというか、そもそもそんな状況があるのだろうかというか。
レイヤー２まで確立してるのであれば、通信は一応成立する訳だし・・・。
現状筆者が思いつく限りでは
・(入っているなら)nmapあたりでそれを代替する。
・何かツールを使う(よっぽどスマートにやらない限りこれも多分総当たりに近い)
正直丁度いい解決案は思い当たりません。ごめんなさい。
