キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

Reverse-route で生成したルートが消えない

リモートアクセス VPN 接続では、通常下記のように社外ネットワークにある VPN クライアントとなっているパソコンなどから、インタネットを経由して VPN サーバに接続します。VPN 接続が確立できたら、社外に居ながら、社内ネットワークにアクセスできるようになります。

VPN クライアント ------------- [インターネット] ------------- (Gi0/0) VPN サーバ(IOS ルータ) (Gi0/1) ------------- 社内ネットワーク

# ここでは IOS ルータが VPN サーバになっているとします。

一般的な設定として、クライアントへのルーティングをサポートするため、RRI (reverse-route) を有効にし、インタネット向けのインターフェースに crypto map を定義する必要があります。RRI は、VPN 接続時にクライアントへ配布した VPN プールのアドレスに対する /32 のスタティックルートを VPN サーバのルーティングテーブルに追加する機能です。正常の動作として、VPN セッションの切断に伴って RRI によって生成されたルートも削除されます。

// ここでは設定の一部を抜粋

!

crypto dynamic-map DYN 10
reverse-route

!
crypto map MAP 10 ipsec-isakmp dynamic DYN

!
interface GigabitEthernet0/0

description Internet facing interface

crypto map MAP

!
interface GigabitEthernet0/1

description Corporate LAN network

!

そこで、VPN クライアントとなっているパソコンが社内ネットワークに持ち運ばれた場合、本来社内にいる時に VPN 接続は必要ないですが、万が一社外にいる時と同様に VPN 接続を確立してしまいますと、その時に配布されたアドレスに対する /32 のルートが RRI によって追加されます。リモートアクセス VPN では、このように社内から接続することを想定していないため、ここで追加された RRI ルートは、VPN セッションが切れても削除されません。

結果的に、もしその後同一の VPN プールのアドレスが再度(別の VPN クライアントへ)配布された場合、ルーティングテーブルには、そのアドレスに対する /32 のスタティックルートが二つ載せてしまいます。もちろん、二つの内、古いルートは無効のものなので、ルーティング上問題が出てきて、通信できなくなることがあります。

この問題は CSCth15924 として報告されており、その修正によって、crypto map が定義されていないインターフェース(ここでは Gi0/1)からのリモートアクセス VPN セッションでは RRI ルートが生成しないようになります。

諸事情によって CSCth15924 の修正バージョンへアップグレードすることが難しい場合、下記のようにアクセスリストを活用してこの問題を回避することもできます。

1) インタネット向けインターフェースの IP に対する VPN 接続のパケットを破棄するようにアクセスリストを作成します。

Router(config)# ip access-list extended inbound
Router(config-ext-nacl)# deny udp any host <インタネット向けインターフェースの IP> eq isakmp
Router(config-ext-nacl)# permit ip any any


2) 上記アクセスリストを社内ネットワーク側インターフェースの in 方向に適用します。

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip access-group inbound in

バージョン履歴
改訂番号
1/1
最終更新:
‎07-24-2010 04:46 PM
更新者: