AWS NAT 게이트웨이에서 GRE와 ESP가 실패하는 이유

터널이 실패하고, 보안 그룹은 이미 모든 트래픽을 허용하며, 결론은 AWS가 VPN을 차단한다는 것입니다. AWS는 아무것도 차단하지 않습니다. 관리형 NAT 게이트웨이는 문서화된 외부 프로토콜 집합을 전달하며, 기본 GRE나 기본 ESP는 그 안에 없으므로 추가하는 어떤 규칙도 게이트웨이가 그것들을 전달하게 만들지 못합니다. 허용 규칙과 전송 능력은 서로 다른 것이며, 둘 중 하나만 바꿀 수 있습니다.

규칙 집합은 프로토콜 집합이 아닙니다

보안 그룹은 어떤 트래픽이 인스턴스를 떠날 수 있는지 결정합니다. NAT 게이트웨이는 무엇을 변환하고 전달할 수 있는지 결정합니다. 두 번째 한계가 적용되면 허용적인 규칙은 사람들이 방화벽 문제로 잘못 읽는 증상을 정확히 만들어 냅니다. 패킷은 인스턴스를 떠나고, 제어 교환은 완료될 수도 있으며, 상대편에는 아무것도 도착하지 않습니다.

AWS의 NAT 게이트웨이 프로토콜 사양은 관리형 서비스에 대해 TCP, UDP, ICMP를 나열합니다. 그것이 지원되는 전체 집합입니다. 다른 IP 프로토콜에 대한 허용 규칙은 이를 확장할 수 없습니다. 규칙은 게이트웨이의 전달 경로에 도달하기 훨씬 전에 평가되기 때문입니다.

이 구분이 중요한 이유는 두 실패가 클라이언트 쪽에서 동일하게 보이지만 수정 방법은 완전히 다르기 때문입니다.

PPTP는 포트 테스트가 거짓말하는 이유를 보여줍니다

PPTP는 아무것도 증명하지 못하는 포트 검사의 가장 명확한 과거 사례입니다. 1723번 포트에서 TCP 제어 연결을 열고, 그다음 터널 데이터를 IP 프로토콜 47인 GRE로 전달합니다. 프로토콜 47은 TCP 포트 47이 아니며, 두 숫자는 숫자를 공유한다는 것 외에는 서로 관련이 없습니다.

1723으로의 연결을 시험하고 핸드셰이크가 완료되는 것을 본 운영자는 경로가 작동한다고 결론짓습니다. 그러면 데이터 채널은 단 하나의 패킷도 통과하지 못합니다. 게이트웨이에 제공할 GRE 지원이 없기 때문입니다. 이것은 오래된 프로토콜 요구 사항에 대한 해석이며, 수년 전에 폐기된 PPTP를 도입하라는 조언이 아닙니다.

제어 채널이 TCP나 UDP이면서 데이터 경로는 그렇지 않은 모든 프로토콜에 같은 논리가 적용됩니다.

IPsec은 UDP로만 살아남습니다

IPsec은 답이 단호한 아니오가 아니라 조건부인 경우입니다. AWS는 NAT 게이트웨이를 통한 IPsec에 대해 NAT 트래버설을 지원되는 구성으로 문서화합니다. NAT-T가 협상되면 ESP는 UDP 안에 캡슐화되고 게이트웨이는 프로토콜 50 대신 일반 UDP를 봅니다.

UDP 4500을 허용한다고 해서 엔드포인트가 NAT 트래버설을 사용하게 되는 것은 아닙니다. 이미 그런 형태인 패킷만 허용할 뿐입니다. 클라이언트 자체의 협상 출력에서 어떤 캡슐화가 선택되었는지 확인하고, 수신 측에서 상대가 이를 수락했는지 확인하십시오. 기본 ESP로 설정된 두 엔드포인트는 규칙 집합이 무엇을 말하든 기본 ESP를 계속 보냅니다.

TCP나 UDP 기반 VPN은 문서화된 전송 집합에 맞으며, 그래도 라우팅, 필터링 또는 인증 이유로 실패할 수 있습니다. 집합에 맞는 것은 필요하지만 충분하지 않습니다.

정책을 넓히기 전에 경로를 확인하십시오

워크로드 서브넷의 실제 경로와 다음 홉의 정체를 먼저 확인하십시오. 직접 공용 경로, NAT 인스턴스, 관리형 NAT 게이트웨이, 전송 게이트웨이를 통한 사설 경로는 네 가지 다른 설계이며, 그중 하나만 여기서 설명하는 관리형 서비스입니다.

그런 다음 시도한 엔드포인트, 주소 체계, 외부 프로토콜, 프로토콜에 포트가 있으면 그 포트를 기록하십시오. 성공한 브라우저 요청 대신 클라이언트 진단과 네트워크 소유자의 흐름 관찰을 사용하십시오. 브라우저 요청은 TCP와 UDP가 작동한다는 것만 증명합니다. 그런 다음 흐름의 양방향에 대해 보안 그룹, 서브넷 ACL, 게스트 방화벽, 서비스 정책을 검토하십시오.

서비스가 전달할 수 없는 전송을 보상하려고 모든 트래픽을 열지 마십시오. 규칙 변경으로는 해결되지 않으며 사고 이후에도 남습니다.

전송이 맞지 않을 때

외부 프로토콜이 지원 집합 밖이라면 해결책은 아키텍처로, 경로가 전달할 수 있는 전송을 선택하거나 필요한 것을 전달하는 대상으로 송신 경로를 옮기십시오. OpenVPN UDP, WireGuard의 UDP, TLS 기반 터널은 모두 문서화된 집합에 맞습니다. 특정 프로토콜이 반드시 통과해야 하고 운영 비용이 수용 가능하다면 고객 관리 NAT 인스턴스가 선택지입니다.

인바운드 VPN 서버 호스팅은 별도의 답이 있는 별개의 문제입니다. NAT 게이트웨이는 아웃바운드 변환을 제공하고 일반적인 인바운드 포트 포워딩은 제공하지 않으므로, 그 뒤의 서버는 자체 조건에 맞게 설계된 승인된 공용 진입점이 필요합니다.

작업 순서는 외부 프로토콜을 명명하고, 다음 홉을 확인하고, 문서화된 집합과 비교한 뒤 아키텍처나 전송을 바꾸는 것입니다. 다른 포트 번호로 GRE가 TCP가 되지 않으며, 허용 규칙을 하나 더 추가해도 완료된 제어 교환이 작동하는 데이터 채널이 되지 않습니다.