VPN 게이트웨이의 알려진 문제

알려진 이슈는 출시 전에 수정되지 않았지만 출시를 지연시킬 만큼 중요하지 않은 버그 또는 예상치 못한 동작이 확인된 경우입니다. 이러한 문제는 종종 해결 방법과 함께 사용자에게 전달되며, 개발팀에서 빠른 시일 내에 해결하도록 우선순위를 정합니다.

사이트 간 VPN 게이트웨이의 알려진 문제는 다음과 같습니다:

• VPC용 VPN 게이트웨이는 IPsec ESP 패킷의 UDP 캡슐화가 적용된 VPN 패킷만 허용합니다. 보안 페이로드 캡슐화(ESP) 패킷은 허용되지 않습니다. NAT-T 기능이 온프레미스 VPN 디바이스에서 사용으로 설정되어 있는지 확인하십시오. 또한 UDP 포트 500 및 4500 포트가 IBM VPC NACL 및 피어 네트워크 모두에 허용되는지 확인하세요.

  NAT-T는 IPsec 패킷을 UDP 로 캡슐화하여 VPN 트래픽이 NAT 장치를 통과할 수 있도록 합니다. NAT-T를 사용하지 않으면 NAT 장치가 ESP 트래픽을 제대로 처리할 수 없기 때문에 IPsec 패킷이 삭제될 수 있습니다. NAT 장치에서 안정적인 VPN 연결을 얻으려면 온프레미스 장치에서 NAT-T를 사용하도록 설정해야 합니다.

• 여러 네트워크, 서브넷 또는 둘 모두가 IBM Cloud VPN 게이트웨이 또는 온프레미스 장치와 연결되어 있는 경우 정책 기반 및 라우트 기반 VPN을 혼합하지 마십시오. 정책 기반 VPN은 각 대상 네트워크 범위에 대한 터널을 작성합니다. 그러나 라우트 기반 VPN은 단일 터널을 통해 모든 것을 피어 디바이스로 라우팅합니다. 따라서 여러 네트워크 범위가 구성된 경우 단일 네트워크 범위와 연결된 단일 터널만 설정할 수 있습니다. 인접한 서브넷을 단일 상위 집합 CIDR로 결합하는 것은 유효한 해결 방법입니다.

• VPN 게이트웨이 연결의 피어 서브넷은 겹칠 수 없습니다.

• Transit Gateway 접두사 필터링은 현재 VPN 게이트웨이에서 지원되지 않습니다.

• 정책 기반 VPN을 경로 기반 피어와 연결할 때(또는 정적 경로 기반 VPN을 정책 기반 피어와 연결할 때) 양쪽 모두에 단일 네트워크 범위만 사용하세요. 정책 기반 VPN은 연결된 각 네트워크에 대해 하나의 터널을 사용하는 반면, 경로 기반 VPN은 하나의 터널만 필요합니다. 양쪽의 여러 네트워크 범위와 연결된 서로 다른 유형의 VPN 간 연결은 하나의 네트워크 범위에서만 작동할 수 있습니다.

  

  가능하면 VPN 구성에서 연속 서브넷을 단일 네트워크 범위로 결합하십시오. 예를 들어, 서브넷 192.168.0.0/24 및 192.168.1.0/24는 VPN 또는 라우팅 구성에서 192.168.0.0/23으로 정의될 수 있습니다.

• IBM Cloud 정책 기반 VPN 게이트웨이는 프로비저닝 중에 선택한 서브넷과 연관된 구역에 상주합니다. VPN 게이트웨이는 VPC의 동일한 영역에 있는 가상 서버 인스턴스에만 서비스를 제공합니다. 따라서 다른 구역에 있는 인스턴스는 VPN 게이트웨이를 사용하여 온프레미스 사설 네트워크와 통신할 수 없습니다. 구역 결함 허용의 경우 구역별로 하나의 VPN 게이트웨이를 배치하십시오.

• IBM Cloud 라우트 기반 VPN 게이트웨이는 프로비저닝 중에 선택한 서브넷과 연관된 구역에 상주합니다. VPN 게이트웨이는 VPC의 동일한 구역 내에 있는 가상 서버 인스턴스만 서비스하는 것이 좋습니다. 라우팅 테이블에 사용자 지정 송신 경로를 추가하여 트래픽을 전달하면 다른 영역의 인스턴스가 경로 기반 VPN 게이트웨이를 사용하여 온프레미스 사설 네트워크와 통신할 수 있지만, 이 설정은 권장되지 않습니다. 구역 결함 허용의 경우 구역별로 하나의 VPN 게이트웨이를 배치하십시오.

• 사이트 간 IPsec VPN 연결을 구성하고 최적화할 때 네트워크 성능 문제가 발생할 수 있습니다. 이 중 하나는 최대 전송 단위 (MTU) 및 최대 세그먼트 크기 (MSS) 클램핑과 관련되어 있습니다. 자세한 정보는 IBM 사이트 간 VPN MTU(Maximum Transmission Unit)클램핑 을 참조하십시오.

• 경로가 다음 홉으로 VPN 게이트웨이 연결을 사용하는 경우, 해당 연결은 VPC 서브넷과 연결된 송신 라우팅 테이블에 존재해야 합니다. 또한 VPN 게이트웨이가 트래픽을 VPN 터널로 전달할 때, 이 트래픽의 소스 IP가 해당 라우팅 테이블에 연결된 서브넷 내에 있는지 확인합니다. 소스 IP가 해당 서브넷 외부에 있는 경우, 트래픽은 암호화되지 않으며 VPN 터널을 통해 피어 게이트웨이로 전송되지도 않습니다. 예를 들어, VPN 게이트웨이가 수신 라우팅 테이블을 통해 라우팅되는 트래픽을 수신하는 경우, 소스 IP가 라우팅 테이블에 연결된 서브넷 외부에 있기 때문에 트래픽이 VPN 터널로 전달되지 않습니다.

  다음 홉으로 VPN 게이트웨이 연결을 사용하여 인그레스 라우팅 테이블에 경로를 생성하는 것은 지원되지 않습니다.

• VPN 게이트웨이를 생성할 때 로컬 및 피어 IKE ID(주소, FQDN 또는 호스트 이름)를 설정하는 것은 선택 사항입니다. 하지만 나중에 피어 주소 또는 FQDN을 업데이트하면 VPN 연결에 영향을 미칠 수 있습니다:

  • 로컬 및 피어 IKE ID를 지정하지 않으면 게이트웨이가 자동으로 기본값을 사용합니다. VPN 게이트웨이의 공용 IP가 로컬 IKE ID로 사용되고 피어 게이트웨이의 공용 IP가 피어 IKE ID로 사용됩니다. 이 기본 설정은 피어 주소가 변경되더라도 안정적인 VPN 연결을 유지하는 데 도움이 됩니다.
  • 로컬 및 피어 IKE ID를 명시적으로 설정하면 특정 값을 잠그게 됩니다. 이 경우 연결이 끊어지지 않도록 피어 주소 또는 FQDN을 업데이트하려면 VPN 연결을 삭제하고 다시 만들어야 합니다.