Strongswan은 두 개의 IPsec 터널(그 중 하나는 호스트) 간에 트래픽을 전달합니다.

2024-5-26 • tag-icon

Strongswan은 두 개의 IPsec 터널(그 중 하나는 호스트) 간에 트래픽을 전달합니다.

설명된 것과 비슷한 문제에 직면해 있습니다.여기, 하지만 이 솔루션은 내 시나리오에서는 작동하지 않습니다.

나는 가지고있다

VPN 서버 A의 고정 외부 IP 주소는 AA.AA.AA.AA, 내부 IP 주소는 192.168.1.1, 내부 서브넷은 192.168.1.0/24입니다.
VPN 서버 B에는 동적 외부 IP 주소 BB.BB.BB.BB, 내부 IP 192.168.2.254 및 내부 서브넷 192.168.2.0/24가 있습니다.
VPN에 연결된 경우 동적 외부 IP 주소 MM.MM.MM.MM 및 IP 192.168.250.129를 사용하는 모바일 장치

A와 B 사이에서 두 서브넷은 VPN을 통해 투명하게 라우팅되며 제대로 작동합니다.

모바일 장치는 A에 연결하고 192.168.250.128/25 서브넷에서 IP 주소를 받습니다. 모바일 장치는 192.168.1.0/24 서브넷의 모든 장치와 정상적으로 통신할 수 있지만(반대의 경우도 마찬가지) 192.168.2.0/24의 어떤 장치와도 통신할 수 없습니다.

A에서는 도착하는 패킷을 볼 수 있습니다.

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
19:28:31.367911 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 0, length 64
19:28:32.469991 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 1, length 64
19:28:33.410002 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 2, length 64
19:28:34.389997 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 3, length 64
19:28:35.449973 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 4, length 64

B에서는 패킷이 캡처되지 않습니다.

흥미롭게도 데이터를 다른 방향(예: 192.168.2.0/24 서브넷의 호스트에서 모바일 장치로)으로 보내는 것이 더 잘 작동하는 것 같습니다.

B에서 캡처:

hanjo@B:~$ sudo tcpdump -n net 192.168.250.0/24
20:44:27.201713 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 0, length 64
20:44:28.202222 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 1, length 64
20:44:29.202355 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 2, length 64
20:44:30.202603 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 3, length 64

A에서 캡처:

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
20:42:28.897441 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:29.897510 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:29.897962 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:30.897469 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:30.897918 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:31.897458 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64
20:42:31.897911 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64

그러나 보시다시피 에코 응답이 수신되지 않습니다.

이것은 내 Strongswan 구성입니다.

A의 ipsec.conf:

conn B-tunnel
    left=AA.AA.AA.AA
    leftid="@A"
    right=B.dyndns
    rightid="@B"
    leftsubnet=192.168.1.0/24,192.168.250.0/24
    rightsubnet=192.168.2.0/24
    keyexchange=ikev2
    type=tunnel
    authby=secret
    auto=route

conn rw-v2
    keyexchange=ikev2
    left=AA.AA.AA.AA
    leftid="@A"
    right=%any
    leftsubnet=192.168.1.0/24,192.168.2.0/24
    rightsourceip=192.168.250.128/25
    rightdns=192.168.1.1
    authby=secret

conn mobile
    also=rw-v2
    auto=add
    rightid="@mobile"

B의 ipsec.conf:

conn A-tunnel
    left=192.168.2.254
    leftsubnet=192.168.2.0/24
    leftid=@B
    right=AA.AA.AA.AA
    rightsubnet=192.168.1.0/24,192.168.250.0/24
    rightid=@A
    authby=secret
    type=tunnel
    auto=start

A의 추가 정보:

hanjo@A:~$ sudo ipsec statusall
Status of IKE charon daemon (weakSwan 5.2.2, Linux 3.10.20, mips64):
  uptime: 7 hours, since Jan 08 14:50:14 2017
  malloc: sbrk 586896, mmap 0, used 376264, free 210632
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 44
  loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
Virtual IP pools (size/online/offline):
  192.168.250.128/25: 126/1/1
Listening IP addresses:
  AA.AA.AA.AA
  192.168.1.1
Connections:
B-tunnel:  AA.AA.AA.AA...B.dyndns  IKEv2, dpddelay=30s
B-tunnel:   local:  [A] uses pre-shared key authentication
B-tunnel:   remote: [B] uses pre-shared key authentication
B-tunnel:   child:  192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 TUNNEL, dpdaction=restart
      mobile:  AA.AA.AA.AA...%any  IKEv2, dpddelay=15s
      mobile:   local:  [A] uses pre-shared key authentication
      mobile:   remote: [mobile] uses pre-shared key authentication
      mobile:   child:  192.168.1.0/24 192.168.2.0/24 === dynamic TUNNEL, dpdaction=clear
Routed Connections:
B-tunnel{5}:  ROUTED, TUNNEL
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24
Security Associations (6 up, 0 connecting):
      mobile[55]: ESTABLISHED 104 seconds ago, AA.AA.AA.AA[A]...MM.MM.MM.MM[mobile]
      mobile[55]: IKEv2 SPIs: 4dc26b00764d7fbf_i f00fd36247594b6a_r*, pre-shared key reauthentication in 106 minutes
      mobile[55]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
      mobile{36}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c1012a86_i 08a38525_o
      mobile{36}:  AES_CBC_256/HMAC_SHA1_96, 15163 bytes_i (100 pkts, 66s ago), 55569 bytes_o (78 pkts, 87s ago), rekeying in 44 minutes
      mobile{36}:   192.168.1.0/24 192.168.2.0/24 === 192.168.250.129/32
B-tunnel[19]: ESTABLISHED 6 hours ago, AA.AA.AA.AA[A]...BB.BB.BB.BB[B]
B-tunnel[19]: IKEv2 SPIs: 97ef622accd69b0a_i* b1cd574224dcba1c_r, rekeying in 80 minutes, pre-shared key reauthentication in 70 minutes
B-tunnel[19]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
B-tunnel{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cbd873b7_i cebce241_o
B-tunnel{5}:  AES_CBC_256/HMAC_SHA2_512_256, 518363 bytes_i (3670 pkts, 0s ago), 274095 bytes_o (3733 pkts, 0s ago), rekeying in 21 minutes
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24

hanjo@A:~$ sudo ip xfrm policy
src 192.168.250.129/32 dst 192.168.2.0/24 
    dir fwd priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.2.0/24 
    dir in priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.129/32 
    dir out priority 2851 
    tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
    dir fwd priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
    dir in priority 2851 
    tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
        proto esp reqid 36 mode tunnel
src 192.168.1.0/24 dst 192.168.250.129/32 
    dir out priority 2851 
    tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
        proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir fwd priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir in priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir out priority 2883 
    tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir fwd priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir in priority 2883 
    tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
        proto esp reqid 5 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir out priority 2883 
    tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
        proto esp reqid 5 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 

hanjo@A:~$ sudo ip route
default via AA.AA.AA.1 dev eth0  proto zebra 
AA.AA.AA.0/30 dev eth0  proto kernel  scope link 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1 

hanjo@A:~$ sudo ip route show table 220
192.168.2.0/24 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1 
192.168.250.129 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1

B가 제공한 추가 정보:

hanjo@B:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 4.4.23+, armv6l):
  uptime: 24 hours, since Jan 07 22:19:36 2017
  malloc: sbrk 663552, mmap 0, used 246232, free 417320
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12
  loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Virtual IP pools (size/online/offline):
Listening IP addresses:
  192.168.2.254
Connections:
    A-tunnel:  192.168.2.254,0.0.0.0/0,::/0...AA.AA.AA.AA,0.0.0.0/0,::/0  IKEv2, dpddelay=30s
    A-tunnel:   local:  [B] uses pre-shared key authentication
    A-tunnel:   remote: [A] uses pre-shared key authentication
    A-tunnel:   child:  192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
       A-tunnel[11]: ESTABLISHED 6 hours ago, 192.168.2.254[B]...AA.AA.AA.AA[A]
       A-tunnel[11]: IKEv2 SPIs: 0a9bd6cc2a62ef97_i 1cbadc244257cdb1_r*, pre-shared key reauthentication in 79 minutes
       A-tunnel[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
       A-tunnel{12}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cebce241_i cbd873b7_o
       A-tunnel{12}:  AES_CBC_256/HMAC_SHA2_512_256, 275930 bytes_i (3754 pkts, 0s ago), 523881 bytes_o (3728 pkts, 0s ago), rekeying in 22 minutes
       A-tunnel{12}:   192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24

hanjo@B:~$ sudo ip xfrm policy
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir fwd priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
    dir in priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
    dir out priority 2883 
    tmpl src 192.168.2.254 dst AA.AA.AA.AA
        proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir fwd priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
    dir in priority 2883 
    tmpl src AA.AA.AA.AA dst 192.168.2.254
        proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
    dir out priority 2883 
    tmpl src 192.168.2.254 dst AA.AA.AA.AA
        proto esp reqid 12 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 

hanjo@B:~$ sudo ip route
default via 192.168.2.1 dev eth0 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.254 

hanjo@B:~$ sudo ip route show table 220
192.168.1.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254 
192.168.250.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254

문제가 무엇인지 아시나요?

답변1

잘못된 것 같습니다.

20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64

A가 B의 트래픽을 전달하는 중인데 A의 공용 IP에서 모바일 클라이언트로 ICMP가 있는 이유는 무엇입니까? 공용 IP가 있는 ESP 패킷을 기대하지만 확실히 ICMP는 아닙니다.

A에 NAT 규칙이 있습니까? 그렇다면 꼭 이용해 보세요.정책모듈은 실제 NAT 규칙에서 IPsec 정책과 일치하는 트래픽을 제외합니다. 기본적으로 다음과 같은 것을 추가하십시오.앞으로실제 NAT 규칙(또한강한 백조 위키):

iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT

답변1

관련 정보