web-dev-qa-db-ja.com

DHCPv6用にラップトップワイヤレスアダプターを構成する方法

ネットワークトポロジは、次のように単純です。 network topology

いくつかの通信の後、私のISPはいくつかのスイッチを切り替えて、ルーターが「デフォルトのIPv6ゲートウェイ」と呼ぶものを取得できるようにしました。イーサネットに接続されたPCは、問題なくIPv6を使用できるようになりました。

_$ ping -q -c 1 ipv6.google.com
PING ipv6.google.com(syd15s01-in-x0e.1e100.net (2404:6800:4006:806::200e)) 56 data bytes

--- ipv6.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 45.496/45.496/45.496/0.000 ms
_

同じディストリビューション（Arch Linux）で 同じソフトウェア を実行しているラップトップは、IPv4ホストに接続できますが、IPv6ホストには接続できません。

_$ ping -q -c 1 ipv6.google.com
connect: Network is unreachable
_

これについて私のISPに尋ねると、彼らは答えました

コンピューターのワイヤレスアダプターにIPv6が構成されていますか？

どうすればわかりますか？私が考えることができる最も近いのは、ラップトップがネットワークインターフェイスに内部IPを割り当てているように見えることです。

_$ ip address show dev wlp1s0 
2: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 54:8c:a0:52:3e:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.6/24 brd 192.168.1.255 scope global noprefixroute wlp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::f0ac:8fe:bb0d:619a/64 scope link 
       valid_lft forever preferred_lft forever
_

私のラップトップにはイーサネットプラグがないので、イーサネット経由でIPv6アドレスを受信するかどうかを確認できません。

私がルーター構成で考えることができる最も近いページはこれです：

IPv6 LAN auto configuration page

私はISPとさらに連絡を取り合っており、現在の設定でそれを維持していますshould正常に機能します。 デスクトップPCでワイヤレスネットワークに接続したところ、実際にDHCPv6リースを受信して​​いることを確認できました。

両方のマシンには、同一の/etc/dhcpcd.confファイルと/ etc/netconfigファイルがあります（diff -u <(ssh laptop cat /etc/…) /etc/…を使用して確認）。それでも、Wi-Fiに接続する場合、dhcpcdログは大きく異なります。私のPCの場合：

_$ journalctl --follow --output=cat --unit=dhcpcd | grep ^eno1
eno1: rebinding lease of 192.168.1.2
eno1: leased 192.168.1.2 for 86400 seconds
eno1: adding route to 192.168.1.0/24
eno1: adding default route via 192.168.1.1
eno1: soliciting an IPv6 router
eno1: Router Advertisement from xxxx::xxxx:xxxx:xxxx:xxxx
eno1: adding address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64
eno1: adding route to xxxx:xxxx:xxxx:xxxx::/64
eno1: adding default route via xxxx::xxxx:xxxx:xxxx:xxxx
eno1: soliciting a DHCPv6 lease
_

ラップトップの場合：

_$ journalctl --follow --output=cat --unit=dhcpcd | grep ^wlp1s0
wlp1s0: rebinding lease of 192.168.1.6
wlp1s0: leased 192.168.1.6 for 86400 seconds
wlp1s0: adding route to 192.168.1.0/24
wlp1s0: adding default route via 192.168.1.1
wlp1s0: soliciting an IPv6 router
wlp1s0: no IPv6 Routers available
_

それらのWi-Fi接続構成も、インターフェース名を除いて同じです。

_Description='Automatically generated profile by wifi-menu'
Interface=wlo1
Connection=wireless
Security=wpa
ESSID=…
IP=dhcp
Key=…
_

Wiresharkは、ラップトップが実際に正しいMACアドレスからICMPv6ルーターアドバタイズメントを受信して​​いることを報告しており、問題はラップトップがルーターアドバタイズメントを処理していないことにあるという考えを裏付けています。

2台のマシンのIPテーブルの違いが手がかりを与えているようです。数年前に私のラップトップにUFWをインストールして以来、いくつかのルールが残っています。 2台のマシンのIPテーブルを比較すると、次のようになります。

_$ comm -23 <(ssh laptop cat iptable.txt) iptable.txt 
-P INPUT DROP
-P FORWARD DROP
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-logging-allow
-N ufw-logging-deny
-N ufw-not-local
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-skip-to-policy-forward
-N ufw-skip-to-policy-input
-N ufw-skip-to-policy-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-N ufw-user-forward
-N ufw-user-input
-N ufw-user-limit
-N ufw-user-limit-accept
-N ufw-user-logging-forward
-N ufw-user-logging-input
-N ufw-user-logging-output
-N ufw-user-output
…
_

_-P INPUT DROP_がこの問題の原因である可能性があると思いますか？ IPv6テーブルは同様の違いを示しています。

_-P INPUT DROP
-P FORWARD DROP
-N ufw6-after-forward
-N ufw6-after-input
-N ufw6-after-logging-forward
-N ufw6-after-logging-input
-N ufw6-after-logging-output
-N ufw6-after-output
-N ufw6-before-forward
-N ufw6-before-input
-N ufw6-before-logging-forward
-N ufw6-before-logging-input
-N ufw6-before-logging-output
-N ufw6-before-output
-N ufw6-logging-allow
-N ufw6-logging-deny
-N ufw6-reject-forward
-N ufw6-reject-input
-N ufw6-reject-output
-N ufw6-skip-to-policy-forward
-N ufw6-skip-to-policy-input
-N ufw6-skip-to-policy-output
-N ufw6-track-forward
-N ufw6-track-input
-N ufw6-track-output
-N ufw6-user-forward
-N ufw6-user-input
-N ufw6-user-limit
-N ufw6-user-limit-accept
-N ufw6-user-logging-forward
-N ufw6-user-logging-input
-N ufw6-user-logging-output
-N ufw6-user-output
_
arch-linuxipipv6netctl
3
l0b0

tl; dr修正：

  1. iptablesルールとチェーンを完全にリセットします
  2. 再適用 ファイアウォール設定

これは、次の組み合わせによって引き起こされました。

  1. -P INPUT DROP私のiptablesルールでは、システムのセキュリティ保護に関する以前の作業から残っています。
  2. Puppetファイアウォールの「パージ」ディレクティブ がファイアウォールを完全にリセットするという誤った仮定。私たちは皆、仮定が何をするか知っています…

助けてくれてありがとう！特に @ UncleBilly ファイアウォールルールの違いについて質問してください。

1
l0b0