☰

ipsec 오른쪽 서브넷이 너무 넓어서 라우팅 테이블을 포함할 수 없습니다. | IPSec는 터널을 통하지 않고 "로컬로" 일부 패킷을 라우팅합니다.

tag-icon • tag-icon route ipsec openswan
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으로 변경할 수 있다는 것을 알고 있지만 경로 하나만 변경하고 싶습니다.

그냥 확인 중

# 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과 라우팅을 처리하는 가장 좋은 방법은 둘을 완전히 분리하는 것입니다. 정책 모드의 기본 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.2및 172.16.0.0/16을 가리키기만 하면 됩니다 10.100.100.1. 더 좋은 점은 이러한 고정 경로를 완전히 제거하고 OSPF 또는 BGP가 자동으로 라우팅을 처리하도록 하는 것입니다(quagga 참조).

장점: 기본 IPsec 스택은 라우팅과 완전히 격리되어 있으므로 재구성하지 않고도 언제든지 쉽게 경로를 추가할 수 있습니다. 표준 이더넷 인터페이스가 필요한 모든 서비스를 아무런 문제 없이 실행할 수 있습니다(iptables가 완벽한 예입니다). BGP 및 여러 IPsec 터널을 활용하여 여러 개의 분기 및 중복 경로를 쉽게 완료하고 다소 복잡한 IPsec 고가용성 시나리오를 완전히 피할 수 있습니다. 그러나 가장 큰 이점은 이제 추가 구성 없이 상위 네트워크 계층으로 쉽게 확장할 수 있는 매우 격리된 위치(링크의 트래픽 보호)에 IPsec이 있다는 것입니다.

IPsec은 매우 유연한 프로토콜이므로 많은 것들이 결국 그 소용돌이에 휩싸이게 됩니다. 어떤 면에서는 IPsec이 최선을 다하는 것에 집중하고 더 높은 수준의 네트워크 스택 개념을 활용하는 것이 부엌 싱크대를 던지는 것보다 정말 좋습니다.

관련 정보