GCP VM이 OpenVPN IPv6 풀에 응답하지 못하는 이유

IPv6 VPN 클라이언트가 워크로드에 도달하고, 워크로드는 터널 안으로 응답하지만 그 응답은 끝내 도착하지 않습니다. 방화벽이나 터널을 의심하게 되지만 보통 둘 다 원인이 아닙니다.OpenVPN이 할당한 주소는 터널 내부에만 존재하는 내부 네트워크이며, Google Cloud는 fd42:90::/64가 특정 VM 뒤에 있어야 한다는 사실을 알려주기 전까지 전혀 모릅니다.

이 사실을 배워야 하는 시스템은 두 개이며 그중 하나만 OpenVPN입니다. VPC는 무언가를 되돌려 보내기 전에 경로가 필요하고, VM은 도착한 것을 포워딩할 수 있어야 합니다. 어느 한쪽만 틀려도 증상은 똑같아 보입니다.

풀은 서브넷이 아니라 내부 네트워크

OpenVPN은 선택한 범위에서 IPv6 주소를 할당할 수 있으며, 그 범위는 터널 양 끝이 합의한 허구입니다. Google Cloud 서브넷이 아니고 VPC 서브넷 목록에도 나타나지 않으며, VM의 네트워크 인터페이스가 그 주소를 얻지도 않습니다. 따라서 클라이언트에 응답하는 워크로드는 네트워크가 라우팅 불가로 보는 주소로 패킷을 보냅니다.

풀은 VPC가 이미 사용하는 모든 범위 밖에 두십시오. 다른 터널 뒤의 범위 밖에도 두십시오. 겹치면 깔끔한 라우팅 실패가 부하에서만 나타나는 간헐적 실패로 바뀝니다.

fd42:90::/64 같은 고유 로컬 주소 지정은 이 내부 네트워크에 합리적인 선택입니다. 이 프리픽스는 설계가 원래 사설이라는 점도 상기시킵니다. ULA 풀이라는 이유로 공용 인터넷에서 정당한 소스가 되는 것은 아닙니다.

VPC에 목적지와 다음 홉을 주십시오

응답에는 목적지가 풀이고 다음 홉이 VPN VM인 VPC 경로가 필요합니다. 현재 정적 경로 문서는 IPv6 목적지 범위를 다루고 어떤 다음 홉 유형이 자격이 있는지 나열하므로, 오래된 IPv4 예제를 복사하는 대신 토폴로지에 지원되는 형식을 확인하십시오.

다음 홉 주소는 실제로 인스턴스의 클라우드 인터페이스에 할당된 주소여야 합니다. VM의 내부 터널 주소는 그 주소가 아닙니다. 그래도 사용하면 깔끔하게 설치되지만 어떤 패킷과도 일치하지 않는 경로가 만들어집니다. 경로를 작성하기 전에 인터페이스 목록을 읽으십시오.

경로 우선순위는 항목 자체만큼 중요합니다. 서브넷 경로는 추가하는 사용자 지정 경로보다 더 구체적이므로, 기존 서브넷 범위에서 잘라낸 풀은 사용자 지정 경로를 어떻게 작성하든 서브넷 경로에 집니다. 별도의 풀을 고르고, 그다음 경로가 인스턴스를 다음 홉으로, 올바른 목적지 프리픽스를 표시하는지 확인하십시오:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

포워딩은 두 번 활성화해야 합니다

경로는 패킷을 인스턴스로 전달합니다. 자신에게 주소 지정되지 않은 것을 포워딩하도록 인스턴스를 만들어 주지는 않으며, 그 권한은 두 계층에 존재합니다.

클라우드 측에는 VM이 소유하지 않은 주소의 트래픽을 받아 전달할 수 있게 하는 인스턴스 포워딩 기능이 활성화되어 있어야 합니다. 게스트 측에는 자체 IPv6 포워딩이 필요한데, 이는 패킷이 도착한 뒤 커널이 별도로 판단하기 때문입니다. 응답 하나가 터널을 건너기 전에 둘 다 켜져 있어야 합니다.

sysctl -w net.ipv6.conf.all.forwarding=1

그다음 방화벽 규칙이 내부 소스 범위를 양방향으로 허용해야 합니다. Google Cloud는 캡슐이 해제된 패킷을 평가하므로, VPC 서브넷만 다루는 규칙은 터널이 이미 성공한 뒤에 풀 트래픽을 버립니다. 인그레스 규칙에 풀을 소스 범위로 추가하고, 사용자 지정 이그레스 정책이 응답을 차단하지 않는지 확인하십시오. 암시적 허용 규칙은 기본 사례를 다루지만 손으로 쓴 이그레스 규칙은 그렇지 않습니다.

OpenVPN에 누가 무엇을 소유하는지 알려주십시오

OpenVPN은 해당 클라이언트가 목적지를 소유한다는 것을 알 때 그 클라이언트로 포워딩합니다. 풀의 클라이언트 주소는 풀을 정의하는 서버 지시문이 처리하지만, 클라이언트 뒤의 서브넷은 다른 배치이며 그 클라이언트에 대한 명시적 소유 항목이 필요합니다.

둘을 혼동하면 서버로의 핑은 되고 그 뒤는 아무것도 안 되는 터널이 됩니다. 어떤 사례를 만드는지 결정하고, 두 번째 push 줄을 추가해 기대하는 대신 맞는 항목을 작성하십시오.

인터넷 이그레스는 이 설계에서 제외하십시오

사설 액세스와 인터넷 액세스는 별개의 계획입니다. ULA 풀은 라우팅과 포워딩이 맞으면 터널을 통해 VPC 워크로드에 도달할 수 있지만, 같은 풀이 VPC를 통해 공용 인터넷으로 나가는 경로는 없는데, 이는 클라우드 게이트웨이가 임의의 터널 소스를 자기 것으로 받아들이지 않기 때문입니다.

클라이언트에 인터넷 이그레스도 필요하면 그에 맞는 지원되는 주소 지정과 라우팅 설계를 계획하고, 사설 풀과 독립적으로 유지하며 두 경로를 따로 테스트하십시오. 한 경로가 동작한다고 다른 경로에 대해 알 수 있는 것은 없고, 둘을 혼동한 설계는 고장 난 터널처럼 보이는 방식으로 실패합니다.