Eu configurei um dnsmasq.conf padrão com praticamente nenhuma modificação, exceto:
listen-address=192.168.42.2
interface=veth1 # Also tried without
server=8.8.8.8
E meu /etc/hosts é assim:
127.0.0.1 test.testing.com
Eu criei um namespace assim:
# 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
Isso tudo configura tudo de bom e elegante.
Posso confirmar via:
[root@arch Torxed]# ip netns list
spacename (id: 0)
Aqui é onde as coisas ficam estranhas
Eu crio um shell permanente dentro do namespace e inicio o dnsmasq.
# ip netns spacename /bin/bash
(namespace)# /usr/bin/dnsmasq -k --enable-dbus --user=dnsmasq --pid-file --log-queries --no-daemon
E tudo começa bem. Eu confirmo isso emitindo:
(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 [::]:*
E do lado de fora, não há porta escutando. Como pretendido. Mas sempre que eu faço:
(namespace)# dig test.testing.com @192.168.42.2
Nada acontece. Mas quando eu faço
# 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
Funciona ... fora do namespace.
Por que em internets green earth não consigo cavar de dentro do namespace onde o dnsmasq está rodando ?
Eu verifiquei novamente o iptables, ele não tem nada suspeito dentro ou fora do namespace:
[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
Parece o mesmo dentro do namespace.
Eu não consigo pingar meu namespace 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 no outro lado do espaço de nomes funciona tho, o receptor no "domínio padrão":
(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
O que significa que o espaço de nomes não pode fazer o ping do próprio IP da interface de namespace.
Tentei tcpdump -vv -n -i veth1 de dentro do namespace também. Não me dá nada quando tento pingar o ip atribuído a veth1 . Mas quando eu pingar veth0 (192.168.42.1) eu recebo os pacotes sem nenhum problema.
Eu verifiquei:
Nenhum dos quais realmente explica por que isso é ou como resolvê-lo.
lista de verificação
- Nenhuma outra forma de ponte
- iptables:
ACCEPT all -- anywhere anywhere em todas as tabelas, cadeias e políticas. Não há regras DROP que assim sempre.
- Nenhum outro firewall instalado ou ativo
- Todas as interfaces estão ativadas (dupla verificação)
- Existem rotas de e para o namespace (a tabela de roteamento parece bem)
- Ping fora - > dentro endereço funciona
- Ping dentro de - > fora funciona o endereço
- Ping dentro de - > dentro o não funciona.
- Ping fora - > fora funciona
Onde eu errei?