입력을 찾고 있습니다. 네트워크 네임스페이스 만료와 관련된 다음 관찰이 예상됩니까, 아니면 오류로 보고되어야 합니까?
- 프로세스가 열려 있으면
/proc/<pid>/net/dev파일을 닫을 때까지 다른 프로세스의 네임스페이스 만료를 차단/지연할 수 있습니다. 그렇게 하기 위해 해당 네임스페이스의 일부일 필요는 없습니다.
이는 매우 놀라운 행동인 것 같습니다. 이를 통해 로컬 사용자는 적절한 파일에 액세스하여 proc네트워크 네임스페이스의 veth 인터페이스 손상을 지연/방지할 수 있습니다. 파일을 닫지 않고 여는 결함이 있는 모니터링 도구 /proc도 이 문제를 일으킬 수 있습니다.
복제기
(Debian Buster - Linux 5.4.0-0.bpo.4-amd64)
1) 네트워크 네임스페이스를 생성합니다.
$ unshare -n
$ echo $BASHPID
18807
2) veth를 생성하고 한쪽 끝을 위에서 생성한 네트워크 네임스페이스로 이동합니다.
$ ip link add dev veth18807 type veth peer name eth18807
$ ip link set eth18807 netns 18807
$ ip addr | grep veth
14: veth18807@if13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
3) tail -f /proc/18807/net/dev별도의 터미널에서 실행
$ tail -f /proc/18807/net/dev
...
tail: /proc/18807/net/dev: file truncated
...leave hanging...
4) 1)에서 네임스페이스를 종료하고 인터페이스를 나열합니다.
$ ip addr | grep veth
14: veth18807@if13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
이전에 생성된 항목이 veth여전히 존재합니다. 그러나 1)단계에서 생성된 네트워크 네임스페이스에 대한 뚜렷한 흔적은 없습니다. lsns표시되지 않으며 /ns해당 디렉토리에 프로세스가 없습니다.
중단 되면 tail -f인터페이스가 즉시 사라집니다 ip addr. 꼬리일 필요는 없고, 그냥 열어두기만 하면 open()충분합니다.
../net/dev열려면 네트워크 네임스페이스에 대한 참조가 필요할 수 있으므로 기술적으로 이것이 의미가 있을 수 있다고 생각합니다 . 네임스페이스가 이런 방식으로 활성 상태로 유지될 수 있다는 것은 매우 놀라운 일입니다.
해결 방법으로 veth사용하기 전에 생성된 저작물을 명시적으로 삭제하세요 ip link del. 그러나 이것이 여전히 네임스페이스를 보존할 수 있을지 궁금합니다.
지옥불의 예
조사는 "이미 사용 중"인 IP 주소에 대해 불평하는 방화범 메시지에 의해 촉발되었습니다. 토끼 구멍을 따라 내려가면 마침내 고정 IP를 사용하는 것처럼 보입니다. 다음과 같이 실행할 수 있습니다.
1) 감옥을 시작하다
$ /usr/local/bin/firejail --net=docker0 --ip=172.30.0.30 --noprofile
Parent pid 20890, child pid 20891
Interface MAC IP Mask Status
lo 127.0.0.1 255.0.0.0 UP
eth0 e2:87:2e:06:07:5b 172.30.0.30 255.255.0.0 UP
Default gateway 172.30.0.1
Child process initialized in 1491.22 ms
2) 별도의 터미널에서 net/dev하위 키를 엽니다.
$ tail -F /proc/20891/net/dev
3) 위에서 종료 firejail하고 동일한 매개변수로 다시 시작하십시오.
$ /usr/local/bin/firejail --net=docker0 --ip=172.30.0.30 --noprofile
Error: IP address 172.30.0.30 is already in use
위 메시지는 veth가 firejail해당 IP에 대한 ARP 확인에 계속 응답하기 때문입니다.
루스트어바웃
Docker를 사용하여 위의 Firejail 시나리오를 재현할 수 없습니다. 컨테이너가 중지되면 인터페이스가 사라집니다. 아마도 Docker가 실제로 ip link del해결 방법(?)을 구현했을 수도 있습니다.
인용하다
Linuxcontainers 및 커널 버그와 관련된 유사한 관찰이 보고되었습니다.
이는 일반적으로 컨테이너의 네트워크 네임스페이스가 만료되지 않았음을 나타내며 일반적으로 커널에 문제가 있음을 나타냅니다. 네트워크 네임스페이스를 사용하는 마지막 프로세스가 종료되면 네임스페이스가 삭제되고 이로 인해 모든 가상 인터페이스가 삭제되고 물리적 인터페이스가 호스트 네트워크 네임스페이스로 다시 이동됩니다.