기본값을 설정 dnsmasq.conf하고 기본적으로 다음을 제외하고는 수정하지 않았습니다.
listen-address=192.168.42.2
interface=veth1 # Also tried without
server=8.8.8.8
내 /etc/hosts모습은 다음과 같습니다.
127.0.0.1 test.testing.com
그런 다음 다음과 같은 네임스페이스를 만들었습니다.
# ip netns add spacename
# ip link add veth0 type veth peer name veth1
# ip link set veth1 netns spacename
# ip addr add 192.168.42.1/24 dev veth0
# ip link set dev veth0 up
# ip netns exec spacename ip addr add 192.168.42.2/24 dev veth1
# ip netns exec spacename ip link set dev veth1 up
# ip netns exec spacename ip route add default via 192.168.42.1
# iptables -t nat -A POSTROUTING -s 192.168.42.0/24 -o eno1 -j MASQUERADE
# echo 1 > /proc/sys/net/ipv4/ip_forward
# ip netns exec spacename /bin/bash
(namespace)# echo 1 > /proc/sys/net/ipv4/ip_forward
이 모든 것이 멋지고 멋집니다.
다음을 통해 확인할 수 있습니다.
[root@arch Torxed]# ip netns list
spacename (id: 0)
여기서부터 상황이 이상해집니다
네임스페이스 내에 영구 셸을 만든 다음 dnsmasq를 시작합니다.
# ip netns spacename /bin/bash
(namespace)# /usr/bin/dnsmasq -k --enable-dbus --user=dnsmasq --pid-file --log-queries --no-daemon
모든 것이 잘 시작되었습니다. 다음 명령을 실행하여 이를 확인했습니다.
(namespace)# ss -lun
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 0.0.0.0:53 0.0.0.0:*
UNCONN 0 0 [::]:53 [::]:*
"외부" 관점에서 보면 포트 수신 대기가 없습니다. 예상대로. 하지만 내가 할 때마다:
(namespace)# dig test.testing.com @192.168.42.2
아무 일도하지. 하지만 내가 할 때
# dig test.testing.com @192.168.42.2
;test.testing.com. IN A
;; ANSWER SECTION:
test.testing.com. 0 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 192.168.42.2#53(192.168.42.2)
;; WHEN: Sat Nov 24 19:58:37 CET 2018
;; MSG SIZE rcvd: 60
네임스페이스 외부에서 작동합니다.
인터넷에는 왜 녹색 지구가 있는 걸까요?dnsmasq를 실행 중인 네임스페이스 내에서 정보를 파헤칠 수 없나요??
iptables를 다시 확인했는데 네임스페이스 내부나 외부 모두 의심스러워 보이지 않습니다.
[root@arch Torxed]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
네임스페이스 내에서도 동일하게 보입니다.
또한 내 네임스페이스 IP를 ping할 수 없습니다.
(namespace)# ping 192.168.42.2 -c 1
PING 192.168.42.2 (192.168.42.2) 56(84) bytes of data.
--- 192.168.42.2 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
네임스페이스의 다른 쪽 끝(예: "기본 도메인"의 수신자)에 대한 핑은 유효합니다.
(namespace)# ping 192.168.42.1 -c 1
PING 192.168.42.1 (192.168.42.1) 56(84) bytes of data.
64 bytes from 192.168.42.1: icmp_seq=1 ttl=64 time=0.024 ms
--- 192.168.42.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
이는 네임스페이스가 자체 네임스페이스 인터페이스 IP를 ping할 수 없음을 의미합니다.
tcpdump -vv -n -i veth1네임스페이스 내부에서도 시도했습니다. 할당된 IP에 ping을 시도하면 아무런 정보도 제공되지 않습니다 veth1. 하지만 ping veth0(192.168.42.1)을 하면 아무 문제 없이 패킷을 받습니다.
나는 다음을 확인했다:
이 중 어느 것도 실제로 이런 일이 발생하는 이유나 해결 방법을 설명하지 않습니다.
체크리스트
- 다른 형태의 연결은 없습니다.
- iptables:
ACCEPT all -- anywhere anywhere모든 테이블, 체인 및 정책에 적용됩니다. DROP 규칙이 없습니다. - 다른 방화벽은 설치되거나 활성화되지 않습니다.
- 모든 인터페이스가 작동 중입니다(다시 확인).
- 네임스페이스를 오가는 경로가 있습니다(라우팅 테이블이 좋아 보입니다).
- 핑외부->~에주소 엔지니어링
- 핑~에->외부주소 엔지니어링
- 핑~에->~에하다아니요일하다.
- 핑외부->외부일하다
내가 어디서 잘못됐나요?
답변1
답변을 보면 참 엉뚱합니다.
네임스페이스 장치가 꺼져 있다는 점을 제외하면 loopback모든 것이 정확합니다 .
모든 것이 로컬로 라우팅되므로 lo이 인터페이스도 작동되어야 합니다.
# ip netns spacename ip link set up dev lo
# ip netns spacename ip addr add 127.0.0.1/8 dev lo
문제를 풀다. TJ-irc.freenoce.net/#ubuntu에 많은 감사를 드립니다.
00:51 < TJ-> DoXiD: "ip netns spacename ip link set up dev lo" :D --- it was down!
00:52 < TJ-> DoXiD: I knew it had something to do with the way localhost is handled, but I didn't look at the basics
00:53 < TJ-> DoXiD: anything routed inside the host uses lo