VPN은 EC2 인스턴스에서 종료되고, 그 인스턴스의 터널 주소에는 도달할 수 있지만, 그것을 거쳐 다른 프라이빗 호스트로 가야 할 트래픽은 사라집니다. 이는 서로 다른 두 시험이며, 둘을 섞으면 몇 시간을 허비합니다. 첫 번째는 인스턴스에 도달할 수 있는지 묻고, 두 번째는 자기 것이 아닌 대상에 대해 트래픽을 전달하라고 요구하며, 후자에는 Linux 전달, 방화벽 정책, 반대편 경로, 그리고 게스트 운영 체제와 아무 관련이 없는 AWS 수준의 권한이 필요합니다. 콘솔 어디에서도 그 차이를 주목하게 만들지 않습니다. 증상은 라우팅 결함처럼 보이지만 대개 그렇지 않습니다.

무엇이든 바꾸기 전에 두 시험을 분리하십시오

게이트웨이에 도달한다는 것은 터널, 그 주소로 가는 경로, 교환을 허용하는 보안 그룹을 증명합니다. 다른 호스트에 대한 전달은 다른 소스 주소, 다른 대상, 그리고 반드시 그 역할을 위해 만들어진 것은 아닌 인스턴스를 사용하므로 그중 어느 것도 증명하지 않습니다. 두 시험을 따로 적고 어느 쪽이 실패하는지 기록하십시오. 각각의 교정은 다른 콘솔에 있고, 터널을 종료하기 위해서만 만들어진 게이트웨이 인스턴스에는 다른 무엇을 전달할 이유가 없으므로 그 기본값도 이를 반영합니다. 그래서 두 번째 시험에는 첫 번째에 대한 작은 조정이 아니라 자체 설정이 필요합니다.

게이트웨이로는 통하는 ping과 그 너머의 호스트로는 실패하는 ping은 간헐적 문제가 아닙니다. 전달해도 된다고 들은 적 없는 인스턴스의 예상된 동작입니다.

설정을 건드리기 전에 경로를 적으십시오

클라이언트 접두사, 전달 인스턴스 또는 네트워크 인터페이스, 대상 서브넷, 응답 경로를 기록하십시오. 인스턴스를 가리키는 VPC 라우팅 테이블 항목은 인스턴스의 운영 체제를 전달하도록 구성하지 않으며, 전달이 켜진 게스트 커널은 VPC 경로를 만들지 않습니다. 그 관계의 양쪽 끝이 모두 존재해야 하며, 그것들은 서로 다른 곳에서 서로 다른 권한을 가진 사람들에 의해 편집됩니다.

그다음 소스/대상 확인 설정을, VPC의 모든 인스턴스가 아니라 실제 전달 구성 요소에서 확인하십시오. AWS는 다른 사람을 위해 트래픽을 전달하는 인스턴스에 이 확인이 꺼져 있어야 하는 이유와, 이 설정이 VPC 전체의 기본값이 아니라 인스턴스별 결정인 이유를 문서화합니다.

네 개의 경계가 있고, 확인은 그중 하나일 뿐입니다

경로를 네 개의 질문으로 다루고 순서대로 답하십시오. 처음 실패하는 답이 작업이 있는 곳이며, 나머지 어느 것도 그것을 보상하지 않습니다.

BoundaryQuestion it answers
VPC route tablesDo the destinations and replies select the intended gateway?
Forwarding instanceDo the AWS check and the guest OS both permit forwarding?
Access policyDo security groups, ACLs and host rules allow the exchange?
DestinationCan the service accept that source and return a reply?

순서가 중요한 이유는 확인이 저렴하기 때문이며, 경로는 한 페이지에서 보이고 확인은 하나의 속성이고 대상의 의견은 대개 사람들이 마지막으로 묻는 것입니다.

번역은 대상이 보는 소스를 바꿉니다

라우팅 설계는 클라이언트의 소스 주소를 유지하므로, 대상에는 클라이언트 접두사로 가는 반환 경로가 필요합니다. 번역 설계는 대신 게이트웨이 주소를 제시하며, 이는 그 요구를 없애고 게이트웨이의 상태 테이블로 대체합니다. 관련 없는 예제가 그것을 써서 동작한 것처럼 보였다고 번역을 추가하지 말고, 의도한 아키텍처에 따라 결정하십시오.

번역한다면 규칙을 클라이언트 접두사와 의도한 대상으로 한정하십시오. 유지한다면 반대편이 경로를 정말 아는지 확인하고, 배울 것이라고 가정하지 마십시오.

원래 클라이언트에서 시험한 다음 변경을 유지하십시오

게이트웨이에서 생성한 요청은 소스가 다르고 전달 사례가 다르기 때문에 성공하는데 전달된 요청은 실패할 수 있습니다. 목표한 교정 후에는 실패했던 바로 그 클라이언트-대-리소스 시험을 같은 클라이언트에서 반복하고, 요청이 도착했을 뿐 아니라 응답이 돌아오는지 확인하십시오.

마지막으로 그 설정을 게이트웨이의 관리형 구성에 넣어 교체 인스턴스가 받도록 하십시오. 수동 예외에 의존하는 성공한 시험은 다음 재구축에서 만료되는 시험이며, 그것을 발견한 사람은 이유를 기억하려고 거기에 있지 않을 것입니다.

관련 글