VPN 컨테이너의 네트워크 공유: DNS에는 무슨 일이 생길까

VPN 컨테이너의 네트워크 네임스페이스를 공유하면 애플리케이션에 터널의 인터페이스와 경로가 주어집니다. 그러나 터널의 리졸버도, 호스트에 있는 다른 무엇과 병합된 사본도 주어지지 않습니다. 이 간극은, 공개 이름은 해석되고 내부 이름은 해석되지 않으며 실패하는 앱은 실제로 잘못된 DNS 서버를 쓰기 때문에 그렇게 보이는, 아주 구체적인 장애를 만듭니다. 수리는 보통 진단이 시사하는 것보다 작습니다.

1단계: 호스트가 아니라 앱에서 테스트합니다

문제가 있는 컨테이너 안에서, 호스트나 브라우저가 아니라 조회를 실행합니다. docker exec app-container getent hosts db.internal 는 이 프로세스의 리졸버가 무엇을 반환하는가라는 중요한 유일한 질문에 답합니다.

호스트가 이름을 해석하고 컨테이너가 해석하지 못하면 결함을 찾은 것입니다. 그 뒤의 모든 것은 그것을 고치는 지원되는 방법을 고르는 일입니다.

2단계: 런타임이 지원하는 모델을 읽습니다

Docker의 네트워크 문서 는 다른 컨테이너의 네트워크 모드를 공유하는 컨테이너의 DNS 플래그에 대한 제한을 기록합니다. Compose에서는 network_mode: service:vpn 앱을 VPN 컨테이너의 네임스페이스에 묶고, 서비스별 dns 설정은 일반 서비스에서처럼 동작하지 않습니다. 얻는 해석은 공유 네임스페이스가 가지고 있는 것입니다.

사용자 정의 브리지 네트워크도 Docker의 내장 DNS를 기본 브리지와 다르게 사용합니다. 그래서 동작하는 브리지 예제에서 복사한 dns 절이 공유 스택에서는 아무것도 하지 않을 수 있습니다. 절을 복사하기 전에 구성을 확인하세요.

루프백 주소는 항상 해당 네트워크 컨텍스트를 가리킵니다. 공유 네임스페이스 안에서 127.0.0.1 는 호스트의 리졸버가 아닙니다.

3단계: 쿼리를 수신자까지 따라갑니다

자체 리졸버를 실행하는 앱은 편집한 파일을 무시하므로, 앱의 리졸버 구성을 읽고 이어서 앱이 함께 제공하는 앱별 암호화 DNS를 읽습니다. 그다음 선택한 리졸버가 VPN의 경로와 방화벽 정책 아래에서 도달 가능한지 확인합니다. 터널 반대편의 리졸버 주소는 네임스페이스에 그곳으로 가는 경로가 없으면 쓸모가 없습니다. 파일을 편집하기 전에 수신자를 확인하세요.

브라우저의 IP 확인 페이지는 이름 쿼리가 어디로 갔는지 알려줄 수 없습니다. HTTP 연결 하나가 어디로 갔는지만 알려줍니다.

4단계: 두 실패 범주를 다르게 고칩니다

공개 이름은 동작하는데 서비스 이름이 실패하면 문제는 컨테이너 네트워크 내부의 서비스 검색이지, 공개 리졸버 목록이 아닙니다. 모든 공개 DNS 주소를 바꿔도 네트워크의 검색 메커니즘에 요청된 적 없는 레코드가 만들어지지 않습니다.

두 범주가 모두 실패하면 리졸버 도달성부터 시작하세요. 하나만 실패하면 검색 메커니즘부터 시작하세요. 둘은 소유자가 달라서 하나의 수리로 둘을 모두 덮지 못합니다.

5단계: 재생성 후 다시 테스트합니다

런타임이 지원하는 메커니즘으로 구성을 바꾸고, 실행 중인 컨테이너 안의 파일을 편집하는 대신 컨테이너를 다시 만드세요. 새 개인 이름, 새 공개 이름, 조회에 이어지는 애플리케이션 요청을 테스트합니다. /etc/resolv.conf 컨테이너 안의 편집은 재생성 시 사라지고, 고쳐지지 않았는데도 고쳐진 것처럼 믿게 만듭니다.

공유 네트워크 정의 옆에 리졸버 소유자와 예상 네임스페이스를 기록하세요. 다음 사람에게 둘 다 필요합니다.