5月2日の朝なんですが、これまで特に通信ができなかったことはないのですが、突然インターネットに接続できないようになりました。
環境はフレッツ光コラボのenひかりクロス固定IP接続(v6プラス)で、ルーターはLinux(debian)で構成した自前ルータだったのですが、こちらの自前のスクリプト(※1)とちがうものをつかっていてIPv6ネットワークプレフィックスを固定にしていた所為もあり、最初は原因がわからないしネットに接続できないのでやむなく一時的にスマホをUSBテザリングしてネットにつなげて情報収集しましたが、原因はわかりませんでした。
そこで、今一度スクリプトを見返したところ、前述のようにIPv6ネットワークプレフィックスを固定にしていたのでもしやと思い、dhclientをデバッグモードで走らせると指定していたプレフィックスとは異なるプレフィックスが割り振られていました。通信できないのは当然です。
今度は割り当てられたプレフィックスを指定し直したところIPv6は接続できるようになりましたが、IPv4で通信できません。これも前述のスクリプトと異なるものを使用していたので、少しづつデバッグしていったところ、curlで認証を受けるところがNGになっていました。ここで前出のスクリプトと見比べるとURLをダブルクォーテーションで囲っていなかったのでこれを修正したところ認証も通り、無事、IPv4も疎通できるようになりました。
これで一件落着と言いたいところなのですが、一部IPv6ネットワークプレフィックスを固定していたのでこれらの変更が必要だったので修正しました。小規模な宅内LANなので良かったのですが、これが大規模なLANでULA(ユニークローカルアドレス,IPv4のプライベートアドレスに相当)で運用されていない環境やIPv6でトンネルを張っていたりすると業務に支障がでるだろうなと思ったのは言うまでもありません。
最後に今後もプレフィックスが変更される可能性は否定できないので、スクリプトを前述のスクリプトに入れ替え(一部修正が必要でしたが)IPv6/IPv4の疎通を確認し、宅内LANのULA化はまだですが、ようやく一件落着となりました。
2024/05/12追記:こちらにULA化(GUA/ULA変換)について投稿しました。
今回は以上です。それでは。
追記1:調べたところ、フレッツ光ネクストのひかり電話無しの場合、wan側のraでprefixのPreferred LifetimeやRouter lifetimeが変化し、新しいprefixに切り替わるまえに何かしらの前兆はあるようです。
また、フレッツ光クロスでの固定IPの場合(つまりフレッツ光ネクストのひかり電話ありの場合と同じ)は、dhcpclientに対し "DHCPv6 Reconfigure message" で通知される様です。つまりdhcpでprefixが変わる場合があるので、半固定という表現は正しくなく、動的だと言うほうが正しいと思いました。
参考: IP通信網サービスのインターフェース 第三分冊(フレッツ 光クロス編)より
追記2: isc dhclientではデフォルトではDHCPv6 Reconfigure messageを受信しませんし、受信する設定をしても以下のようなログが吐かれるだけだそうです。
つまり、上記の設定をおこないsyslogを監視し、"RCV: Reconfigure message on enp1s0f0" のメッセージが来た時にrsyslogで何らかの処理を行い、スクリプトを再度実行するなどして自動的に対応できる可能性はあるかもしれません。
追記3: 以下、rsyslog設定とスクリプトをざっくりと書いてみました。
/etc/rsyslog.conf
/usr/local/sbin/reconfigure-enp1s0f0.sh # chmod +x
環境はフレッツ光コラボのenひかりクロス固定IP接続(v6プラス)で、ルーターはLinux(debian)で構成した自前ルータだったのですが、こちらの自前のスクリプト(※1)とちがうものをつかっていてIPv6ネットワークプレフィックスを固定にしていた所為もあり、最初は原因がわからないしネットに接続できないのでやむなく一時的にスマホをUSBテザリングしてネットにつなげて情報収集しましたが、原因はわかりませんでした。
そこで、今一度スクリプトを見返したところ、前述のようにIPv6ネットワークプレフィックスを固定にしていたのでもしやと思い、dhclientをデバッグモードで走らせると指定していたプレフィックスとは異なるプレフィックスが割り振られていました。通信できないのは当然です。
今度は割り当てられたプレフィックスを指定し直したところIPv6は接続できるようになりましたが、IPv4で通信できません。これも前述のスクリプトと異なるものを使用していたので、少しづつデバッグしていったところ、curlで認証を受けるところがNGになっていました。ここで前出のスクリプトと見比べるとURLをダブルクォーテーションで囲っていなかったのでこれを修正したところ認証も通り、無事、IPv4も疎通できるようになりました。
これで一件落着と言いたいところなのですが、一部IPv6ネットワークプレフィックスを固定していたのでこれらの変更が必要だったので修正しました。小規模な宅内LANなので良かったのですが、これが大規模なLANでULA(ユニークローカルアドレス,IPv4のプライベートアドレスに相当)で運用されていない環境やIPv6でトンネルを張っていたりすると業務に支障がでるだろうなと思ったのは言うまでもありません。
最後に今後もプレフィックスが変更される可能性は否定できないので、スクリプトを前述のスクリプトに入れ替え(一部修正が必要でしたが)IPv6/IPv4の疎通を確認し、
2024/05/12追記:こちらにULA化(GUA/ULA変換)について投稿しました。
今回は以上です。それでは。
追記1:調べたところ、フレッツ光ネクストのひかり電話無しの場合、wan側のraでprefixのPreferred LifetimeやRouter lifetimeが変化し、新しいprefixに切り替わるまえに何かしらの前兆はあるようです。
また、フレッツ光クロスでの固定IPの場合(つまりフレッツ光ネクストのひかり電話ありの場合と同じ)は、dhcpclientに対し "DHCPv6 Reconfigure message" で通知される様です。つまりdhcpでprefixが変わる場合があるので、半固定という表現は正しくなく、動的だと言うほうが正しいと思いました。
参考: IP通信網サービスのインターフェース 第三分冊(フレッツ 光クロス編)より
2.4.2.1.2 IPv6(IPoE)通信における IPv6 アドレス情報付与方法 端末機器は、RFC3315、RFC3633に規定されるDHCPv6-PD(DHCPによるIPv6 Prefix Option)を使用しIPv6 Prefixを取得することを推奨します。端末機器のアドレスとして利用可能なアドレスは、DHCPv6-PDを使用して IP通信網から送信するメッセージに含まれる56bitのIPv6 Prefixを利用して生成したIPv6のグローバル・ユニキ ャストアドレスのみです。なお、DHCPv6を利用した128bitのIPv6アドレスの取得はできません。 サービスの利用状況等によりIP通信網から送信されるIPv6 Prefixの値は変更される場合があります。なお、 IPv6 PrefixのサイズはIP通信網より指定をして送信します。 IP通信網は、RFC2461に規定されているNDP(Neighbor Discovery Protocol)に基づき、ルータ広告(Router Advertisement)メッセージを端末機器に送信しますが、ルータ広告のOther stateful configuration flag及び Managed address configuration flagが1を設定される場合があります。 なお、IP通信網はInformation-Requestには対応しておりません。
追記2: isc dhclientではデフォルトではDHCPv6 Reconfigure messageを受信しませんし、受信する設定をしても以下のようなログが吐かれるだけだそうです。
RCV: Reconfigure message on enp1s0f0 from fe80::xxxx:xxxx:xxxx:xxxx.なお受信するには以下を/etc/dhclient.confに追加します。(interface "enp1s0f0"の部分は環境に合わせてください。)
option dhcp6.vendor-class code 16 = {integer 32, integer 16, string}; interface "enp1s0f0" { also request dhcp6.sntp-servers; also request dhcp6.vendor-opts; also request dhcp6.reconf-msg; #Reconfigure authentication option send dhcp6.reconf-accept; #Reconfigure accept option }(こちらを参考にさせていただきました。ありがとうございます)
つまり、上記の設定をおこないsyslogを監視し、"RCV: Reconfigure message on enp1s0f0" のメッセージが来た時にrsyslogで何らかの処理を行い、スクリプトを再度実行するなどして自動的に対応できる可能性はあるかもしれません。
追記3: 以下、rsyslog設定とスクリプトをざっくりと書いてみました。
/etc/rsyslog.conf
########################### #### GLOBAL DIRECTIVES #### ########################### $template WaitSeconds,"20"/etc/rsyslog.d/gw01.conf
if ($hostname == "gw01" and $msg contains "RCV: Reconfigure message on enp1s0f0") then ^/usr/local/sbin/reconfigure-enp1s0f0.sh;WaitSecondsここで、 systemctl restart rsyslog.service としrsyslogに設定を反映させる。
/usr/local/sbin/reconfigure-enp1s0f0.sh # chmod +x
#!/bin/bash logger "$0 is triggerd." WANDEV=enp1s0f0 WANDEVMAC=0c:aa:bb:cc:dd:ee dhclient -r -6 -v -pf /run/dhclient6.$WANDEV.pid -lf /var/lib/dhcp/dhclient6.$WANDEV.leases -I -P -N -df /var/lib/dhcp/dhclient.$WANDEV.leases $WANDEV #just for sure kill $(cat /run/dhclient6.$WANDEV.pid) rm -rf /run/dhclient6.$WANDEV.pid dhclient -6 -v -pf /run/dhclient6.$WANDEV.pid -lf /var/lib/dhcp/dhclient6.$WANDEV.leases -I -P -N -df /var/lib/dhcp/dhclient.$WANDEV.leases $WANDEV while [ ! -f /run/dhclient6.$WANDEV.pid ]; do ifdown $WANDEV ifup $WANDEV sleep 4 done #自前のスクリプト(※1) /usr/local/sbin/ipt-v6p-static-lan-01.sh #その他のスクリプト等 #logger "/usr/local/sbin/dhcpv6-prefix-reconfigure.sh $WANDEV $WANDEVMAC" #/usr/local/sbin/dhcpv6-prefix-reconfigure.sh $WANDEV $WANDEVMAC logger "$0 ends."テスト
sudo logger "RCV: Reconfigure message on enp1s0f0 from fe80::1111:2222:3333:4444."確認
sudo tail -n 50 /var/log/syslog
コメント
コメントを投稿