IPV4ルーターに接続すると名前を解決できませんが、アドレスをpingでき、IPV6ルーターではすべてがうまく機能します。

IPV4ルーターに接続すると名前を解決できませんが、アドレスをpingでき、IPV6ルーターではすべてがうまく機能します。

自宅にIPV4アドレスを提供するルーターがあります。私のGentoo PCは正常に動作しますが、Gentooのラップトップは名前解決を停止します。私は両親にアクセスしてIPV6アドレスを提供するルーターに接続しようとしましたが、すべてが正常に戻りました(私のネームサーバーに対応するIPV6を/etc/resolv.confに追加しました)。その後、IPV6ルーターの背後にある親ネットワーク上の他のルーターを試してみましたが、IPV4アドレスを指定して名前を解決することはできませんでした(Gentoo LiveCDを起動すると機能しましたが、設定の問題です)。私のラップトップとIPV4関連)(IPV4アドレスを/etc/resolv.confに再度追加し、IPV6アドレスも維持しようとしました)。住所はうまくpingできますが、名前は解決できません。原因は何ですか?どうすれば解決できますか?

私のresolv.conf(IPV4は過去に動作しました):

# dnsmasq
nameserver 127.0.0.1
# OpenNIC
nameserver 31.171.155.107
nameserver 79.133.43.124

IPV6(IPV6ルーターで動作):

# dnsmasq
nameserver ::1
# OpenNIC
nameserver 2a05:dfc7:5::53
nameserver 2001:19f0:7001:929:5400:00ff:fe30:50af

IPV4 ルータは IPV4 ルータで動作しましたが、変更しないと動作が停止しました。他の項目が修正され、名前解決が動作を停止しました。私の完全な/ etcフォルダー(ssl、Shadowなどを除く)を見つけることができます。 ここ

すべてのiptablesルールを更新し、すべてのポリシーを受け入れるように設定しました。 dnsmasqを除いて、実行中のネットワーク関連サービスはありません(そのサービスを無効にし、resolv.confからlocalhost行を削除しようとしましたが、役に立ちませんでした)。私はwpa_supplicantとipを使ってインターネットに接続し、名前解決を除いてうまくいきました(Gentooのrcスクリプトを使用して有線インタフェースを介して接続するときも同じでした)。両方をiptables -L返すip6tables -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

いくつかのテストと結果(結果は有線接続と同じですが、すべて無線接続を持つIPV4ルーターで行われます):

$ 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はホスト名(google.comなど)をpingしようとすると何も登録しませんが、IPアドレスをpingすると正常に登録します。 ICMP echo:

$ 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 

TCPダンプ:

$ 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 

IPv4ルーターのifconfig:

 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             

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

nsスイッチ:

# /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 

私もこれを実行し、strace -e open dig @8.8.8.8 gentoo.orgそれが最後にしたことは/etc/resolv.confを(成功的に)開くことでした。

ベストアンサー1

iptables -L特に不完全なビューを提供し、パケットフロー方式に影響を与える可能性があり、実際に影響を与えるNATまたはマングルテーブルを表示しません。デバッグを完了するには、次のようなさまざまなテーブルも確認する必要があります。

iptables -t nat -n -L

または、ファイアウォールルールセット全体をダンプします。

iptables-save

おすすめ記事