VPN을 통한 DNS 필터링이 웹사이트 로딩을 막았을 때: 응답을 읽는 방법

터널이 켜져 있는데 한 이름만 실패하고 브라우저는 이를 네트워크 오류라고 부르지만, 실제 원인은 리졸버가 돌려준 DNS 응답입니다. 필터링 리졸버는 한 이름을 보류하거나 거부하거나 다시 쓸 수 있으며 나머지 조회는 그대로 동작하게 둘 수 있습니다. 질의를 나르는 것은 터널이고, 응답을 정하는 것은 리졸버입니다. 암호화 설정을 건드리기 전에 그 응답을 확인하세요.

터널이 켜져 있으니 암호화는 용의자가 아니다

연결 상태가 알려주는 것은 패킷이 흐르는지 여부이지, 이름이 해석되는지 여부가 아닙니다. 해석은 클라이언트가 설정된 서버로 보내는 질의이며, 그곳의 정책은 한 도메인에 다른 모든 도메인과 다르게 응답할 수 있습니다. 브라우저 쪽에서는 그 모든 응답이 일반적인 실패로 뭉개지므로 상태 표시등이 증명하는 것은 아주 적습니다.

먼저 세 가지를 기록하세요: 클라이언트가 사용한 리졸버, 실패하는 이름의 응답 코드, 그리고 동작해야 할 이름에 대한 같은 질의입니다. dig example.com @10.20.0.1 로 리졸버에 직접 물어보고 브라우저 메시지가 아니라 상태 줄을 읽으세요. 대조 이름이 해석되고 실패하는 이름이 정책 응답을 돌려주면 증거는 완성됩니다. 둘 다 실패하면 필터는 아직 개입하지 않은 것입니다.

네 가지 응답, 네 명의 다른 소유자

필터링 리졸버가 아니라고 말하는 방식은 하나가 아니며, 거부의 형태가 다음 단계를 다르게 가리키므로 응답 코드를 적어 두세요. 브라우저는 네 가지를 모두 끊긴 연결처럼 들리는 무언가로 다시 쓰기 때문입니다.

무엇이든 터널 탓으로 돌리기 전에 응답을 표와 맞춰 보세요. 거부와 보류된 이름은 둘 다 리졸버가 결정을 내렸다는 뜻이고, 반면 침묵은 질의가 응답을 한 번도 받지 못했다는 뜻입니다. 이 차이가 정책 소유자를 쫓을지 네트워크 경로를 쫓을지를 정합니다.

두 브라우저가 두 정책을 따를 수 있다

자체 암호화 리졸버를 함께 가진 브라우저는 운영 체제가 나눠 주는 서버를 쓸 필요가 없으므로, 터널이 적용하려고 만들어진 정책을 무시할 수 있습니다. 그러면 한 기기에서 두 브라우저가 같은 호스트 이름에 대해 서로 다른 말을 하고, 둘 다 고장 난 것은 아닙니다. 각 애플리케이션이 어느 리졸버에 묶여 있는지 확인하세요 필터가 일관성이 없다고 말하기 전에.

두 애플리케이션이 터널 리졸버를 쓰는데 하나만 실패한다면 차이는 애플리케이션에 있고 DNS에 있지 않습니다. 애플리케이션별로 리졸버 주소를 적어 두세요(창을 닫으면 그 세부 정보가 사라집니다).

가진 것은 바꾸고, 갖지 않은 것은 위로 올리세요

다음 단계는 여러분이 가리키는 리졸버를 누가 소유하는지에 달려 있습니다. 직접 운영하는 것은 문서화된 필터링 옵션과 예외를 확인한 뒤 그 한 이름을 허용할 수 있는, 읽고 설정 가능한 기능입니다. 고용주나 공급자가 운영하는 것은 도메인, 정확한 응답, 시각을 담은 티켓입니다.

사설 이름이 해석되지 않고 의도된 정책도 적용되지 않으므로 사이트를 억지로 열려고 공개 리졸버로 바꾸지 마세요. 좁은 변경은 증거도 그대로 남기므로 소유자가 여러분의 보고서를 자기 기록과 대조할 수 있습니다. 변경 후에는 셸에서 조회하지 말고 원래 애플리케이션 테스트를 다시 하세요.

차단 페이지는 신뢰할 수 있는 인증서가 아니다

자기 인증서를 제시하는 대체 페이지는 HTTPS 신원 경고를 띄우며, 리디렉션은 그 인증서를 유효하게 만들지 않습니다. 터널이 켜져 있다는 이유로 그 경고를 넘겨 클릭하지 말고, 경고는 별개의 신뢰 결정으로서 여전히 올바라야 합니다.

실패하는 이름이 정책 응답을, 대조 이름이 같은 리졸버를 통해 정상 응답을 돌려주면 진단이 끝납니다. 그 시점의 수리는 터널 변경이 아니라 정책 변경이며, 보고서에 인용하는 것은 RFC 1035 응답 코드입니다. 두 이름과 응답을 함께 보관하는 것이 사건의 전부입니다.