普通2つのNICと言えば192.168.1.0のネットワークと192.168.2.0のネットワークを使い分けるようなパターンが多い。
しかし今回はWindows10マシンから2つのNICで同じ192.168.1.0のネットワークに接続する。この項目はリンクアグリゲーション(Link Aggregation)やEtherChannel IEEE802.3ad ポートトランキングではありません。
2019-07-29
結論
インターフェイスメトリックの変更
route delete 0.0.0.0 if 15
NetBIOSを止める
mDNSを止める
ネットワークの混雑を避ける
理由は昼の時間に始まるバックアップの嵐を抜けて、安定した外部との通信(もはや死語のネットサーフィン)をしたいから。
実はよくネットワークの不調とかで呼び出されるけど、二つの端末だけがバックアップに異常に時間が掛かっていることが分かっている。この二つのノートパソコンはWiｰFi経由でNASにつながっているので、Wi-FIを使わなければ、快適に外部につながるはずだ。
バックアップファイルソフトももちろん丸コピしているわけではなく、更新日付を確認し差異のあったファイルのみ保存しているのだが、こに2台のノートに関してはファイルが多すぎてファイルの検証しているだけで時間が掛かっていると思われる。
ちなみに多すぎるファイルの内容は90年代からの整理されていない仕事のファイルに加え、今やないはずのiPodの音楽ファイル等マルチメディアファイルから始まり、最近ではちゃんとお金を払ってダウンロードした熟女系のエロ動画と海外出張の前の指名用下調べ画像である。特に義母と息子系には事欠かない。
また、No.2に至ってはわいせつ事件で有名な私立大学出身なだけあり、複数の不倫相手との思い出がExcelファイルに纏められている。
とにかく、ネットワーク管理者でもないパソコン相談員には原因が分かっていても指摘でない立場なのだ。
普段使っているPCをWi-Fiとイーサネットの二つのネットに同時に接続してみる。
さて、どうなるか。Windows10が自動で判別して片方のネットワークしか使わなくなる。
何故ならそれが一番安定しているからである。友達のようになった route print コマンドで確認してみる。抜粋
>route print
============================
インターフェイス一覧
15...b0 c7 45 ab 25 1b ......BUFFALO WLI-UC-GNM Wireless LAN Adapter
1...........................Software Loopback Interface 1
8...d4 be d9 1a 6d 37 ......Realtek PCIe GBE Family Controller
=============================
IPv4 ルート テーブル
===========================
アクティブ ルート:
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイス メトリック
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.42 45
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.38 60安定している接続というけれど、不安定要素があってゲートウェイが2行に渡って設定されている。ここは流石のWindows10でもどちらに絞るかは出来なかった模様。
ここでWANにつながるときにどちらのネットが選択されるかがメトリックで決まる。ipconfigしないと分からないが、インターフェイス192.168.1.42がRealtek 100Mbps Ether で インターフェイス192.168.1.38 が Buffalo Wifiである。
Windows10が8.8.4.4のパケットをどのインターフェイスを使って送ろうかと悩んだ時、この表のメトリックの小さい値のポートに送ることを知る。
またWindows10が192.168.1.110等プライベートアドレスを送ろうとしたときは以下の続きの表を見て考える。
192.168.1.0 255.255.255.0 リンク上 192.168.1.38 406
192.168.1.0 255.255.255.0 リンク上 192.168.1.42 257
192.168.1.255 255.255.255.255 リンク上 192.168.1.38 406
192.168.1.255 255.255.255.255 リンク上 192.168.1.42 257
224.0.0.0 240.0.0.0 リンク上 127.0.0.1 331
224.0.0.0 240.0.0.0 リンク上 192.168.1.38 406
224.0.0.0 240.0.0.0 リンク上 192.168.1.42 257
255.255.255.255 255.255.255.255 リンク上 127.0.0.1 331
255.255.255.255 255.255.255.255 リンク上 192.168.1.38 406
255.255.255.255 255.255.255.255 リンク上 192.168.1.42 257この表のメトリックの小さいほうのポートつまり192.168.1.42のEthenetに送信されることになる。
つまり、全てのやり取りするパケットが有線LANに流れる
実はWi-fiポートもやり取りしたいパケットだけでなくNetBIOSやmDNS等ネットワーク制御系のパケットはやり取りされるので、全く音沙汰が無くなるわけではない。
方針
| Wi-Fi Buffalo 192.168.1.38 | プライベート通信全てと制御系のパケット |
| Ether Realtek 192.168.1.42 | WANのすべて |
制御系のパケットと書いたけど、サービスではARP LLNMR mDNS NBNS NetBIOS LANMAN SMB BROWER が該当する。
WANの全てとはいえDNSは内部にも外部にも該当する。
Wi-Fiのネットワークプライオリティを上げる
失敗談
当初にroting tableからWi-Fiの0.0.0.0を削除し、Etherの192.168.1.0等プライベートアドレスを削除すればいいと考えていた。
所がこれでは制御系のパケットが突然行き場を失い、内部ネットワークにつながったり繋がらなくなってりと不安定を極めた。
原因を探ろうにもあるとき突然つながるので再現も出来ない。arp -d * nbtstat -R などでキャッシュをクリアしてもしきれない。
netstat -nbv などで様子を見ていても、sessionを切ってメトリックを変えてもセッションが復活してくる。元のインターフェイスで。
Wiresharkなどで見ていると多分電源が入ってから今までEtherで通信していて突然切れて変更しても、相手側が覚えていてインターフェイスを叩いているようだ。しかも手前のWindows10も前につながったことを思い出してこの悪しきパケットを迎え入れているようだ。犯人は身内。
そのためこの方法は諦めた。
Wi-Fiに全てを任せてみる
先ずは全てのパケットをWi-Fiに出させる。ネットワークの接続 – Wi-Fi – プロパティ – インターネット プロトコル バージョン(TCP/IPv4) を選択。
プロパティを出す。その中の全般タブ – 詳細設定(V)…
そして下記のように自動メトリックを外し、インターフェイスメトリックを1とする。
メトリックは数字が少ないほうが優先だ。つまり最優先にする。計画では制御系のパケットも全てW-Fiに出てくるはずだ。
command line 大好きな私が、GUIで変更しているのには理由がある。こちらのほうが操作が簡単なのだ。
Windows10の自動メトリックには素晴らしいと思うのだけど、それゆえ自由が無い。Windows10は頭が良いため、IFのリンクしている速度を把握している。その為、個人的都合でcommand line から遅いWi-Fiネットワークのメトリックを小さくしても順番通りしないと意地でもEtherを優先させようとするのである。
1.自動メトリックを外して 2. インターフェイスメトリックを変更するというのが同時に出来るのはGUIの強みである。
Wi-Fiに全てのパケットが流れる
ルートテーブルはこうなっている。
===========================
インターフェイス一覧
15...b0 c7 45 ab 25 1b ......BUFFALO WLI-UC-GNM Wireless LAN Adapter
1...........................Software Loopback Interface 1
8...d4 be d9 1a 6d 37 ......Realtek PCIe GBE Family Controller
IPv4 ルート テーブル
===========================
アクティブ ルート:
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイス メトリック
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.42 406
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.38 2
127.0.0.0 255.0.0.0 リンク上 127.0.0.1 331
127.0.0.1 255.255.255.255 リンク上 127.0.0.1 331
127.255.255.255 255.255.255.255 リンク上 127.0.0.1 331
192.168.1.0 255.255.255.0 リンク上 192.168.1.42 406
192.168.1.0 255.255.255.0 リンク上 192.168.1.38 257
192.168.1.38 255.255.255.255 リンク上 192.168.1.38 257
192.168.1.42 255.255.255.255 リンク上 192.168.1.42 406
192.168.1.255 255.255.255.255 リンク上 192.168.1.42 406
192.168.1.255 255.255.255.255 リンク上 192.168.1.38 257
224.0.0.0 240.0.0.0 リンク上 127.0.0.1 331
224.0.0.0 240.0.0.0 リンク上 192.168.1.42 406
224.0.0.0 240.0.0.0 リンク上 192.168.1.38 257
255.255.255.255 255.255.255.255 リンク上 127.0.0.1 331
255.255.255.255 255.255.255.255 リンク上 192.168.1.42 406
255.255.255.255 255.255.255.255 リンク上 192.168.1.38 257
==============================
固定ルート:
ネットワーク アドレス ネットマスク ゲートウェイ アドレス メトリック
0.0.0.0 0.0.0.0 192.168.1.1 既定
===============================
メトリックがWi-Fiに優先され、狙い通り起動時からWi-Fiに全てのパケットが流れ始めた。
WANのパケットはEtherから流れてほしい
このままでは遅いインターネットとなる。いろいろな方法が思いつくが、今のところ成功したのはこのルーティングテーブルから外向けのWi-Fiの項目を削除しただけである。
route delete 0.0.0.0 if 15尚 route -p add 等と -p オプションを付けると再起動後も設定が維持されるとあるけど、deleteに関しては維持されないので起動後毎度行う必要がある。
色々Windows10のルーティングテーブルをいじってきた中で感じたのは、何行も設定すると正しいと思えるルーティングテーブルでも期待通り動作しないということである。
気になるのは192.168.1.0等ローカルアドレスが優先順位が低いもののEtherに設定されていることが気になるが、気にして何行も
route delete 192.168.1.0 if 8
route delete 192.168.1.42 if 8
route delete 192.168.1.255 if 8
route delete 224.0.0.0 if 8
route delete 255.255.255.255 if 8とすると、Windowsは期待外れの動作を繰り返すようになる。
つまり思い出したかのようなEtherでの通信や、NetBIOSのパケットの行方不明。それによるネットワークドライブが繋がったり繋がらなかったり。
確かに完ぺきではないが、Wiresharkで監視している限りプライベートなパケットは流れてこない。
制御系のパケットはWAN側から漏れている
これについては詳しくは別に記述したい。
SMB/CIFS等のパケットは流れなくなっているが、そもそもARPやmDNS等の通知するパケットは流れている。
しかも受け取った側は同じPCで二つアドレスがあって片方はEtherだと当然Etherを優先して送ってくる。
送ってはきたものの、手前のPCではrouting table に記載されていないのでWi-fiで送ったり、WindowsがEtherの裏口から迎え入れたりしている。
果てはパケットが行方不明に。
とにかくEtherの存在を他のPCに知られたくない。
WindowsやMac等PCに関してはとにかく簡便に使えるようにと進化してきた。Windows95の時代の様に殆どをテプラでIPアドレスをPCに張り付けてで管理していたのと違って、今のは有線LANならブスっとさすだけでインターネットにつながったりする時代になった。
その裏にはDHCPを始め色々な努力があるのだけど、NetBIOSとかいろいろあって今はNBNS(NetBIOS)とmDNSが管理している。ようだ。
どちらも定期的に自分のPCのコンピュータ名をブロードキャストして宣伝。そして他のコンピュータからの問い合わせに自身の情報を回答している。
ネットあるあるではWindowsのサービスのTCP/IP NetBIOS Helperを止めている例が多い。(このプロセスは普通に止めても蘇ってくるので注意)
今回の用途では、内部ネットには回答してもらわないといけないので下記に示す方法が完ぺきとは言えないことをご了承いただきたい。
内部ネットワークにつながっているのは大抵一つのインターフェイスである。今回は192.168.1.38 の if 15 Buffalo Wi-Fiである。話の便宜上一つのインターフェイスの話になるが、複数の内部ネットワークに複数インターフェイスで接続されている場合該当内部ネットワーク全部のインターフェイスと外部のインターフェイスに読み替えてほしい。
このネットワーク接続画面は何の加工もしていな正直な画像である。6個のインターフェイスがあり、Npcap Loopbackはwireshark用。外部ネットワーク用VPN。内部用Wi-Fi。WAN用イーサネット。VMware用 イーサネット2と4 である。
内部ネットワークだけNBNS(NetBIOS)を有効にする
NetBIOSはWiｰFi内部ネットワークには必要だが他の外部ネットワークには不要である。
外部ネットワーク接続 – Wi-Fi – プロパティ – インターネット プロトコル バージョン(TCP/IPv4) を選択
プロパティを出す。その中の全般タブ – 詳細設定(V)…
WINSタブのNetBIOS設定
ここでNetBIOSを無効にする。
これを内部ネットワーク以外の外部ネットワークインターフェースに全て個々に実行する。
おまけとして不要な問い合わせが無くなるので、コンピュータ名での接続が速くなる。
外部に公開するようなサーバー用途などはNetBIOSを止めることが普通であり、このような情報はよくある。細かいことが気になるようなら検索されたい。
内部ネットワーク用Wi-Fiは規定値か「有効」を設定しておく。コンピュータ名によるアドレス解決をしないのであれば無効にしてしまっても良い。その時はサービスごと止めてしまうのが良いと思う。
内部ネットワークだけmDNSを有効にする
Apple zero configuration の流れをくむmDNSだが、Windows10でもトラブルも多いと聞く。
そのせいで巷にはbonjourをインストールしてmDNSを使いこなしているところもあるかもしれないが、今回Bonjourの出すmDNSが止まるかどうかまで検証していない。
実はIPv6を止めるとWindowsのmDNSは止まる。
かなり裏技的な方法だが、IPv4のmDNSも実際止まっている。但し、バグである可能性もあるので今後のバージョンアップに伴いこの方法では止まらなくなるかもしれない。
外部ネットワーク接続 – Wi-Fi – プロパティ
インターネット プロトコル バージョン(TCP/IPv6) のチェックを外す。
これで、mDNSの情報が外部ネットワークに流れなくなる。
但し外部ネットワークでIPv6が使えなくなるので、DS-LiteでNGNやっている人は使えないと思う。
自分としてはIPv4だけの方がwireshark等で監視しやすいので好みだが。
内部ネットワークWi-Fiにはガンガン流れることを確認している。
常にWiresharkで監視
最後に以上の設定を行ったけど、うまくいかなかったと言うのは受け付けない。own riskで。
結局のところパケットを監視して異常があれば対策しなくてはならない。その覚悟の無い方はやめてほしい。
最後に役立つかもしれないコマンド集を
netstat -nbv
nbtstat -c
nbtstat -R
nbtstat -a
nbtstat -n
arp -d *
arp -a
net use
ipconfig /displaydns
ipconfig /flushdns
nbtstat -a TARGET
本業設計!! 