xfrm 인터페이스의 패킷은 라우팅되지 않지만 반대 작업은 수행됩니다.

2024-6-23 • tag-icon

저는 사이트 간 VPN을 개발 중입니다. 하나는 UDM이고 다른 하나는 Strongswan입니다. 목표는 클라우드 환경에 양방향 라우팅을 제공하는 것입니다. 왜 이것이 작동하지 않는지 완전히 당황했습니다.

좋은 소식은 Strongswan이 연결되어 트래픽을 전달한다는 것입니다. 하지만 Strongswan 측에는 라우팅 문제가 있습니다. 내 Strongswan 호스트에는 eth0에 공용 인터넷 IP가 있는 eth0과 eth1에 10.132.169.74의 내부 IP가 있는 두 개의 인터페이스가 있습니다.

LAN 네트워크: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
클라우드 네트워크: 10.132.0.0/16
10.87.0.1 = UDM
10.132.169.74 = Strongswan eth1이며 내부 클라우드 네트워크 10.132.0.0/16에 연결됩니다.
10.87.0.33 = LAN 네트워크의 호스트 테스트
10.132.40.82 = 클라우드 네트워크의 테스트 호스트

현재 상황:

10.87.0.33(Lan 테스트 호스트) -> 10.132.169.74(Strongswan)에서 ping을 실행하면 작동합니다.
10.132.169.74(Strongswan) -> 10.87.0.33(Lan 테스트 호스트)에서 ping을 실행하면 작동합니다.
10.132.40.82(클라우드 테스트 호스트) -> 10.87.0.33(Lan 테스트 호스트)에서 ping을 실행하면 작동합니다.
10.87.0.33(Lan 테스트 호스트) -> 10.132.40.82(클라우드 테스트 호스트)에서 ping을 실행하면 작동하지 않습니다. 이것이 이 모든 것에서 가장 중요한 것입니다.

Strongswan 호스트 10.132.169.74의 라우팅 테이블은 다음과 같습니다.

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.21 
10.19.49.0/24 dev wg0 proto kernel scope link src 10.19.49.1 
10.87.0.0/16 dev ipsec0 scope link src 10.132.169.74 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.169.74 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z

클라우드 테스트 호스트(10.132.40.82)의 라우팅 테이블은 다음과 같습니다.

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.24 
10.87.0.0/16 via 10.132.169.74 dev eth1 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.40.82 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z

Strongswan 호스트에서 다음을 실행합니다.

sudo ip link add ipsec0 type xfrm dev eth0 if_id 4242
sudo ip link set ipsec0 up
sudo ip route add 10.87.0.0/16 dev ipsec0 src 10.132.169.74

마지막으로 내 백조 구성은 다음과 같습니다.

sudo tee /etc/strongswan.d/charon-systemd.conf  << "EOF"
charon-systemd {
  load=pem pkcs1 x509 revocation constraints pubkey openssl random random nonce aes sha1 sha2 hmac pem pkcs1 x509 revocation curve25519 gmp curl kernel-netlink socket-default updown vici
  journal {
    default=0
    # enc=1
    # asn=1
  }
}
EOF

sudo tee /etc/swanctl/conf.d/xyz.conf << "EOF"
connections {
  vpn-cloud-udm-lan {
    version=2
    proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
    unique=replace
    encap=yes
    local {
      id=x.x.x.x
      auth=psk
    }
    remote {
      auth=psk
    }
    children {
      net {
        local_ts=10.132.0.0/16
        remote_ts=10.87.0.0/16
        esp_proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
        start_action=trap
        if_id_in=4242
        if_id_out=4242
      }
    }
  }
}
secrets {
  ike-1 {
    id-vpn-cloud=x.x.x.x
    secret="somesecret"
  }
  ike-2 {
    id-udm-lan=y.y.y.y
    secret="somesecret"
  }
}
EOF

Strongswan 호스트의 내 sysctl은 다음과 같습니다.

net.ipv4.ip_forward=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

sudo swanctl --list-sas활성 터널이 표시되고 핑을 하면 카운터가 올라가는 것을 볼 수 있습니다. 또한 클라우드 테스트 호스트에서 수신 대기하는 tcpdump에는 도착하는 트래픽이 표시되지 않지만 특정 시나리오에서 Strongswan 호스트의 tcpdump에는 트래픽이 표시되므로 해당 위치에 삭제됩니다.

도움을 주시면 감사하겠습니다!

답변1

그래서 머리를 세게 부딪히고(록 음악에서 하는 그런 종류는 아님) 이를 갈고 난 후에 나는 다음 답변에서 그것을 알아냈습니다.https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates

Digital Ocean이 개인 인터페이스에서 패킷을 삭제하고 있었습니다. 그래서 10.87.0.0/24의 트래픽을 허용하는 방화벽 규칙을 추가했습니다. 그것은 WERX!!!

답변1

관련 정보