AWS Client VPN 엔드포인트 DNS: 확인된 IP를 고정하면 실패하는 이유

지난주 dig +short가 AWS Client VPN 프로필의 엔드포인트 이름에 대해 주소 하나를 알려 주었고, 터널이 연결되었습니다. 이번 주에는 같은 프로필이 노트북에서 'Connecting'에 머물러 있는데, 동료의 손대지 않은 복사본은 여전히 작동합니다. 아무것도 차단되지 않았고 인증서도 만료되지 않았습니다. 누군가 엔드포인트 호스트 이름을 그 확인된 주소로 바꾸었고, 서비스는 이제 그곳에서 응답하지 않습니다. 내보낸 이름은 그 변화를 견디도록 만들어진 부분입니다.

프로필의 이름이 질의되는 이름이 아닐 수 있습니다

Client VPN에서 내보낸 프로필에는 보통 remote-random-hostname가 들어 있습니다. 이 옵션이 켜져 있으면 클라이언트는 일회용 레이블을 만들고 점으로 엔드포인트 이름과 결합한 뒤 결합된 이름을 확인합니다. 엔드포인트 영역의 와일드카드 레코드가 어떤 레이블에도 응답하므로 지어낸 접두사도 확인되고, 손으로 쿼리를 재현하려 할 때 이 속임수가 보이지 않는 이유입니다.

따라서 엔드포인트 이름을 터미널에 붙여 답을 얻었다면, 클라이언트가 연결할 때 쓰는 이름과 다른 이름을 확인한 것입니다. 이 불일치는 프로필에서 고칠 결함이 아닙니다. 레이블은 의도적으로 다시 만들어집니다. 이 옵션은 캐시가 오래된 답을 붙잡지 못하게 하고, 사용자의 기기나 세션을 절대 식별하지 않습니다.

클라이언트가 이 옵션을 아예 무시하는 호환성 사례도 겪었습니다. AWS는 우회 방법을 문서화합니다. 실제 엔드포인트 이름을 유지하고 앞에 임의의 문자열과 점을 붙이되, 붙여 넣을 값이 아니라 이름 지정 패턴으로 다루라는 것입니다. 오래된 클라이언트에 적용하는 것은 합리적이지만, 접두사가 붙은 문자열을 엔드포인트로 하드코딩하는 것은 아닙니다.

저장된 답이 올바르게 남을 수 없는 이유

Client VPN 엔드포인트 주소는 AWS가 관리하고 시간이 지나면 바뀝니다. 모범 사례 문서도 분명히 말합니다. 캡처한 답은 한 번의 확인에 대한 스냅숏입니다. 그것을 하드코딩한 프로필은 서비스가 옮겨가는 순간 폐기된 호스트를 겨냥한 프로필이 되고, 실패는 좀처럼 DNS처럼 보이지 않습니다. 연결 시간 초과나 멈춘 핸드셰이크가 나오므로 사람들은 라우팅과 인증서를 쫓습니다.

/etc/hosts의 같은 답은 같은 만료를 물려받고 문제가 하나 더 붙습니다. hosts 항목은 재부팅, 재내보내기, '클라이언트 재설치' 수정을 견디므로 주소가 옮겨질 때마다 실패가 돌아옵니다. 어떤 항목이 몇 주 동안 무해하게 있다가, 그것을 가진 모든 기기를 한꺼번에 멈추게 했고 새 설치본은 정상적으로 연결되던 것을 본 적이 있습니다. 같은 계정에서 한 집단은 실패하고 다른 집단은 괜찮다는 이 분열이 가장 값싼 단서입니다.

무작위화의 범위도 정확히 잡아야 합니다. 이것은 연결 시도마다 일어납니다. 이미 맺어진 터널은 엔드포인트를 다시 확인하지 않고, 세션 중간에 서버를 바꾸지 않으며, 개별 애플리케이션 요청이 각각 새 VPN 호스트를 고르지도 않습니다. 다음 시도만 다시 확인하므로 오후 내내 작동한 세션이 내일 아침을 보장하지 않습니다.

터널이 올라올 때 서비스가 확인하는 것

Client VPN은 연결된 주소가 엔드포인트의 DNS 이름에 대해 확인된 주소와 일치하기를 요구합니다. 이 한 가지 요구 사항이 무관해 보이는 여러 실패를 설명합니다. 다른 곳을 가리키는 사용자 지정 DNS 레코드, 실제 엔드포인트 주소로 전달하는 사용자 지정 프런트엔드, 원시 주소로 다시 쓴 프로필입니다. AWS는 사용자 지정 레코드와 전달의 조합을 최신 AWS 제공 클라이언트에서의 실패로 문서화합니다. 검사는 좁으며 모든 별칭이 금지된다는 판결이 아닙니다.

VPN 프로토콜에 대한 일반 규칙도 아닙니다. 숫자 remote는 일반적인 OpenVPN 배포에서 완전히 유효하며 많은 곳이 그렇게 운영됩니다. 제약은 관리형 구성에서 오고, 그 아래 프로토콜에서 오지 않습니다.

그래서 인증서 검증을 느슨하게 하는 것은 잘못된 반사입니다. 주소 교체 후 프로필이 실패하면 서버 검증을 끄는 것은 확인이나 주소 일치 요구를 고치는 대신 오류를 옮길 뿐이며, 무엇이든 신뢰하는 클라이언트를 남깁니다. 내보낸 CA, 서버 검증, 상호 인증 설정은 온 그대로 유지하십시오.

허용 목록, 이그레스, 사설 DNS는 서로 다른 세 가지 문제입니다

노트북이 연결되기 전에 목적지를 허용해야 하는 방화벽 규칙은 바깥 리스너에 관한 것입니다. 네트워크 소유자에게 엔드포인트 이름, 전송, 설정된 포트를 주고, 그들의 통제가 서비스의 DNS 동작을 따라갈 수 있는지 물으십시오. 캡처한 주소 하나를 담은 규칙은 만료가 적히지 않은 스냅숏입니다. 통제가 불변 목적지만 받아들인다면, 조용히 답을 하드코딩하는 대신 배포 전에 그 간극을 정리하십시오.

터널이 올라온 뒤의 요청에 고정 소스 주소가 필요한 파트너는 다른 요구가 있습니다. 이그레스입니다. 웹사이트가 보는 것은 애플리케이션 경로와 분할 터널 정책에 달려 있고, 클라이언트가 연결한 주소와는 무관합니다. 분할 터널 트래픽은 AWS를 전혀 건드리지 않을 수 있습니다.

터널 안의 사설 DNS는 세 번째 계층입니다. 클라이언트에 주어지는 리졸버는 연결 후 내부 이름에 답하고, 터널이 생기기 전에는 공인 엔드포인트를 확인할 수 없습니다. 엔드포인트 확인 실패와 내부 애플리케이션 확인 실패는 다른 단계에서 일어나며, 둘을 섞으면 잘못된 로그로 갑니다.

주소 패밀리도 같은 목록에 들어갑니다. IPv4 답은 IPv6 또는 이중 스택 엔드포인트의 허용 경로에 대해 아무것도 말하지 않으므로, 한 패밀리에서 찍은 스냅숏은 다른 패밀리의 증거가 아닙니다.

아무것도 고정하지 않고 연결을 확인하십시오

내보낸 그대로의 프로필에서 시작해 실제로 무엇을 요구하는지 읽으십시오.

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

그다음 세 가지를 비교합니다. 프로필이 가진 엔드포인트 이름, 새 시도를 위해 클라이언트가 보고하는 주소, 그리고 이름이 지금 어디로 확인되는지입니다. 확인되는 이름은 레코드가 응답한다는 것만 증명합니다. 전송과 인증은 별개이고 엔드포인트가 ping에 응답할 필요도 없습니다. 가운데 항목의 유일한 출처는 클라이언트 자체 로그이므로 시도가 끝난 뒤가 아니라 시도 중에 잡으십시오.

오늘 응답하는 주소는 오늘에 대한 증거입니다. 이름이야말로 서비스가 유효하게 유지하는 대상입니다. 관찰을 기록하고, 엔드포인트를 소유한 사람에게 보내고, 프로필은 이름을 가리키게 두십시오.

버려야 할 두 가지 습관이 있습니다. 멈춘 핸드셰이크를 넘으려고 인증서 검사를 끄는 것, 그리고 하나라도 붙기를 바라며 엔드포인트 이름 앞에 레이블을 쌓는 것입니다. 레이블은 와일드카드 레코드로 확인되거나 문제가 다른 곳에 있습니다. 올바르게 설정한 프로필이 그래도 실패하면 더 긴 호스트 이름이 아니라 정확한 쿼리와 연결 이벤트를 보내십시오.

마무리하기 전에 확인하십시오. 프로필은 내보낸 엔드포인트 이름을 그대로 갖고, 어떤 hosts 파일도 주소를 고정하지 않으며, 클라이언트 로그의 remote는 현재 확인 결과와 일치하고, 방화벽 규칙은 주소가 아니라 엔드포인트를 지목합니다. 이것이 다음 사람에게 넘길 상태이기도 합니다.