在命名空间中运行的 dnsmasq 无法从命名空间内获取查询

在命名空间中运行的 dnsmasq 无法从命名空间内获取查询

我设置了默认值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)

这就是事情变得奇怪的地方

我在命名空间内创建一个永久 shell,然后启动 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

它在命名空间内看起来是一样的。
我也无法 ping 我的命名空间 ip:

(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

ping 命名空间的另一端是有效的,即“默认域”中的接收者:

(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

这意味着命名空间无法 ping 通它自己的命名空间接口 IP。

tcpdump -vv -n -i veth1也从命名空间内部尝试过。当我尝试 ping 分配给 的 ip 时,它没有给我任何信息veth1。但是当我 ping veth0(192.168.42.1) 时,我收到的数据包没有任何问题。

我查过:

这些都没有真正解释为什么会出现这种情况或如何解决它。

清单

  • 没有其他形式的桥接
  • iptables:ACCEPT all -- anywhere anywhere 在所有表、链和策略上。没有任何 DROP 规则。
  • 没有安装或激活其他防火墙
  • 所有接口均已启动(双重检查)
  • 有往返命名空间的路由(路由表看起来不错)
  • pinging外部->里面地址工程
  • pinging里面->外部地址工程
  • pinging里面->里面不是工作。
  • pinging外部->外部作品

我到底哪里出错了?

答案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

相关内容