호스트가 특정 네트워크로 로밍할 때 QEMU "사용자 네트워크"에서 DNS 확인이 중지되는 이유는 무엇입니까?

호스트가 특정 네트워크로 로밍할 때 QEMU "사용자 네트워크"에서 DNS 확인이 중지되는 이유는 무엇입니까?

저는 노트북에서 GNOME Box를 사용하고 있습니다. 랩탑이 네트워크(이더넷, 다른 위치의 Wi-Fi 또는 USB 모뎀 역할을 하는 휴대폰) 사이를 이동할 때마다 게스트 컴퓨터는 기본 설정을 사용하여 자동으로 인터넷 연결을 얻습니다.

게스트 시스템은 호스트에 브리지되지 않으며 호스트의 LAN에 표시되지 않습니다.방문자의 MAC 주소를 덮어썼습니다.프레임을 호스트의 LAN으로 전달하기 전.

기본적으로 QEMU는 SLRP 게스트용 사용자 네트워크 백엔드 및 가상 네트워크 어플라이언스...

사용자 네트워크QEMU 내에서 완전한 TCP/IP 스택을 제공하고 이 스택을 사용하여 가상 NAT 네트워크를 구현하는 "slirp"를 사용하여 구현되었습니다.

QEMU의 마지막이자 가장 이상한 네트워킹 옵션은 기본 옵션이기도 합니다. 그 기능은 "사용자 모드 네트워크 스택"to vlan. 네트워크 스택은 ip, tcp, udp, dhcp 및 tftp 등의 프로토콜을 독립적으로 구현한 것입니다. 예를 들어 유효한 주소로 dhcp 요청에 응답하거나 tftp에 응답하여 vlan의 프레임을 처리할 수 있습니다. 호스트 파일 시스템 파일에서 파일을 가져오거나 패킷 데이터를 전달할 수 있는 udp/tcp 소켓을 생성합니다.

네트워크 스택은 qemu 프로세스 자체 내에서 실행됩니다. 예를 들어, 이러한 요청을 처리하기 위한 별도의 dhcp 또는 tftp 프로세스가 없습니다. 또한 스택은 udp/tcp 패킷에서 애플리케이션 데이터의 압축을 풀고 이를 qemu 프로세스와 대상 프로세스를 연결하는 소켓을 통해 전달함으로써 효과적으로 프록시 역할을 합니다.

위의 맥락에서 "vlan"은 "에뮬레이트된" LAN을 의미합니다.IEEE 802.1Q VLAN ID를 의미하는 것은 아닙니다..

기본적으로 게스트는 10.0.2.0/24 네트워크에서 10.0.2.15 IP 주소를 갖습니다. 게이트웨이는 10.0.2.2입니다. DNS 서버는 10.0.2.3입니다. 게스트는 10.0.2.2 게이트웨이 IP에 연결하여 호스트에 액세스할 수 있습니다.

여기에 이미지 설명을 입력하세요.

특정 Wi-Fi 네트워크에서는 모든 게스트 컴퓨터가 인터넷에 액세스할 수 없습니다. 내가 찾은인터넷 부족에 대한 또 다른 질문QEMU 하의 게스트에서는 특정 설정 하에서 DNS가 기본적으로 작동하지 않을 수 있다는 사실이 발견되었습니다. 그래서 나는 내 것을 확인했습니다. 방문자의 IP를 통해 웹사이트에 접속할 수 있습니다. 또한 IPv4 연결을 수동으로 구성하고 기본 10.0.2.3 외에 다른 알려진 확인자(예: 8.8.8.8)를 백업으로 추가하면 해상도도 복원됩니다.

로컬 관리자에 따르면 Wi-Fi 네트워크에는 로컬 컴퓨터와 게스트 컴퓨터를 분리하기 위해 VLAN 태깅이 활성화되어 있습니다. 분명히 VLAN이 문제라면 단순히 문제를 해결하기보다는 인터넷 액세스가 완전히 중단될 것입니다.

이 네트워크의 또 다른 특징은 첫 번째 DNS 확인자가 대부분의 요청을 거부하도록 구성되어 있다는 것입니다. 두 번째 파서인 8.8.8.8이 제공되지만 QEMU는 이를 사용하지 않는 것으로 보입니다.

다른 장치에서도 문제가 지속됩니다. 저는 Intel 무선 기술을 탑재한 완전히 다른 두 개의 노트북을 사용해 보았습니다. 이 문제는 Debian "Buster", "Bullseye" 및 "Sid" 10.4 이후부터 발견되었습니다.

답변1

기본 "사용자 모드" 네트워크에서 QEMU는 호스트의 첫 번째 DNS 이름 서버만 사용합니다. 따라서 해당 네임서버가 올바르게 확인되지 않으면 QEMU는 호스트에서 보조 네임서버로 구성될 수 있는 다른 네임서버로 대체되지 않습니다. 이로 인해 게스트의 인터넷 연결이 명백히 손실되는 반면 호스트는 대체 이름 서버를 사용하여 여전히 문제를 "숨길" 수 있습니다.

이는 알려진 QEMU 동작이며 QEMU에서 수정될 것으로 예상되지 않습니다. 이건 한 남자의 명언이에요2011년 데비안 버그 보고서 로그 #625689:

아니요, 해당 제한 사항은 아직 문서화되지 않았으며 수정하기 어렵거나 실제로 문제를 일으킬 가치가 없을 수도 있습니다. 두 가지 이유가 있습니다. 우선, 사용자 모드 네트워킹은 심각한 작업에는 적합하지 않습니다. 오프로드 네트워킹을 위해서는 브리지를 사용해야 합니다. 이는 약 100배 빠르고 실제로 작동합니다(예: ICMP). 둘째, 구현은 매우 간단합니다. DNS의 경우 게스트(예: NAT 상자)의 패킷을 호스트/resolv.conf에서 네임서버로 전달합니다. 동시. 따라서 이 문제를 해결하려면 qemu는 단순한 NAT "장치"가 아닌 DNS에 대한 애플리케이션 수준 프록시가 되어야 합니다.

먼저 호스트에 일부 정크를 추가하면 nameserver문제를 쉽게 재현할 수 있습니다 . /etc/resolv.conf손님은 즉시 연설을 중단했습니다.

Debian 클라이언트의 경우 네트워크를 복원하려면 다른 알려진 확인자(예: 8.8.8.8)를 네트워크에 추가하기만 하면 됩니다 /etc/resolv.conf. 이러한 구성 변경 사항은 클라이언트를 다시 시작해도 유지되지 않습니다.

관련 정보