VPN 뒤의 CloudFront 지오 블로킹: 출구 진단

지리 제한은 IP 주소에 대한 결정이고, VPN은 서비스가 보는 주소를 바꾼다. 이 한 문장이 지원 대기열에 도착하는 혼란스러운 보고의 대부분을 설명한다. «집에서는 사이트가 열리는데 터널에서는 실패한다»와 «터널에서는 열리는데 사무실의 다른 누구도 로드할 수 없다»는 같은 메커니즘이 반대 결과를 내는 것이다. 이 런북은 원인을 하나씩 배제하는 순서로 진단을 진행하며, 엣지가 실제로 무엇을 말했는지부터 시작한다. 같은 출구 주소라도 한 검사는 통과하고 다음 검사에서 실패할 수 있다. 각 검사가 그 주소의 다른 속성을 평가하기 때문이다.

무엇이든 바꾸기 전에 403을 읽어라

지리 차단과 WAF 차단은 모두 403으로 오고, 고치는 위치가 다르다. 응답 헤더와 본문의 첫 줄을 캡처하라. CloudFront는 캐시 헤더와 이유 문자열을 포함하며 어느 계층이 응답했는지 알려준다.

curl -sS -o /tmp/body.txt -D /tmp/headers.txt https://d111111abcdef8.cloudfront.net/
grep -i "x-cache\|via" /tmp/headers.txt
head -c 300 /tmp/body.txt

배포 자체가 지리 때문에 요청을 차단했다면 본문에는 국가 제한을 명시한 메시지가 있다. WAF 규칙이 차단했다면 본문은 보통 일반적인 금지 페이지이고, 헤더의 배포 요청 ID를 WAF 로그로 가져간다. 여기서 착각하면 속도 기반 규칙 문제를 국가 허용 목록으로 해결하려 하게 되고, 이는 성공할 수 없는 하루치 작업이다.

1단계: 배포가 어떤 주소를 보는지 확인하라

실패하는 브라우저가 쓰는 같은 머신과 같은 경로에서 외부 세계가 무엇을 보는지 네트워크에 물어라. curl -s https://checkip.amazonaws.com 은 호출자의 공인 주소를 반환하며, VPN 클라이언트에서는 이것이 가입자의 가정 연결이 아니라 출구다.

curl -s https://checkip.amazonaws.com
nslookup d111111abcdef8.cloudfront.net

그 주소가 다른 국가에 있는 제공자의 출구라면 지리적 결정은 이미 내려졌고 클라이언트에서 무엇도 바꾸지 못한다. 설정을 건드리기 전에 주소를 티켓에 적어라. 보고서에서 당신과 서비스가 동의하는 유일한 사실이기 때문이다.

2단계: 국가와 평판을 분리하라

CloudFront는 요청의 원본 주소를 키로 하는 서드파티 GeoIP 데이터베이스에서 시청자 위치를 판단하며, 매핑은 정확한 확정이 아니라 대략적이고 지역 단위다. 위치를 판단할 수 없을 때 문서화된 기본값은 콘텐츠를 제공하는 것이다. 따라서 세 가지 상태가 있다. 출구가 차단 국가로 매핑되거나, 허용 국가로 매핑되거나, 데이터베이스가 의견이 없어 요청이 진행된다.

차단 국가의 사용자도 제공자가 그곳에 출구를 두면 허용 국가에 있는 것처럼 보일 수 있고, 허용 국가의 사용자도 출구가 다른 곳에 등록되어 차단될 수 있다. 어느 결과도 제한이 깨졌음을 증명하지 않는다. 둘 다 주어진 주소에 대해 제한이 작동하는 것이며, CloudFront 지리 제한 문서가 설명하는 바와 같다.

평판은 두 번째 축이며 터널을 넘어 살아남는다. AWS WAF의 익명 IP 관리형 규칙 그룹은 VPN, 프록시, Tor 노드, 호스팅 제공자의 요청을 차단하도록 만들어졌다. 따라서 국가 검사를 통과한 요청도 주소가 어디에 있는지가 아니라 무엇인지 때문에 거부될 수 있다. 터널을 클라우드 호스트로 옮겼을 때 차단이 시작되었다면 이 계층이 유력하다.

3단계: 할당량 동작을 확인하라

공유 출구는 세 번째 방식으로 실패한다. IP별 속도 제한과 세션 수는 하나의 주소를 하나의 클라이언트로 취급하고, 소비자 출구는 동시에 많은 가입자를 태운다. 그래서 가정 연결에서는 눈에 띄지 않는 요청 패턴이 출구에서는 자동화처럼 보인다. 증상은 스스로 사라지는 제한이나 일시 차단이며, 지리적 오류 메시지가 아니다.

배포가 주소별 세션을 의도적으로 세기도 한다. 예를 들어 DynamoDB에 쓰는 Lambda@Edge 함수를 쓰는 경우다. 그것은 출구 뒤의 사람을 식별하지 않지만 하나의 주소가 하나의 클라이언트처럼 행동하게 만들며, 이것이 실제 의도인 경우가 많다. 임계값을 조정하기 전에 불만 뒤의 서로 다른 주소를 기록하라. 이백 개 책상 앞의 기업 NAT는 밖에서 보면 정확히 바쁜 출구처럼 보인다. 기업 NAT, 대학 네트워크, 단일 주소를 제시하는 대가족에서 오탐을 예상하라.

지리를 탓하기 전에 WAF의 샘플 요청과 속도 기반 규칙 지표를 보라. 출구의 요청량에서 발동하는 규칙은 명확한 흔적을 남기고, 수정이 한도 조정인지 다른 출구 경로인지도 알려준다.

무엇을 어떤 순서로 바꿀까

먼저 통제의 목적을 정하라. 지역 카탈로그 유지, 남용 제한, 계약 이행은 세 가지 다른 목표이며 국가 목록으로 해결되는 것은 첫 번째뿐이다. 목적이 남용 통제라면 출구는 잘못된 신원 단위이며, 아무리 허용 목록을 늘려도 공유 주소를 신뢰할 수 있게 만들지 못한다.

허용 목록에 정말 안정적인 주소가 필요하다면 전용 또는 고정 출구가 도움이 된다. 주소를 등록할 수 있고 회전하지 않기 때문이다. 그러나 주소가 주거용이 되지는 않으며 GeoIP 데이터베이스가 부여하는 국가도 바뀌지 않는다. 하나가 될 때까지 출구를 돌리는 것은 일시적인 평판 변화이지 정책의 해결책이 아니다.

그다음 결과를 요청자가 쓴 용어로 적어라. 이 주소는 국가, 평판 또는 속도로 차단되었고, 바뀔 통제는 이것이다. 더 모호하게 쓰면 다음 주에 다른 출구로 같은 티켓이 다시 온다.