ip netns exec와 DNS: 네임스페이스 안에서 이름이 실패하는 이유

명령은 VPN 네임스페이스 안에서 10.8.0.5에 아무 불만 없이 도달하지만, 같은 명령이 호스트 이름을 쓰는 순간 실패합니다. 네임스페이스에는 자체 인터페이스와 경로와 소켓이 있지만, 자체 리졸버 파일은 없습니다. 무언가가 그곳에 파일을 두지 않는 한, 안쪽 프로세스는 호스트의 /etc/resolv.conf을 읽고 그 네트워크 스택에서는 닿지 않을 수 있는 서버에 묻습니다.

이것은 라우팅 문제가 아니라 파일 선택의 문제이며, 숫자 목적지가 여전히 동작하는 이유가 바로 그것입니다.

프로세스가 실제로 받는 리졸버 뷰를 확인하십시오

사용한 셸이 디버깅 중인 프로세스와 같다고 가정하지 마십시오. 그래픽 애플리케이션, systemd 유닛, 컨테이너는 각각 다른 마운트 또는 네트워크 컨텍스트로 들어갈 수 있습니다. 같은 실행 경로로 조회를 수행하고, 그 안에서 리졸버 파일을 출력하십시오.

ip netns add로 만든 네임스페이스라면 읽기 전용 확인은 짧습니다:

ip netns exec vpn cat /etc/resolv.conf

결과가 도달 가능한 주소인지, loopback 스텁인지, 아니면 도달 가능성이 다른 곳을 가리키는 심볼릭 링크인지 살펴보십시오.

exec 도우미가 실제로 마운트하는 것

ip-netns 도구는 네임스페이스별 구성을 /etc/netns/NAME/ 아래에 문서화합니다. 프로세스를 실행할 때 도우미는 마운트 네임스페이스를 만들고 그 파일들을 평소 경로 위에 바인드 마운트하므로, 프로세스는 네임스페이스 전용 사본을 봅니다. 이것은 이 특정 실행기의 편의 기능입니다. unshare나 컨테이너 런타임 같은 다른 경로로 네트워크 네임스페이스에 들어가면 그것이 자동으로 재현되지 않습니다.

여기서 함정은 loopback 리졸버입니다: 127.0.0.53은 호스트의 스텁이 아니라 네임스페이스 자체의 loopback을 뜻합니다. 호스트 네임스페이스에서만 수신하는 스텁은 새 네임스페이스에서 서비스가 되지 않습니다.

네임스페이스가 도달할 수 있는 리졸버를 고르십시오

파일이 어떤 서버를 지목하든, 그 네임스페이스로부터의 경로가 여전히 필요합니다. 공용 리졸버는 공용 이름에 답하면서도 사설 서비스가 터널로만 도달 가능한 내부 영역에는 실패할 수 있습니다. 조회가 이미 실패한 뒤가 아니라 주소와 동시에 경로를 확인하십시오.

자체 리졸버를 가진 애플리케이션, 예를 들어 DNS over HTTPS를 쓰는 앱은 그 파일을 완전히 무시할 수 있습니다. 도구에 자체 DNS 설정이 있으면 resolv.conf을 바꿔도 영향을 받지 않으며, 네임스페이스는 애초에 문제가 아니었습니다.

파일을 올바른 위치에 쓰십시오

/etc/netns/NAME/resolv.conf 아래에 네임스페이스별 파일을 만들고 실행기가 그것을 제시하게 하십시오. 최소한으로 유지해서 도달 가능한 서버 한두 개와 작업에 필요한 검색 도메인만 두십시오. 프로세스 한 그룹을 위한 뷰를 고치려고 호스트의 생성된 리졸버 파일을 편집하지 마십시오. 그것은 머신의 모든 애플리케이션을 바꾸므로, 호스트가 리졸버 관리자를 쓴다면 그와 싸우는 대신 그 관리자를 통해 네임스페이스 경로를 구성하십시오.

파일 내용을 런북에 기록하십시오. 그렇지 않으면 다음 사람이 호스트의 리졸버를 시험하고 동작하는 답을 본 뒤 네임스페이스가 괜찮다고 결론지을 것입니다.

전체 경로를 다시 시험하십시오

네임스페이스 안에서 숫자 주소, 내부 이름, 공용 이름으로 시험하면 도달 가능성과 해석을 분리하고 내부 영역과 공용 영역을 분리할 수 있습니다. 그런 다음 네임스페이스를 다시 만들고 반복하십시오. 실행 중인 인스턴스에만 존재하는 파일은 그와 함께 사라지기 때문입니다.

파일을 받는 것이 셸이 아니라 프로세스임을 확인하십시오. 대화형 셸에서는 되고 서비스에서는 실패하는 조회는 마운트 컨텍스트에 관한 발견이며, 다음 사고 전에 처음부터 다시 발견하는 대신 적어 두는 것이 좋습니다.