このエントリーをはてなブックマークに追加

テザリングでブリッジ接続したVMWarePlayerへのSSHが切れるときの対処方法

はじめに

スマートフォンやモバイルルータのUSBテザリングやWiFiテザリングを利用したPC上でVM WarePlayerをブリッジ設定で動作させ、
TeratermなどでSSH接続をしていると、ネットワークの接続状況によってSSHが切れることがある。
対処として、TeratermからVMWarePlayerに対して直接接続するルートを作る。
接続ルートをスマホルータを通さずホストと直接やり取りする。

改善前

  • ホスト機
    • 192.168.1.10
  • 仮想OS
    • 192.168.1.11
      192.168.1.xがテザリングで割り当てられるIP

改善後(例)

  • ホスト機
    • 192.168.1.10
    • 192.168.23.1 [new]
  • 仮想OS
    • 192.168.1.11
    • 192.168.23.129 [new]

ホスト機と仮想OSを直で繋ぐNICを作ると、USBテザリングを切ったりUSB抜いたりしてもTeratermは落ちない。
USBテザ→WiFiテザに変更とかしても落ちない。

手順

Windows

ネットワーク接続で「VMWare Network Adapter VMnet1」は有効にしておくこと。
(※)これがWin側のNICになる。

確認はコマンドプロンプトから

ipconfig /all
~略~
イーサネット アダプター VMware Network Adapter VMnet1:

   接続固有の DNS サフィックス . . . . .:
   説明. . . . . . . . . . . . . . . . .: VMware Virtual Ethernet Adapter for VMnet1
   物理アドレス. . . . . . . . . . . . .: 00-50-56-C0-00-01
   DHCP 有効 . . . . . . . . . . . . . .: はい
   自動構成有効. . . . . . . . . . . . .: はい
   リンクローカル IPv6 アドレス. . . . .: fe80::f49f:8697:482d:a14e%16(優先)
   IPv4 アドレス . . . . . . . . . . . .: 192.168.23.1(優先)
   サブネット マスク . . . . . . . . . .: 255.255.255.0

でIPアドレスが出ていればOK

VMWarePlayer

下記のような構成にする。
ネットワークアダプタ1 → ブリッジ(自動) (既存のもの)
ネットワークアダプタ2 → ホストオンリー (追加するもの)

  1. ネットワークアダプタを追加する。
    1. VMWare Workstation Playerを開く
    2. [Player]->[管理]->[仮想マシン設定]を開く
    3. [ハードウェア]タブ→[追加]→[ネットワークアダプタ]→[ホストオンリー]を選択
    4. 「接続済み」「パワーオン時に接続」にチェックを入れておく

仮想OS

(※)CentOS 6.x系で説明

ホストオンリーのNICを追加すると下記が出来る。
/etc/sysconfig/network-scripts/ifcfg-eth1

  1. 最低限、下記が設定してあることを確認。
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    
    DEVICE="eth1"
    BOOTPROTO="dhcp"
    ONBOOT="yes"
    
  2. eth1のIPアドレスを確認しておく
    $ ip addr
    
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
     link/ether 00:0c:29:03:fc:7c brd ff:ff:ff:ff:ff:ff
     inet 192.168.23.129/24 brd 192.168.23.255 scope global eth1
     inet6 fe80::20c:29ff:fe03:fc7c/64 scope link
    
  3. 接続確認
    $ ping 192.168.23.1    (ゲートウェイに到達するか)
    $ ping 8.8.8.8        (外に出れるか)
    $ ping www.yahoo.co.jp(ドメイン引けるか)
    
  • ゲートウェイに到達しない場合
    ネットワーク設定を見直す。
  • 8.8.8.8に到達しない場合
    デフォゲがインターネット側のNICになってないので下記を実行。
    現在のデフォゲ確認

    $ route
    (略)
    default         192.168.~~    0.0.0.0         UG    0      0        0 eth1
    

    インターネット側のNICのでデフォゲを追加

    $ sudo route add default gw 192.168.1.1
    

    元のデフォルト設定を消す

    $ sudo route del default gw 192.168.~~
    

    default routeをeth0になっていればOK。

  • www.yahoo.co.jpにアクセスできない場合
    DNSなのでresolv.confを確認

    $ cat /etc/resolv.conf
    

    eth1がDHCPから貰ってきたDNSなら接続可能。
    とりあえず繋ぎたいなら8.8.8.8か8.8.4.4を設定しておく。恒久対応は後述。

デフォゲとDNSの設定が(NICの)再起動ごとに変わる対応

  • 最後に起動したNICのGATEWAYがデフォゲになる
  • NICがDHCPだとresolv.confも毎回書き換えが発生する

    resolv.confの固定化

    DNSが変わるので、外部のDNSを固定にしておくと楽
    DHCPでIPを取得するたびにresolv.confが書き換えられるのでNIC設定で防止
    $ vi /etc/sysconfig/network-scripts/ifcfg-eth0
    $ vi /etc/sysconfig/network-scripts/ifcfg-eth1
    
    で、一番下に追記。
    PEERDNS="no"
    
    $ vi /etc/resolv.conf
    
    一か所のきまったDNSだけ使う場合はeth0のDHCPで割り当てられるDNSでよい。
    nameserver 192.168.1.1
    
    いろんなところのWiFi使う場合は、面倒なので外部(Google)のDNSを使う。
    nameserver 8.8.4.4
    nameserver 8.8.8.8
    

    デフォゲが変わる対策

  • eth0がテザでeth1がホストオンリーだと毎回eth1のGWがデフォゲになり、変更する必要がでてくる。
    もしeth0がローカル接続用側になっていたら、70-persistent-net.rulesとifcfgファイルを書き換えてeth0とeth1の紐付けを逆にする。
    $ vi /etc/udev/rules.d/70-persisistent-net.rules
    

サスペンドから回復した場合やWiFiの接続先を変えたときに実行するscript

インターネット側のNICを ifdown -> ifupすればよい。
rootのホームディレクトリに下記のスクリプトを設置。

# インターネット側NICのみ再起動
ifdown eth0
ifup eth0
# NTP時刻合わせ
ntpdate ntp.jst.mfeed.ad.jp
# 時刻確認
date
# IPアドレス確認
ip addr | grep "global eth"
# 外部接続+DNSの確認
ping -c1 www.yahoo.co.jp | grep time

時刻合わせはvmware-toolの時刻同期を設定していたら不要。
eth1は再起動するとTeratermが落ちるのでeth0のみifdown->ifup。

SSHクライアント

Linuxサーバ上で確認したeth1のIPに対して接続する。