Na minha casa, tenho um roteador que me fornece um endereço IPV4. Meu PC Gentoo funciona bom, mas meu laptop Gentoo parou de resolver nomes. Eu visitei meus pais e tentei conectar ao seu roteador, o que me dá um endereço IPV6, e pronto, tudo voltou ao normal (adicionei os equivalentes de IPV6 dos meus servidores de nomes para /etc/resolv.conf). Então eu tentei outro roteador na rede dos meus pais, que fica atrás do IPV6, mas que me dá um endereço IPV4, e depois novamente eu não consigo resolver nomes (embora se eu inicializo um LiveCD do Gentoo eu consigo, então é um problema de configuração no meu laptop e relacionado ao IPV4) (eu adicionei novamente o IPV4 endereços de volta para /etc/resolv.conf, e eu também tentei deixar os IPV6). Eu pode pingar endereços muito bem, eu simplesmente não consigo resolver nomes. O que poderia ser causando isso e como eu poderia consertar isso?
Meu resolv.conf (IPV4, costumava funcionar no passado):
# dnsmasq
nameserver 127.0.0.1
# OpenNIC
nameserver 31.171.155.107
nameserver 79.133.43.124
IPV6 (trabalhando no roteador IPV6):
# dnsmasq
nameserver ::1
# OpenNIC
nameserver 2a05:dfc7:5::53
nameserver 2001:19f0:7001:929:5400:00ff:fe30:50af
Observe que o IPV4 usado para trabalhar nos roteadores IPV4 parou de funcionar sem mim modificando isso. Outra coisa foi modificada e o nome foi resolvido parou de trabalhar. Minha pasta inteira / etc (exceto ssl, shadow, etc) pode ser encontrada aqui .
Eu limpei todas as regras do iptables e defini todas as políticas para ACCEPT. Nenhuma rede relacionada
serviços estão executando exceto dnsmasq (eu tentei desativá-lo e remover o
linha localhost de resolv.conf, sem sucesso). Eu me conecto à internet usando
nua wpa_supplicant ee ip, e funciona bem, é apenas o nome resolvendo
o que não acontece (nem mesmo ao conectar a interface com fio usando
Scripts rc do Gentoo). Ambos iptables -L e ip6tables -L return:
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
Alguns testes e seus resultados (tudo em um roteador IPV4 conectado sem fio, embora os resultados sejam os mesmos com uma conexão com fio):
$ nslookup google.com 8.8.8.8
;; connection timed out: no servers could be reached.
...
$ dig @8.8.8.8 gentoo.org
;; connection timed out: no servers could be reached.
tcpdump não registra nada ao tentar fazer ping de um hostname como google.com, mas registre com sucesso os ecos do ICMP ao efetuar o ping de um endereço IP:
$ ping gentoo.org
ping: unknown host gentoo.org
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=74.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=73.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=73.7 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 73.708/73.810/74.012/0.344 ms
tcpdump:
$ tcpdump -i wlp3s0 port 53
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
$ tcpdump -i wlp3s0
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:05:55.807483 IP 192.168.25.11 > 8.8.8.8: ICMP echo request, id 5903, seq 1, length 64
07:05:55.881446 IP 8.8.8.8 > 192.168.25.11: ICMP echo reply, id 5903, seq 1, length 64
07:05:56.808617 IP 192.168.25.11 > 8.8.8.8: ICMP echo request, id 5903, seq 2, length 64
07:05:56.882287 IP 8.8.8.8 > 192.168.25.11: ICMP echo reply, id 5903, seq 2, length 64
07:05:57.810421 IP 192.168.25.11 > 8.8.8.8: ICMP echo request, id 5903, seq 3, length 64
07:05:57.884089 IP 8.8.8.8 > 192.168.25.11: ICMP echo reply, id 5903, seq 3, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
ifconfig no roteador ipv4:
wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.25.11 netmask 255.255.255.0 broadcast 192.168.25.255
inet6 fe80::16ec:71f7:dcc5:f175 prefixlen 64 scopeid 0x20<link>
ether 00:07:c8:82:a2:96 txqueuelen 1000 (Ethernet)
RX packets 6 bytes 568 (568.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 24 bytes 4038 (3.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rota ip:
$ ip route
default via 192.168.25.1 dev wlp3s0
169.254.0.0/16 dev wlp3s0 proto kernel scope link src 169.254.144.184 metric 304
192.168.25.0/24 dev wlp3s0 proto kernel scope link src 192.168.25.11
nsswitch:
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $
passwd: compat
shadow: compat
group: compat
# passwd: db files nis
# shadow: db files nis
# group: db files nis
hosts: files dns
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
Eu também corri strace -e open dig @8.8.8.8 gentoo.org e a última coisa que faz
está aberto /etc/resolv.conf (com sucesso).
iptables -L dá uma visão incompleta; em particular, ele não mostra as tabelas NAT nem mangle, que podem influenciar o fluxo de pacotes. Para uma depuração completa, essas várias tabelas também precisarão ser inspecionadas
iptables -t nat -n -L
ou todo o conjunto de regras do firewall descartado, e. com
iptables-save
Tags dns networking ipv6 ipv4 gentoo