ARP：シスコ機器のニュアンスと興味深い事例。 パート2

こんにちはHabr！ この記事の前の部分では、 NATルールとプロキシARP機能に関連するCiscoルーターのARPの機能を調べました。 この投稿では、CiscoルーターとCisco ASAファイアウォールのARPの違いを明らかにしようとします。 記事の最後で、ARPの作業に関連する実践の興味深い事例をいくつか紹介します。



Cisco ASAファイアウォールのNATおよびプロキシARP



NATルールのARPおよびプロキシARP設定に対するCisco ASAファイアウォールの動作は、Ciscoルーターとは異なります。 デフォルトでは、Cisco ASAでNATルールを設定すると、デバイスはNATルールの内部グローバルアドレスに一致するARP要求に応答します。 ただし、この動作はASAインターフェイスIPサブネットの内部グローバルIPアドレスの所有権に依存しません。 この動作により、 sysopt noproxyarp <interface name>オプションが構成されます。



次の単純なトポロジに基づいた例を検討してください。







Cisco ASAインターフェイス設定：

interface Vlan1 nameif inside security-level 100 ip address 192.168.20.1 255.255.255.0 ! interface Vlan2 nameif outside security-level 0 ip address 198.18.0.1 255.255.255.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外部インターフェイスのNATルールとアクセスリストの設定：

 object network TEST-PC-tcp3389 host 192.168.20.5 nat (inside,outside) static 198.18.99.2 service tcp 3389 3389 access-list acl-outside-in extended permit tcp any object TEST-PC-tcp3389 eq 3389 access-group acl-outside-in in interface outside
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

提示された設定からわかるように、Cisco ASAインターフェイスのIPサブネットに属さないアドレス198.18.99.2の下でtcp 3389（RDP）ポートを公開します。



sysopt noproxyarpオプションを確認します。

 asa# sh run all sysopt . . . no sysopt noproxyarp inside no sysopt noproxyarp outside
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプションが設定されていない（noproxyarpが有効になっていない）ことがわかります。 アドレス198.18.99.2のtcpポート3389を開いて、同時にスニファーを見てみましょう。







成功：Cisco ASAはARP要求に応答し、ポートが開きます。



sysopt noproxyarp outsideオプションを設定してみましょう。 外部インターフェイスに接続されているコンピューターのアークキャッシュをクリアし、ポートを再度開こうとします。











ASAは、宛先IPアドレスへのARP要求に応答しなくなりました。 ただし、宛先IPアドレスがASAインターフェイスのIPサブネットにあるかどうかは関係ありません。 sysoptオプションを設定すると、noproxyarp ASAはインターフェイスIPアドレスのみにアドレス指定されたARP要求に応答します。



ルータのip proxy-arpインターフェイスの設定とsysopt noproxyarp Cisco ASAオプションの設定を比較しないでください。 Cisco ASAオプションには、ファイアウォールを介したARP要求のプロキシは含まれません。 このオプションは、NATルールの内部グローバルIPアドレスと、 aliasキーワードを使用して設定されたASA ARPテーブルの静的エントリの提供のみを担当します。





場合によっては、特定のNATルールに対してARP応答機能を無効にする必要があります。 これを行うには、NAT設定でno-proxy-arpキーワードを使用します。 最も一般的な例は、Cisco ASAでVPNを使用するときにNAT例外を設定することです。 Cisco ASAの背後のローカルエリアネットワークが192.168.20.0/24であり、サイト間VPNのリモート側のローカルエリアネットワークが192.168.30.0/24であるとします。 このVPNのNAT例外は、次のように構成できます。

 object network local-LAN subnet 192.168.20.0 255.255.255.0 object network remote-LAN subnet 192.168.30.0 255.255.255.0 nat (any,any) source static local-LAN local-LAN destination static remote-LAN remote-LAN
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここに示されている設定は、ローカルLAN 192.168.20.0/24 IPサブネットが、同じローカルLAN IPサブネットの内部グローバルアドレスの下で、各Cisco ASA（NATルールの任意、任意）で完全に公開されていることをCisco ASAに示します。 したがって、この設定では、Cisco ASAは、内部インターフェイスを含む任意のインターフェイスで受信したIPサブネット192.168.20.0/24からのターゲットIPアドレスへのARP要求に応答します。



アドレス192.168.20.5のホストが、アドレス192.168.20.6の同じIPサブネットからホストにアクセスしたい状況を想像してください。 ターゲットアドレス192.168.20.6に対してARP要求が生成されます。 ARP要求はブロードキャストされ、ターゲットホストとCisco ASAインターフェイスの内部の両方に到達します。 設定されたNATルールにより、Cisco ASAはMACアドレスでARP要求に応答します。 Cisco ASAからのARP応答がターゲットホストからの応答の前に到着すると、ターゲットホストに向けられたすべてのトラフィックはCisco ASAに送られ、そこで安全にドロップされます。



提示された例では、Cisco ASAはローカルIPサブネットの「ブラックホール」として機能し、すべてのトラフィックを自身に「吸い込み」ます。 同時に、ポリシーNAT要素（ destinations静的キーワードの後に​​NATを設定する）は状況を保存しません。 ルータと比較して、Cisco ASAでのこの設定は、ルータインターフェイスでのip proxy-arpとip local-proxy-arpの共同設定と事実上似ています。 この影響を回避するには、Cisco ASAのNATルールにno-proxy-arpキーワードを追加します。

 nat (any,any) source static local-LAN local-LAN destination static remote-LAN remote-LAN no-proxy-arp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注 ：説明されている効果は、キーワードではなく、NATルール設定で正確なインターフェイスを指定することで回避できます。 たとえば、nat（inside、outside）...



まとめ



実践から事例の説明に進む前に、記事の第2部の主要なポイントを強調します。

1. デフォルトでは、Cisco ASAは、インターフェイスIPサブネットが属しているかどうかに関係なく、NATルールの内部グローバルIPアドレスへのARP要求に応答します。 この動作は、 sysopt noproxyarp <interface name>オプションを設定することにより制御されます。
2. Cisco ASAでは、 no-proxy-arpキーワードを使用して、特定のNATルールのARP応答を無効にできます。 特に、NAT例外ルールの場合、ローカルネットワークでの通信の問題を回避するために、ARP応答を無効にする必要があります。
3. プロキシARP機能はCisco ASAで明示的に設定されていませんが、NATルールを使用して必要な効果を達成できます。

だから、練習からのケース。 説明した問題はすべて、私または同僚が新しいシスコのネットワーク機器をインターネットプロバイダーに接続したときに発生したことをすぐに言わなければなりません。 私たちの経験では、ARPの問題を伴うことが最も多いのはこのシナリオです。



ケース番号1。 セカンダリプロバイダーのIPアドレス



Cisco ASAファイアウォールをプロバイダーに接続しました。 接続が成功し、すべてのサービスが正常に機能しました。 ただし、しばらくすると、接続が失われました。 詳細な分析によると、発信接続を開始すると、安定して動作します（トラフィックは両方向に行きます）。 この問題は、インターネットからの着信接続（ルーターへのリモート接続など）でのみ発生します。 この場合、着信接続の発信への直接の依存関係が追跡されます。発信接続がある場合、着信接続は正しく機能し始めます。 ただし、しばらくすると、リモートから接続したり、インターネットからデバイスを「ping」することはできなくなります。



物理層とリンク層はおそらく大丈夫なので、ARPの動作を確認し始めました。 ASAでdebug arpを起動し、arp-cacheをクリアしようとしました。 デバッグメッセージから、ASAは問題なくARP要求を正しく送信し、プロバイダーからARP応答を受信することがわかりました。 この例では、ASAのIPは80.XX4、MACアドレスはa0ec。****。****、プロバイダー80.XX1のIPアドレス、プロバイダーaa43のMACゲートウェイです。****。****：

 arp-send: arp request built from 80.XX4 a0ec.****.**** for 80.XX1 at 978772020 arp-refresh: Trying to refresh ARP for outside 80.XX1 arp-in: response at outside from 80.XX1 aa43.****.**** for 80.XX4 a0ec.****.**** having smac aa43.****.**** dmac a0ec.****.****\narp-set: added arp outside 80.XX1 aa43.****.**** and updating NPs at 978772020 arp-in: resp from 80.XX1 for 80.XX4 on outside at 978772020
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、しばらくして、ASAのdebug arpにメッセージが表示されました。

 arp-in: request at outside from 195.YY1 aa43.****.**** for 80.XX4 0000.0000.0000 having smac aa43.****.**** dmac ffff.ffff.ffff\narp-in: Arp packet received from 195.YY1 which is in different subnet than the connected interface 80.XX4/255.255.255.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメッセージから判断すると、ASAは有効な送信者MACアドレスaa43を持つARP要求を受信します****。****が無効な送信者IPアドレス-195.YY1。 この無効なASP ARP要求は破棄され、ARP応答は送信されません。



したがって、発信トラフィックが存在する場合、ASAはプロバイダーにARP要求を送信し（必要に応じて、ASA ARPテーブルの適切なエントリの更新が必要な場合）、ARP応答を受信します。 ASAからのARP要求のおかげで、プロバイダーの機器もARPテーブルでASAレコードを受信します。 ただし、ASAからの発信トラフィックが長時間なく、ASAがARP要求を送信しない場合、ASAに関するレコードは、ARPテーブルのプロバイダーの機器で期限切れになります。 プロバイダー機器は、ARP要求を送信してレコードを更新しようとしますが、応答を受信しません。 ここから、コミュニケーションに関する「浮遊」問題が現れます。



プロバイダーの機器が間違った送信者IPアドレスでARP要求を送信する理由を理解することは残っています。 後で、プロバイダーはこの状況を確認し、ARPトラフィックのダンプを表示し、ASAデバッグメッセージを確認しました。

 324: 22:03:41.056546 802.1Q vlan#2 P0 arp who-has 80.XX4 tell 195.YY1 325: 22:03:41.937329 802.1Q vlan#2 P0 arp who-has 80.XX4 tell 195.YY1 326: 22:03:42.822909 802.1Q vlan#2 P0 arp who-has 80.XX4 tell 195.YY1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロバイダーのインターフェースでは、アドレス195.YY1がプライマリとして構成され、IPアドレス80.XX4（デフォルトゲートウェイ）がセカンダリとして構成されていることが判明しました。 この設定は状況を完全に説明しました。 この場合、プロバイダーの機器に静的ARPレコードを追加することで問題を解決しました。



シスコのルーターを使用してプロバイダーに接続したとき、別のサイトでもまったく同じ状況が発生しました。 プロバイダーの機器では、ゲートウェイは二次IPアドレスとしても構成されました。 この場合、問題を解決するプロセスを高速化するために、プロバイダーのインターフェイスのプライマリIPアドレスと同じサブネットからルーターにセカンダリIPアドレスを追加しました。 その後、ルーターはプロバイダーからのARP要求に正常に応答し始めました。ARP要求のアドレスと同じサブネットからのIPアドレスがインターフェイスに表示されたためです。



ケース番号2。 ARPの非互換性



オフィスの1つで、Cisco ISRをCisco ASAファイアウォールに置き換える作業を行いました。 ASAファイアウォールは事前設定され、インストールポイントに送信されました。 プロバイダーに接続した後、Cisco ASAはリモート接続に使用できないことが判明しました。 一見すると、デバイス上ですべてが正常に機能しました。 ASAファイアウォールは、標準のARP要求/ ARP応答手順を使用して、プロバイダーのルーターのMACアドレスを正しく決定しました。 パケットがインターネット上のデバイスの外部インターフェイスを離れました。 同時に、ASAには反対方向に何も来ませんでした。 この事実は、組み込みのパケットキャプチャツールによって記録されました。



プロバイダーに連絡した後、ASAからのパケットがプロバイダーの機器に正常に配信されたことがわかり、プロバイダーはアップストリーム機器からの応答パケットも確認​​しました。 ルーターが再接続された後、トラフィックは再び両方向に正しく移動し始めました。 これは、問題がプロバイダーとASAファイアウォールの接合部のどこかにあることを意味していました。 問題の詳細な説明をプロバイダーに再連絡した後、プロバイダーの機器にASAファイアウォールMACアドレスが表示されていないと判断されました。 組み立てられたデモスタンドは、ASAの正しい動作を証明しました（プロバイダーの役割はCiscoルーターによって果たされました）。 何らかの理由で、プロバイダーのデバイスは、ASAからARP応答を受信した後、ARPテーブルにASAを記録しませんでした。 最も興味深いことに、Cisco ASAからのARP要求は破棄されませんでした。 プロバイダーの機器は、ASAからのARP要求に正しく応答しましたが、ARPテーブルにASAレコードを入力しませんでした。



その結果、プロバイダーは、ARPテーブルに静的バインディングを作成するように求められました。 このケースでは、プロバイダーの機器とCisco ASAファイアウォールのARPの非互換性が示されました。 残念ながら、プロバイダーは機器の製造元を発表しませんでした。



ケース番号3。 無償のアルプ



そして再び、Cisco ASAプロバイダーに接続します。 今回はMS TMGサーバーの代わりに。 このケースの特徴は、MS TMGがL2スイッチを介してプロバイダーのデバイスに接続されていたことです。 L2スイッチを介してASAを接続することも想定されていました。











したがって、MS TMGを切断し、代わりにL2スイッチの同じポートでCisco ASAを接続します。 標準的な状況が見られます。トラフィックは外部Cisco ASAポートを離れますが、応答パケットはありません。 プロバイダーに連絡した後、プロバイダーの機器は、Cisco ASAに渡されたIPアドレスの背後にあるMS TMGサーバーのMACアドレスをまだ認識していることがわかりました。



さらなる調査の結果、Cisco ASAファイアウォールは、インターフェイスがDOWN状態からUP状態に移行したときにGratuitous ARPメッセージを送信しないことが明らかになりました。 また、プロバイダーの機器はL2スイッチを介して接続されているため、こちら側でデバイスを変更しても、プロバイダーへのチャネルは落ちず、プロバイダーのルーターのインターフェイスは常にオンのままです。 デバイスとMACアドレスが変更されたことをタイムリーにプロバイダーに通知する唯一の方法は、Gratuitous ARPです。 それ以外の場合は、プロバイダーからのARPレコードのタイムアウトを待つ必要があり、これは通常4時間です。

この場合、Cisco ASAインターフェイスでno ip address、ip address xxxx yyyyコマンドを実行した後、ASAはGratuitous ARPを送信し、すべてが離陸しました。



おわりに



この2部構成の記事では、ネットワークアドレス変換（NAT）とプロキシARP機能を使用する場合のシスコ機器のARPの複雑さを検討しようとしました。 CiscoルーターとCisco ASAファイアウォール間のARPの違いを理解しました。 記事の最後で、ARPの動作により、インターネットプロバイダーに接続するときに発生する問題を調べました。



説明されているケースは、ネットワークの問題を解決および除去するプロセスでARPをチェックする必要性を覚えることがいかに重要であるかを示しています。 この記事がARPの動作をより深く理解するのに役立つことを願っています。



コメントを待っています。 たぶん誰かがARPの仕事に関連する自分自身の興味深いケースを伝えることができます。