web-dev-qa-db-ja.com

pingは機能しますが、TCPは少し変わったトポロジではありません

最初に、私は最初からこのネットワークを設計しなかったと言うので、トポロジーは私にも驚きました。

同じ物理的な場所にある2つのサブネット（1つは私たちの会社で、もう1つはクライアントです）があるため、ネットワークはVLANによって分離されています。ただし、これに加えて、私たちとクライアントの両方に異なるファイアウォールがあるため、ネットワーク間のブリッジとして機能する追加の仮想ルーター（VyOS）があります。 VyOSルーターには2つのインターフェース（eth0とeth1）があります。

両方のネットワークに問題なくpingできますが、クライアントのWebサーバーのサブネットにアクセスしようとすると、接続が失敗します。特に興味深いのは、ゲートウェイを192.168.5.1のゲートウェイではなく手動で192.168.5.34（VyOS）にポイントするように設定すると、接続が機能するため、トラフィックをリダイレクトする必要があるときにファイアウォールで何かが失敗しているはずです。元のインターフェイスと同じインターフェイスから出力されます。また、ソースNATを構成すると、それも機能します。

ネットワークに関する情報は次のとおりです。

私たちのサブネット：192.168.5.0/24ファイアウォール：192.168.5.1 VyOS eth1：192.168.5.34

クライアントサブネット：192.168.1.0/24ファイアウォール：192.168.1.1 VyOS eth0：192.168.1.34

編集：これは、HTTP経由でWebサーバーに接続しようとしたときにトラフィックがたどるルートです

192.168.5.172-> 192.168.5.1-> 192.168.5.34-> 192.168.1.28 | 192.168.1.28-> 192.168.1.1（Juniperファイアウォールで、ここで接続が失敗したようです）

tcpsubnetjunipervyos
3
nyoatype

ネットワークは期待どおりに機能しています。それを描きましょう：

My gosh so many network problems can be explained better and quicker by a succinct diagram. Own work.

これは私が確信している単純化ですが、問題とさまざまな修正（およびそれらの欠点）を示すのに十分な情報がここにあります

前提条件

  • 各デバイスは、LANのファイアウォールIPをデフォルトゲートウェイとして使用します。
  • DNSは重要ではありません
  • この例では、すべてのネットマスクは/ 24です。
  • 2つのLANトポロジは、VLANとして提供されています。ここでは省略し、各VLANを個別の物理LANとして表します。
  • 修正では、3つのルーター/ファイアウォールすべてでルールを管理できることを前提としています。

OSIスタックを使用している場合、これはすべてIPであり、レイヤー3にあります。

1。直接接続されたネットワーク

PCには、IPに送信するパケットがあります。まず、宛先IPが同じローカルIPネットワークにあるかどうかを確認します。 SRCアドレスとDSTアドレスの両方が同じネットワークを共有している場合（サブネットマスクが適用された後も残るIPのビット）、OSはパケットをイーサネットインターフェイスに送信します。 OSは、発信パケットに、それが存在するインターフェイスのソースIPのラベルを付けます。

テストPCはSRC IPが192.168.5.172のパケットを送信します。宛先は192.168.5.250です。ネットマスクは/ 24で、255.255.255.0です。ネットワークは192.168.5.xのままです。したがって、PCはイーサネットからのパケットと宛先はそれを受信します。

2。デフォルトゲートウェイ

デフォルトゲートウェイ、デフォルトルート、ゲートウェイ、ラストリゾートルーターは、パケットを送信するための適切なルートがない場合にパケットを送信するものです。

ネットワークのデフォルトルートは次のとおりです。

enter image description here

したがって、宛先IPがローカルではない（直接接続されていない）場合、TestPCはパケットのアドレス指定を知っていますviaデフォルトゲートウェイ。

デバイスのデフォルトゲートウェイIPアドレスは1つだけです（ハンドウェーブ-はい、シンプルにしようとしています）。

（サイドコメント）VyOSボックスにデフォルトゲートウェイが設定されている場合、おそらくオフィスのジュニパー経由です。これは更新やその他のことにはいいことですが、環境には関係ありません。また、VyOSでデフォルトゲートウェイがまったく構成されていないこともまったく妥当です。

3。特定のルート

質問からのtracerouteは、2つのオフィスファイアウォールが他のLANに関する特定の知識を持っていることを示しています。

そのため、各ファイアウォールには追加のルートが構成されます。

あなたの会社ジュニパーは「192.168.5.34経由で192.168.1.0/24にアクセスする」ことを知っています

彼らのファイアウォールは、「192.168.5.0 255.255.255.0 via 192.168.1.34」または同様のものを認識しています。絵でそれは意味します：

enter image description here

4。パケットと一致する

パケットの観点からこれを視覚化しましょう。

a。 TestPCはgoogleにpingします（TCP接続）を説明するよりステートレスで簡単なので、私はpingを使用しています）

  1. パケットは8.8.8.8です。これは192.168.5.xにはないため、testPCはDSTが192.168.5.1のイーサネット上でパケットをスローします。
  2. ジュニパーは、SRC 192.168.5.172およびDST 8.8.8.8のパケットを受信しますNATに構成され、このパケットを転送します。SRCアドレスは、ジュニパーの外部Inet IPに書き換えられ、 ISP。ジュニパーはメモリ内のテーブルにこの接続を追跡します。
  3. パケットはgoogleに送られ、SRCが8.8.8.8、Inet IPのDSTでISPを介して応答が返されます
  4. ジュニパーネットワークスは、接続追跡テーブルを調べ、これがTestPCによって開始された接続に対する応答であることを発見しました。したがって、DSTを192.168.5.172に変更し、このパケットをLANインターフェースにプッシュします（これは、192.168.5.xに直接接続されているインターフェースであるためです）
  5. TestPCはIPのパケットを聞き、それをネットワークから取得します（ここでさらに手を振っています）

これは画像として：

enter image description here

b。 TestPCは192.168.1.28で顧客のサーバーにpingします。

  1. 上記のように、testPCは192.168.1.xに直接接続していないため、パケットをデフォルトゲートウェイであるJuniperにアドレス指定します。
  2. ジュニパーはパケットを転送するように構成されていますが、192.168.1.xへの静的ルートがありますvia VyOSが192.168.5.34なので、NAT=を使用して宛先を変更する代わりにジュニパーネットワークスは、ISPゲートウェイにパケットをVyOS経由で転送します。
  3. VyOSは2つのネットワークのみを認識します。一方の側でもう一方の側のパケットを確認し、単にそれをもう一方のインターフェイスに転送します
  4. CustyServerはパケットを見て、それを受信します。途中！
  5. CustyServerは192.168.5.172に応答を送信しますが、これは直接接続されていないため、デフォルトゲートウェイに移動します。
  6. Custyファイアウォールには、このパケットの処理方法がないIDEAであるため、ドロップされるか、ISPに転送されてドロップする可能性があります。
  7. この時点ですべてです。応答パケットは失われ、TestPCはタイムアウトまで応答を待ちます。

これが絵として最後です：

enter image description here

これをどのように修正しますか？複数の異なる修正があります。

1。相互接続ネットワーク

これは「適切な」設計であり、2つのファイアウォール間で小さな相互接続ネットワークを使用し、VyOSデバイスを廃止します。相互接続LANとして172.22.22.x/24を使用しました。/24はかなり大きいですが、これは単純なままです。

enter image description here

ポジティブ

  1. 各ファイアウォールはすべてのトラフィックを認識しており、適切に接続追跡できます。
  2. ファイアウォールの変更のために、会社ごとに1つのデバイスを確認します。
  3. 各LANデバイスは、可能な限り最も単純なセットアップを持っています。

欠点

  1. 両方のファイアウォールデバイスには、追加のイーサネットインターフェイスと、それらの間を通るイーサネットケーブルが必要です。

2。お客様のファイアウォールに静的ルートを追加します

欠けているようです。カスタマーファイアウォールからVyOSに青い矢印を追加した場合、より効果的に機能します。

enter image description here

3。ソースを追加しますNAT VyOSデバイスで

有名人は、「NATの層を追加する計画が含まれている場合、根本的な問題を理解していない」と言っていました。これは良い考えではないと思います。

VyOSデバイスが2つのネットワーク間のすべてのトラフィックをそのLAN内の独自のIPにNAT変換する場合、応答トラフィックはデフォルトゲートウェイに移動しようとしません。

主な欠点は、VyOS IPからのすべてのトラフィックが表示され、実際の送信者が誰なのか分からないことです。これにより、フォレンジックが多少難しくなります。

enter image description here

4。すべてのものを静的ルート！

これはひどい答えですが、状況によってはそれが適切な場合があります。

すべてのLANデバイスにこのようなルーティングテーブルがある場合、それらはすべて、カスティLANと通信する方法を知っています。

＃ip ro ls
192.168.5.1 dev eth0によるデフォルト
192.168.1.04経由の192.168.5.34 dev eth0
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.173

欠点は、これは管理上の悪夢です。絶対に動かないデバイスが2つしかない場合は有効かもしれませんが、動的に追加するのは面倒です。

可能な節約

  1. Active Directoryは、グループポリシーを使用して静的ルートをプッシュできます。ドメインに参加しているWindowsボックスではないデバイスは役に立ちません。プリンター、電話、AP、その他すべてを見逃しています。それは私がそれについて知っているすべてです。
  2. DHCPで静的ルートをプッシュすることは可能ですが、ほとんどの実装ではこの提案は無視されます。 pfSenseはそれを行うことができますが、windows10はオプションを無視しました。

enter image description here

要約すれば

LANマップは、ネットワークの問題を理解するための素晴らしいソリューションです。彼らを愛する！私は http://www.gliffy.com/ を使用して、これらのイラストの背景画像を作成しました。

[〜＃〜] kiss [〜＃〜]解が面倒で複雑な場合、おそらく間違った解です。

6
Criggie