ipsec右サブネットが広すぎてルーティングテーブルを含めることはできません。 | IPSecはトンネルを介さずに「ローカルに」いくつかのパケットをルーティングします。

ipsec右サブネットが広すぎてルーティングテーブルを含めることはできません。 | IPSecはトンネルを介さずに「ローカルに」いくつかのパケットをルーティングします。

(IPSec) ルーティングテーブルの一部をオーバーライドしたいと思います。

(IPSecトンネルを経由せずにeth0を介して10.108.0.0/16へのローカルパス)

私のIPSECの設定

conn vpc
    type=tunnel
    authby=secret
    left=172.16.0.200
    leftid=x.x.x.x
    leftsubnet=172.16.0.0/16
    leftfirewall=yes
    right=y.y.y.y
    rightsubnet=10.0.0.0/8
    #pfs=yes
    auto=start

ご覧のとおり、10.0.0.0/8はトンネルを介してルーティングされます。

# ip r s t all
10.0.0.0/8 via 172.16.0.1 dev eth0  table 220  proto static  src 172.16.0.200 
default via 172.16.0.1 dev eth0 
10.108.0.0/16 via 172.16.0.1 dev eth0 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.200 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 172.16.0.0 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
local 172.16.0.200 dev eth0  table local  proto kernel  scope host  src 172.16.0.200 
broadcast 172.16.0.255 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
fe80::/64 dev eth0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
local ::1 dev lo  table local  proto none  metric 0 
local fe80::52:b2ff:fe65:b0fe dev lo  table local  proto none  metric 0 
ff00::/8 dev eth0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101

# ipsec statusall
Listening IP addresses:
  172.16.0.200
Connections:
     vpc:  172.16.0.200...x.x.x.x  IKEv1/2
     vpc:   local:  [x.x.x.x ] uses pre-shared key authentication
     vpc:   remote: [y.y.y.y] uses pre-shared key authentication
     vpc:   child:  172.16.0.0/16 === 10.0.0.0/8 TUNNEL
Security Associations (1 up, 0 connecting):
     vpc[3527]: ESTABLISHED 30 minutes ago, 172.16.0.200[x.x.x.x]...y.y.y.y[]
     vpc{1}:   172.16.0.0/16 === 10.0.0.0/8

特に追加しました。

    #ip r a 10.108.0.0/16 via 172.16.0.1

10.108.0.0/16 via 172.16.0.1 dev eth0

テーブル220「以前」をキャプチャしたいが、
トラフィックはまだIPSecトンネルを通過します。一部のレイヤーが欠けているようです。 rightsubnet=10.0.0.0/8 を rightsubnet=10.0.0.0/16 に変更できることを知っていますが、パスを 1 つだけ変更したいと思います。


ただ確認中

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst x.x.x.x
            proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 

たぶんここで何かを変えることができると思います。


私の考えではIPSecトンネルを介さずにローカルeth0を介して10.108.0.0/16をルーティングします。

編集ポリシーを次のように拡張しました。

ip xfrm policy update dir in src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir out src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir fwd src 172.16.0.0/16 dst 10.108.0.0/16

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir fwd priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir out priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir in priority 0 

もう一つの試み:

ip xfrm policy add dir out src 172.16.0.0/16 dst 172.16.0.1
ip xfrm policy add dir in src 172.16.0.0/16 dst 172.16.0.1 
ip xfrm policy add dir fwd src 172.16.0.0/16 dst 172.16.0.1

# ip xfrm policy 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir fwd priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir in priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir out priority 0 
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
            proto esp reqid 1 mode tunnel

しかし、まだ良い「リダイレクト」のようには見えません。

ベストアンサー1

これはあなたが聞きたいものではないかもしれないことを知っていますが、IPsecとルーティングを処理するための最良の方法は2つを完全に分離することです。ポリシーモードのデフォルトIPsec(Linuxのやり方、使用しているものと似ています)は、階層を「マージ」する傾向があり、ルーティングを非常にあいまいにします。より良いアプローチは、IPsecを一般的な論理ネットワークリンクのように扱うことです。 IPsecはポイントツーポイント通信を処理し、GREの上にOSPFやBGPなどのダイナミックルーティングプロトコルを使用します(この場合はダイナミックルーティングをスキップできます)。欲しいけどお勧めします)。

あなたの場合、インターフェイスを直接処理するのではなく、IPsecスタックがインターフェイスの上部またはインターフェイス上に172.16.0.0/16ポイントツーポイントリンクを作成できるようにします。10.0.0.8/8たとえば、左側の IP と右側の IP を使用できます。設定したら、ローカルおよびリモート側の内部IPを使用してGREトンネルを作成します(そしてその外部側に上記のIPを使用します)。ボーナス:転送モードでIPsecを実行できる場合は、その部分を完全に削除し、エンドポイントの実際のIPをGREトンネルの外部部分として使用できます。/30/3110.254.254.1/3010.254.254.2/3010.100.100.1/3010.100.100.2/3010.254.254.0/3010.254.254.0/30

標準のイーサネットインターフェイス(GREトンネル)があり、非常に簡単に静的ルーティングを実行できます。を10.0.0.8/8介して10.100.100.2172.16.0.0/16を指すだけです10.100.100.1。より良いことは、これらのスタティックルートを完全に削除し、OSPFまたはBGPがルーティングを自動的に処理できるようにすることです(quaggaを参照)。

利点:デフォルトのIPsecスタックはルーティングから完全に分離されているため、再構成せずにいつでも簡単にルートを追加できます。標準のイーサネットインターフェイスを必要とするすべてのサービスを問題なく実行できます(iptablesは完璧な例です)。 BGPと複数のIPsecトンネルを活用して、複数の分岐と冗長パスを簡単に完了し、やや複雑なIPsec高可用性シナリオを完全に回避できます。ただし、最大の利点は、追加の設定なしで親ネットワーク層に簡単に拡張できる非常に孤立した場所(リンクのトラフィック保護)にIPsecがあることです。

IPsecは非常に柔軟なプロトコルなので、多くのことが最終的にその渦に巻き込まれます。いくつかの点では、IPsecが最善を尽くすことに集中し、より高いレベルのネットワークスタックの概念を活用することがキッチンシンクを投げるよりも本当に良いです。

おすすめ記事