web-dev-qa-db-ja.com

OSXのnetstat-rはゲートウェイについて何を教えてくれますか？

ルートテーブルにわからないエントリがたくさんあることに気づきました。

ルートテーブルは次のとおりです。

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.0.254      UGSc           28        0     en1
10.8.0.1/32        10.8.0.5           UGSc            1        2    tun0
10.8.0.5           10.8.0.6           UH              2        3    tun0 
127                localhost          UCS             0      284     lo0 
localhost          localhost          UH             10     3663     lo0
169.254            link#5             UCS             0        0     en1
192.168.0          link#5             UCS             4        0     en1
192.168.0.25       localhost          UHS             0        0     lo0
192.168.100        10.8.0.5           UGSc            0        7    tun0

私はこのルートが言うと信じています：

  1. 192.168.100。*のすべてのトラフィックは10.8.0.5（！？）にルーティングする必要があります
  2. 10.8.0.5へのすべてのトラフィックは、10.8.0.6（！？）にルーティングする必要があります。
  3. 10.8.0.1/32へのすべてのトラフィックは、10.8.0.5（！？）にルーティングする必要があります。

192.168.100が10.8.0.1ではなく10.8.0.5になり、次に5から6になり、1/32が6に一致すると思われるのはなぜですか。ループがあるようです。

10.8.0.5にpingを実行できませんが、それがvnetworkのIPだと思いました。 10.8.0.6にpingを実行できませんが、マスクされていると思います。「フィルターによって通信が禁止されています」という出力が表示されます。

ifconfigは以下を示します：

tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 
    open (pid 1307)

そしてまた6-> 5があります！

注：ルートを理解するためにさらに情報が必要な場合に備えて、ここから先は詳細です。

私のセットアップは次のとおりです。-ルーター（192.168.0.254）を備えたローカルネットワーク（192.168.0 ..）上のラップトップ-ネット（10.8.0 ...）上の仮想ルーター（10.8.0.1）を介して（192.168）のネットワークに接続されたVPN .100 ...）ルーター付き（192.168.100.1）-192.168.100.200はリモートネットワーク上のサーバーです

今、私が 'traceroute 192.168.100.200'のとき、私は期待していました

10.8.0.1（反対側のVPNルーター）192.168.100.1（反対側の物理ネットワーク上のルーター）192.168.100.200（ホストに到達しました。）

代わりに、無限の*のセットを取得します

これは この質問 と同じではなく、答えが見つからなかったので、ありがとう！

macosnetworkingvpnroutingnetstat
1
nycynik

ルート情報を部分的に正しく読んでいます。

tun0は、VPNに使用される仮想インターフェイスであり、10.8.0.6（VPNGWの側）から10.8.0.5（VPNGWのリモート側）までのポイントツーポイントリンクを（それ自体の内部目的で）使用します。それは「ifconfigtun0」があなたに言うのと同じことです。これらの2つのアドレスに直接アクセスしないでください。

したがって、GW 10.8.0.5を介してルーティングするトラフィックはすべて（インターフェイスtun0を介して）VPNトンネルに入り、反対側でVPNトンネルを出ます（もちろん、VPNトンネルが確立され、機能していると仮定すると、pid 1307で実行されるVPNプロセスによって）。

10.8.0.1/32 10.8.0.5 UGSc 1 2 tun0

これは、ホスト10.8.0.1（/ 32は [〜＃〜] cidr [〜＃〜] 表記、つまり「この1つのホストのみ」を意味する）に送信されるものはすべて、10.8のゲートウェイ経由でルーティングされることを意味します。 0.5（つまり、VPNトンネルに入ります）。

したがって、10.8.0.1にpingを実行すると、VPNトンネルが機能する場合にのみ機能します。これがここにある理由です（反対側のコンピューターが稼働していない場合でも、トンネルが機能しているかどうかを確認できます）。

192.168.100 10.8.0.5 UGSc 0 7 tun0

上記と同じですが、クラスCネットワーク全体の192.168.100。*（CIDRでは短い「192.168.100」の代わりに「192.168.100.0/24」と記述することもできます）。これは、トンネルを設定する主な目的です。したがって、VPNを介してリモート側でこの範囲のアドレスにアクセスします。

10.8.0.5 10.8.0.6 UH 2 3 tun0

これは間違っています。フラグ「UH」に注意してください。「G」がないということは、データをルーティングできるゲートウェイではなく、直接接続されたポイントツーポイントリンクを意味します。したがって、10.8.0.5のトラフィックが10.8.0.6を介して送信されることを意味するのではなく、tun0インターフェイスを使用してこのコンピューター（IP 10.8.0.6）に10.8.0.5が直接表示されることだけを意味します。

192.168.100が10.8.0.1ではなく10.8.0.5になり、次に5から6になり、1/32が6に一致すると思われるのはなぜですか。ループがあるようです。

うまくいけば、上記の情報がそれらの誤解を解消した。

10.8.0.5にpingを実行できませんが、それがvnetworkのIPだと思いました。 10.8.0.6にpingを実行できませんが、マスクされていると思います。「フィルターによって通信が禁止されています」という出力が表示されます。

はい、これら2つのアドレスはtun0インターフェースによって内部的に使用されます。（ネットワーク間などでトラフィックアナライザーを実行している場合を除いて）気にする必要はありません。通常のアドレスのようには機能しません。

6
Matija Nalis