外出先からVPNで急に家庭内LANのNASが表示されなくなりまして困ってます。
ルーター iO-DATA WN-AC1600DGR
PC MACBOOK PRO 2012 Mavericks
MACBOOK AIR 2012
VPN（PPTP）はWN-AC1600DGRで設定しています。ちなみにiPhone5sではLTEでVPN（PPTP）を使って家庭内のNASにアクセス出来ています。念の為VPNとルーターの画像を貼り付けます。
試したことはMAC側VPNの再設定とルーターの初期化です。それとpingとSSHは繋がることを確認しました。
2台とも同じぐらいのタイミングで繋がらなくなったのでどうなっているやら？
画像でも分かる通りVPNに接続は出来ています。LAN内のNASにアクセス出来なくて困っているのです。
宜しくお願い致します。
MacBook Pro (15-inch Mid 2012), OS X Mavericks (10.9.5)
> NAS4FREEというよりはルーター iO-DATA WN-AC1600DGRの問題かもしれません
そうだとすると、ルータのログも見た方が良いかも。
ルータのVPNに関するキャパが小さくて、スレッドがちょっと増加すると処理できなくなるとか。もしこれが原因なら、ルータをリセットして、接続を１台だけにすれば繋がるかも。
ファイアウォールやセキュリティソフトが影響しているということはないですよね。
LAN内の接続ができているということなら関係無いとは思いますが、ここまで一度も話がでていないので念の為ということで確認させていただきました。
それで接続に関してですが、ターミナルからtelnetを使って接続できますか？
接続できればSMBのプロトコルにおける問題の可能性が高くなり、ネットワークの問題はとりあえず考えなくて良くなりますし、接続できなければSMBではなくMacでのVPNを介した利用でのネットワークの問題となり、原因の絞り込みも少しは容易になるかもしれません。
以下、手元のMac/El Captanでの実行結果です。
（nas1はNASのホスト名、445がSMBが使用するポート番号、下線部が入力、^] はcontrol＋］、IPアドレスが同じなのは偶々です）
$ telnet nas1 445
Trying 192.168.0.9...
Connected to nas1.tm.private.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
$
はに様
logを確認していますが、ルーター、NAS4freeともに今のところ特に何もないような感じがします。ただしlogを確認するのが不慣れなため時間がかかりそうなので引き続き覗いてみようと思っています。
ToMi様
ファイアウォールとセキュリティソフトは停止させて確認しています。
教えて頂いたtelnetの件ですが、VPN接続ですと「nodename nor servname provided, or not known」と表示されました。
NASと同じLAN内でtelnetを試した所
Trying 192.168.0.9...
Connected to xxxyyyzzz
Escape character is '^]'.
^]
telnet> quit
Connection closed.
とtelnetが接続できたのでコマンド入力間違いはなさそうです。
「nodename nor servname provided, or not known」が何を意味しているか分かりませんのでネットで調べてみたいと思います。
有難うございます。
追記です。
先ほど、ルーターのメーカー（IODATA）に現在の状況で問い合わせをしてみました。返事は後日となっていましたが何か分かりましたらこちらに書き込みたいと思います。宜しくお願いします。
> VPN接続ですと「nodename nor servname provided, or not known」と表示
これは、OSXで利用されてるmDNSResponderのキャッシュの問題ということです。
で、
sudo killall mDNSResponder
としてmDNSResponder を停止すれば解決というのがありました。
http://g-taki.com/wordpress/web/6943.html
（停止しても、すぐ再開するので心配無用）
これでVPN経由のSMB接続の問題も解決になりませんか？
はに様
有難うございます。
sudo killall mDNSResponderを試しましたが、残念ながら変わりませんでした。
私も色々試しているのですが、
PC:windows7→モバイルルーター(192.168.255.1)→自宅のルーター(192.168.0.1)→NAS4free(192.168.0.9)
PC:MacBook Pro→モバイルルーター(192.168.255.1)→自宅のルーター(192.168.0.1)→NAS4free(192.168.0.9)
でどちらも同じVPN接続をしているのですが、windows7のPCは自宅のルーター(192.168.0.1)及びNAS4free(192.168.0.9)の管理画面が表示されますがMacでは管理画面が表示させることができません。でもVPN接続でping(192.168.0.9)、ssh(192.168.0.9)ともに出来ています。
Macではモバイルルーター(192.160.255.1)の管理画面しか表示させることができませんでした。
> sudo killall mDNSResponderを試しましたが、
これ、あきませんか。
でも、どうも、DNS関連の気がします。
hostsファイル作ってみるとどうですか？
macで /etc/hosts を作ります。
ターミナルで、
sudo pico /etc/hosts
とします。hostsファイルは最初から用意されたものがありますので、これで、出てくると思います。
そこで、
192.168.0.9 nas4free
を最下行に追加します。^o （Control-o）とするとこれを書き込めます。その上で、^x とすると、picoエディターから出られます。
これらはpicoを実行すると、下に出ますので、それを見ながらやれば良いです。
less /etc/hosts
とすれば意図した通りになってるかどうか確認できます（lessはqとすれば終了できます）。
これを書いた上でアクセスしてみるとどうですか？
これを書いておけば、nas4free とするだけでNAS4Freeにアクセスできるはずです。
例えば、
ping nas4free
で（ラン内でも、VPN経由でも）NAS4Freeにpingが通るはずです。
本当はhostsファイルに書き込むんじゃなくて、DNSを立ててそれを参照するようにするのが良いのですけど。
はに様
教えて頂いた通りにsudo pico /etc/hostsで追記致しまして、vpn接続後にping nas4free(仮)としたところpingが通ることを確認致しました。
しかし(smb://nas4free)を試してみたところ結果は変わらず、サーバーへ接続中となりその後接続が切れました。
自宅へ帰ったら念の為nas4freeで再度afpを設定してafp接続でも試してみたいと思います。
> しかし(smb://nas4free)を試してみたところ結果は変わらず
そしたら、/etc/hosts を
192.168.0.9 nas4free nas4free.local
としてみてください。
.local とつけたのを後ろに追加します。これはボンジュールの名前です。
書き換えた後、ファイル共有のテストをする前に、
sudo killall mDNSResponder
も実行してみてください。
はに様
>そしたら、/etc/hosts を
192.168.0.9 nas4free nas4free.local
としてみてください。
.local とつけたのを後ろに追加します。これはボンジュールの名前です。
上記の教えて頂いた通り、nas4free.local（仮）追加してファイル共有のテストをする前に
>sudo killall mDNSResponder
も実行したのですが残念ながら変わりませんでした。
ping が通り、LANではSMBもOK、どうにもわかりませんね。
ちなみで「サーバへ接続...」で「smb://invalid.host.name」とやると数秒で
と表示されました。
これが表示されないのならホスト名がIPアドレスに変換できていないということはなさそうです。
やはりログにすがるしかなくなってきたような気がしますが、ネットワーク上で実際に通信が行なわれているかの確認に以下の方法はどうでしょう。
実際にはデータまで解析しないと判明しないかもしれませんが、少なくとも通信が行なわれていることはこれだけでも確認できます。
（LAN上では動作確認してますが、VPNのインターフェースに使えるかは未確認です）
1. ターミナルで次のコマンドを実行し、VPNインターフェースのネットワークデバイス名を確認
system_profiler SPNetworkDataType
VPNに割り当てられた BSD Device Name がその名前になります。（以下ではen1であるとします）
2. ターミナルで次のコマンドを実行
sudo tcpdump -tttt -i en1 'host 192.168.0.9 and port 445'
-tttt = タイムスタンプを実時間で表示
-i en1 = モニタするインターフェース名を指定
host 192.168.0.9 = モニタする対象をIPアドレスで限定
port 445 = モニタするポート番号を限定
実行例：
（tcpdumpを開始後、別のターミナルウインドウでtelnet を実行、接続後少し待って切断）
$ telnet 192.168.0.9 445
Trying 192.168.0.9...
Connected to nas1.tm.private.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
（tcpdumpの実行、telnet 切断後にcontrol-Cで終了、macのホスト名をXXXXXXX、接続先のホスト名をYYYYYYYYに変えてます）
$ sudo tcpdump -tttt -i en1 'host 192.168.0.9 and port 445'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 262144 bytes
2016-02-15 12:50:53.269618 IP XXXXXXXX.58867 > YYYYYYYY.microsoft-ds: Flags [S], seq 583255051, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1155521742 ecr 0,sackOK,eol], length 0
2016-02-15 12:50:53.269762 IP YYYYYYYY.microsoft-ds > XXXXXXXX.58867: Flags [S.], seq 3237367780, ack 583255052, win 17896, options [mss 8960,sackOK,TS val 664875457 ecr 1155521742,nop,wscale 5], length 0
2016-02-15 12:50:53.269904 IP XXXXXXXX.58867 > YYYYYYYY.microsoft-ds: Flags [.], ack 1, win 4117, options [nop,nop,TS val 1155521742 ecr 664875457], length 0
2016-02-15 12:51:03.953075 IP XXXXXXXX.58867 > YYYYYYYY.microsoft-ds: Flags [F.], seq 1, ack 1, win 4117, options [nop,nop,TS val 1155532358 ecr 664875457], length 0
2016-02-15 12:51:03.955204 IP YYYYYYYY.microsoft-ds > XXXXXXXX.58867: Flags [F.], seq 1, ack 2, win 560, options [nop,nop,TS val 664876525 ecr 1155532358], length 0
2016-02-15 12:51:03.955401 IP XXXXXXXX.58867 > YYYYYYYY.microsoft-ds: Flags [.], ack 2, win 4117, options [nop,nop,TS val 1155532360 ecr 664876525], length 0
^C
6 packets captured
121966 packets received by filter
0 packets dropped by kernel
ToMi様
教えていただいた下記のコマンドを試したところ
system_profiler SPNetworkDataType
system_profiler SPNetworkDataType
Network:
VPN (PPTP):
Type: PPP (PPTP)
BSD Device Name: ppp0
IPv4 Addresses: 192.168.0.33
IPv4:
Addresses: 192.168.0.33
Configuration Method: PPP
Destination Addresses: 192.168.0.1
Interface Name: ppp0
Network Signature: VPN.RemoteAddress=tamakicloud.iobb.net
OverridePrimary: 1
Router: 192.168.0.1
ServerAddress: 126.10.212.19
IPv6:
Addresses: ::1
Configuration Method: Automatic
Interface Name: ppp0
IsNULL: 1
OverridePrimary: 1
Router: ::1
DNS:
Server Addresses: 218.176.253.65, 218.176.253.97
Supplemental Match Domains:
Supplemental Match Orders: 100000
Proxies:
FTP Passive Mode: Yes
Supplemental Match Domains:
Supplemental Match Orders: 100000
Service Order: 0
Wi-Fi:
Type: AirPort
Hardware: AirPort
BSD Device Name: en1
IPv4 Addresses: 192.168.255.9
IPv4:
Addresses: 192.168.255.9
ARPResolvedHardwareAddress: 40:27:0b:00:2b:de
ARPResolvedIPAddress: 192.168.255.1
Configuration Method: DHCP
Interface Name: en1
Network Signature: IPv4.Router=192.168.255.1;IPv4.RouterHardwareAddress=40:27:0b:00:2b:de
Router: 192.168.255.1
Subnet Masks: 255.255.255.0
IPv6:
Configuration Method: Automatic
DNS:
Server Addresses: 192.168.255.1
DHCP Server Responses:
Domain Name Servers: 192.168.255.1
Lease Duration (seconds): 0
DHCP Message Type: 0x05
Routers: 192.168.255.1
Server Identifier: 192.168.255.1
Subnet Mask: 255.255.255.0
Ethernet:
MAC Address: 28:cf:e9:53:fb:03
Media Options:
Media Subtype: Auto Select
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Auto Discovery Enabled: Yes
Service Order: 1
Bluetooth DUN:
Type: PPP (PPPSerial)
Hardware: Modem
BSD Device Name: Bluetooth-Modem
IPv4:
Configuration Method: PPP
IPv6:
Configuration Method: Automatic
Proxies:
FTP Passive Mode: Yes
Service Order: 2
Ethernet:
Type: Ethernet
Hardware: Ethernet
BSD Device Name: en0
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Ethernet:
MAC Address: 10:dd:b1:b3:82:b4
Media Options:
Media Subtype: none
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 3
FireWire:
Type: FireWire
Hardware: FireWire
BSD Device Name: fw0
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Ethernet:
MAC Address: 44:fb:42:ff:fe:0f:2e:4a
Media Options: Full Duplex
Media Subtype: Auto Select
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 4
Bridge (bridge0):
Type: Ethernet
Hardware: Ethernet
BSD Device Name: bridge0
IPv4:
Configuration Method: DHCP
IPv6:
Configuration Method: Automatic
Proxies:
Exceptions List: *.local, 169.254/16
FTP Passive Mode: Yes
Service Order: 5
と表示されまして、BSD Device Name: ppp0と分かりましたので
sudo tcpdump -tttt -i ppp0 'host 192.168.0.9 and port 445'
と実行しまして、
（tcpdumpを開始後、別のターミナルウインドウでtelnet を実行、接続後少し待って切断）
（tcpdumpの実行、telnet 切断後にcontrol-Cで終了、macのホスト名をXXXXXXX、接続先のホスト名をYYYYYYYYに変えてます）
を行ったところ
2016-02-15 14:13:40.971004 IP tamakicloud.microsoft-ds > 192.168.0.33.51871: Flags [.], ack 1555, win 250, options [nop,nop,TS val 3896438149 ecr 115852499], length 0
2016-02-15 14:13:49.844953 IP 192.168.0.33.51872 > tamakicloud.microsoft-ds: Flags [F.], seq 1, ack 1, win 8265, options [nop,nop,TS val 115862364 ecr 301225664], length 0
2016-02-15 14:13:50.443170 IP tamakicloud.microsoft-ds > 192.168.0.33.51872: Flags [.], ack 2, win 252, options [nop,nop,TS val 301248949 ecr 115862364], length 0
2016-02-15 14:13:50.443200 IP tamakicloud.microsoft-ds > 192.168.0.33.51872: Flags [F.], seq 1, ack 2, win 252, options [nop,nop,TS val 301248959 ecr 115862364], length 0
2016-02-15 14:13:50.443272 IP 192.168.0.33.51872 > tamakicloud.microsoft-ds: Flags [.], ack 1, win 8265, options [nop,nop,TS val 115862961 ecr 301248949], length 0
2016-02-15 14:13:50.443363 IP 192.168.0.33.51872 > tamakicloud.microsoft-ds: Flags [.], ack 2, win 8264, options [nop,nop,TS val 115862961 ecr 301248959], length 0
2016-02-15 14:13:51.968509 IP 192.168.0.33.51871 > tamakicloud.microsoft-ds: Flags [P.], seq 1555:1627, ack 1011, win 8201, options [nop,nop,TS val 115864481 ecr 3896413959,nop,nop,sack 1 {5187:5191}], length 72SMB-over-TCP packet:(raw data or continuation?)
2016-02-15 14:13:52.139838 IP tamakicloud.microsoft-ds > 192.168.0.33.51871: Flags [.], ack 1627, win 250, options [nop,nop,TS val 3896450155 ecr 115864481], length 0
^C
252 packets captured
1320 packets received by filter
0 packets dropped by kernel
と表示されました。
見づらくてすみません。
追記です。
VPN接続してNASにアクセス(smb://192.168.0.9)した時のルーターのログです。
Feb 15 15:46:41 [SYSTEM]: CTRL: Couldn't write packet to client.
Feb 15 15:46:37 [SYSTEM]: CTRL: Client pppd finish wait
Feb 15 15:46:37 [SYSTEM]: CTRL: Client pppd TERM sending
Feb 15 15:46:37 [SYSTEM]: CTRL: Reaping child PPP[3511]
Feb 15 15:46:37 [SYSTEM]: CTRL: CTRL read failed
Feb 15 15:46:37 [SYSTEM]: CTRL: couldn't read packet header (exit)
Feb 15 15:46:37 [SYSTEM]: CTRL: EOF or bad error reading ctrl packet length.
Feb 15 15:43:06 [SYSTEM]: CTRL: Starting call (launching pppd, opening GRE)
Feb 15 15:43:06 [SYSTEM]: CTRL: Client 210.130.191.120 control connection started
ログについてはこれから調べてみたいと思います。
返信を下さいました皆様色々と有難うございました。NASに無事、接続することが出来ました。
犯人？はMTUでした。MTUの値を自動（1500？）から1400へ下げたところ無事に接続致しました。
そしてこれからMTUの値の適正値をチェックし最適な値を探したいと思います。
本当に有難うございました。
VPNで家庭内NASが表示されなくなった。
