☰

두 IPsec 터널 간의 트래픽 라우팅

tag-icon • tag-icon vpn ipsec strongswan backend libreswan
두 IPsec 터널 간의 트래픽 라우팅

DO 인프라에서 백엔드를 실행하고 이를 사이트라고 부릅니다.이비, 타사 사이트에 연결됨잠다음 libreswan 구성을 사용하여 IPsec 터널을 통해:

conn prov-client
  ...
  right=$YVI_IP
  rightsourceip=10.31.3.1
  rightsubnet=10.31.3.0/28
  left=$PROV_IP
  leftsubnet=10.70.0.36/28

잠에서 실행 중인 서버가 있고 10.70.0.37다음에서 서버와 상호 작용할 수 있습니다.이비.

내 문제는 로컬 개발 환경(다른 네트워크의 Ubuntu 상자)을 설정하고 있으며 변경 사항이 있을 때마다 배포해야 한다는 것입니다.이비왜냐하면 거기에서만 API에 접근할 수 있기 때문입니다.잠. 연결하여 이를 방지하고 싶습니다.현지의에게이비해당 트래픽을 다음으로 라우팅합니다.잠API에 도달할 수 있도록잠~에서현지의개발이 용이해졌습니다.

나는 연결한다현지의에게이비다음 구성을 갖춘 로드 워리어로서:

conn remote-dev-client
  ...
  left=$YVI_IP
  leftsubnet=10.31.3.0/28
  right=%any
  rightaddresspool=10.31.4.1-10.31.4.254

연결이 성공적으로 설정되었습니다.현지의난 닿을 수 10.31.3.1있어이비. 내가 원하는 것은 도달하는 것 10.70.0.37입니다잠~에서현지의. 네트워크 에 대한 경로가 자동으로 추가되지 않아서 일부 및 규칙을 수동으로 10.70.0.36/28설정해 보았습니다 .ip xfrmip route현지의:

# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000

# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000

ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static

나는 이제 달려 ip xfrm monitor간다이비그리고 나서부터현지의핑 10.70.0.37; 도착하는 패킷을 볼 수 있습니다.이비(xfrm 모니터에서이비), 응답이 아닌 발신만 가능합니다(예를 들어 10.31.3.1에 ping을 실행한 경우 표시됨).이비트래픽을 수신하지만 라우팅하지 않습니다.잠? 이건 정말 어떻게 해석해야 할지 모르겠습니다.

경로를 추가해야 할 것 같아요이비트래픽을 다음으로 라우팅하려면잠API는 올바르게 작동하지만 위의 규칙에 유사한 규칙을 추가해도 작동하지 않습니다. 제가 무엇을 놓치고 있는지, 무엇을 잘못하고 있는지 이해하는 데 도움을 주시면 감사하겠습니다.

다른 접근 방식에 대한 제안도 환영합니다.잠은(는) 내가 제어할 수 없는 IPsec 터널을 통해 이루어집니다.이비, 내가 제어합니다.

답변1

iptables NAT rule로 해결했습니다. 정책 ip xfrm은 필요하지 않았습니다. 이것은 전문가가 아닌 누군가를 위해 제가 한 일에 대한 간단한 설명입니다.

에서이비외근 직원에게 10.31.4.0/24서브넷을 할당하므로 해당 네트워크의 경로가 키잉 데몬(내 경우에는 libreswan)에 의해 자동으로 설치되므로 NAT 규칙을 추가했습니다.이비( /etc/ufw/before.rules, 저는 UFW를 사용하고 있기 때문에 직접적으로 동일한 결과를 얻을 수 있습니다 iptables):

*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# PRE 
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37


# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1

COMMIT

*natNAT 테이블에 규칙을 적용하도록 iptables에 지시하고 실제로 규칙 COMMIT을 저장합니다. -FUFW는 규칙을 추가 ufw enable하지만 삭제하지 않기 ufw disable때문에 편의를 위해 존재합니다. 따라서 중복 항목이 생기므로 플러시 플래그가 사용 됩니다 -F.

이 PREROUTING규칙은 로드 워리어 서브넷에서 으로 향하는 패킷에 적용되며 10.31.3.2대상 주소를 대신 으로 변경하여 10.70.0.37해당 10.31.3.2IP 주소를 에 효과적으로 할당합니다.잠출장 근무자의 관점에서 본 서버.

이 POSTROUTING규칙은 나가려고 하는 로드 워리어 서브넷에서 들어오는 패킷 10.70.0.37(즉, 사전 라우팅 규칙에 방금 도달한 패킷)에 적용되며 대상 주소를 의 주소에서 로 변경 10.31.4.0/0합니다 10.31.3.1. 이는 경로, 서버 또는 기타 항목을 제어하지 않기 때문에 필요합니다.잠, 그래서 만약잠서브넷 에서 요청을 받으면 10.30.4.0/24응답 방법을 알 수 없습니다. 그러나 그것은 알고 있다 10.31.3.1.

그리고 그게 다야! 이제 닿을 수 있어잠~에서현지의~을 통해이비에 10.31.3.2.

관련 정보