AWS Client VPN: 로그인은 되지만 서브넷에 닿지 않는다

클라이언트는 Connected라고 하고 인증서도 유효한데 인트라넷 페이지는 여전히 시간 초과로 끝납니다. 이 간극은 거의 인증 문제가 아닙니다. AWS Client VPN은 로그인과 별개로 대상을 승인하며, 흔한 두 원인은 ID 공급자가 보낸 값과 맞지 않는 그룹 값과 넓은 규칙을 이기는 더 구체적인 대상 규칙입니다. 어디를 봐야 할지 알면 둘 다 엔드포인트 구성에서 보입니다.

로그인은 성공했지만 규칙이 맞지 않았다

인증은 사용자가 누구인지 답합니다. 권한 부여 규칙 은 그 ID가 어떤 네트워크 접두사에 닿을 수 있는지 답합니다. 사용자는 첫 번째를 통과하고 두 번째에서 실패할 수 있으며, 클라이언트는 모든 요청이 시간 초과되는 동안 연결만 유지해 줄 뿐입니다.

실패하는 주소를 대상에 포함하는 권한 부여 규칙이 엔드포인트에 있는지 확인하는 것으로 시작하세요. 일치하는 규칙이 없으면 연결은 올바르게 동작하는 것이고, 정책이 없는 것입니다.

그룹 값은 실제로 어디에서 오는가

Active Directory에서는 access-group 필드에 그룹의 표시 이름이 아니라 SID가 들어갑니다. SAML 페더레이션에서는 구성된 SAML 그룹 속성이 실제로 전달하는 그룹 ID나 이름이 들어갑니다. 값은 어서션이나 디렉터리 조회에서 복사하고, 위키 페이지에서 가져오지 마세요.

IAM 그룹은 다른 제어 영역입니다. Client VPN 엔드포인트를 관리할 권한이 IAM 그룹을 사용자의 VPN 그룹으로 만들어 주지는 않으며, IAM 그룹 이름을 access-group 필드에 붙여 넣어도 AD SID나 SAML 속성 값으로 바뀌지 않습니다.

다른 디렉터리에 있는 비슷한 이름의 그룹은 아무것도 증명하지 못합니다. 엔드포인트의 인증 방식과 같은 시스템에서의 사용자 소속이나 어서션을 확인하세요.

가장 긴 접두사가 이긴다, 0.0.0.0/0 포함

권한 부여는 가장 긴 접두사 일치로 평가되고, 모든 대상 규칙은 먼저가 아니라 마지막에 평가됩니다. Engineering에 10.46.0.0/16 규칙을, 모두에게 0.0.0.0/0 규칙을 추가해도 Engineering 밖의 사용자는 넓은 규칙으로 10.46.20.10에 닿지 못합니다.

바로 여기서 수정이 잘못될 수 있습니다. 좁은 규칙을 지우면 사용자의 액세스가 돌아오고, 동시에 넓은 규칙이 포괄하는 모든 ID에 그 서브넷이 주어집니다. 무언가를 지우기 전에 그룹 대 네트워크 매트릭스를 만들고, 어느 그룹이 어느 범위에 닿아야 하는지 적어 두세요. 이 규칙은 허용만 합니다. 넓은 허용에서 예외를 잘라내는 거부 항목은 없습니다.

변경은 공정하게 판단되려면 새 연결도 필요합니다. 규칙을 편집한 뒤 클라이언트를 다시 연결하고, 그다음 다시 시험하세요.

권한 부여와 데이터 경로를 분리하라

일치하는 규칙은 경로가 아니다. 엔드포인트에는 연결된 서브넷과 대상에 대한 라우팅 테이블 항목이 필요하고, 대상 리소스의 보안 그룹이 트래픽을 받아들여야 합니다. 반환 트래픽과 DNS도 동작해야 합니다.

성공해야 할 사용자와 계속 제외되어야 할 사용자를 시험하세요. 둘 다 로그인할 수 있지만 한 명만 서브넷에 닿고, 그 차이가 바로 원하는 증거입니다.

IP 주소는 되는데 호스트 이름이 안 된다면, 권한 부여를 건드리기 전에 리졸버를 보세요. 어떤 경로도 주소를 덮지 않으면 연결이나 라우팅 테이블을 고치세요. 패킷이 도착했는데 서비스가 거부하면 다음 지점은 그 서비스의 정책입니다. 권한 부여 매트릭스를 모든 사용자로 넓히면 어느 계층이 실제로 깨졌는지가 가려집니다.

티켓을 닫기 전에 ID 출처, 정확한 그룹 값, 대상 접두사, 트래픽을 실어 나르는 경로를 기록하세요. 그 기록이 있으면 다음 연결됨 그러나 접근 불가 보고는 또 한 차례 추측이 아니라 몇 분짜리 대조가 됩니다.