IPv4とIPv6の優先度設定

前回の記事でIPv4とIPv6のデュアルスタックにしてみた。どうやらシステムはうまく動き出したぞ!ということでpingしてみる。

>ping hogeserver

hogeserver.hogeserver.hogedns.jp [172.16.1.100]に ping を送信しています 32 バイトのデータ:
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 =1ms TTL=64

172.16.1.100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

 

おっとっと…




Windows10のIPv4/IPv6の優先度については完全な答えがココにある。
パソコンたすかるHowTo / IPv6の優先度の変更

コマンドはともかく、その表示結果について書かれていることに加えてもう少し調べてみた。

>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

 

さて…今になるとようやくこのページの意味がわかり始めた…
Wikipedia / IPv6アドレス 2018/12/1現在。

::1/128 優先度50 0000:0000:0000:0000:0000:0000:0000:0001/128 ループバックアドレス。自分自身を表す。
::/0 優先度40 0000:0000:0000:0000:0000:0000:0000:0000/0 デフォルトルート。IPv4の0.0.0.0/0に相当する。 デフォルトルートはあるIPアドレスに対してルートが特定できない場合に利用される。
::ffff:0:0/96 優先度35 0000:0000:0000:0000:0000:ffff:0000:0000/96 IPv4射影IPv6アドレス(IPv4-mapped IPv6 address)。 ウチのServer(172.16.1.100)のIPv4のアドレスをそのまま表示するとこうなる。 ::ffff:172.16.1.100/96 ← IPv4部分はコロンじゃなくピリオド。
2002::/16 優先度30 歴史的 2002:0000:0000:0000:0000:0000:0000:0000/16 6to4(IPv4のネットワーク上にIPv6のパケットを流せるようにするという技術)で利用される。だが、WikipediaによればHistricになっている模様。
2001::/32 優先度5 廃止 2001:0000:0000:0000:0000:0000:0000:0000/32 Teredo(IPv6移行技術の一つで、IPv4を用いてインターネットに接続可能であるが、通信経路のどこかに IPv6 を理解しない通信機器が存在するために IPv6 ネットワークと直接接続ができないホストに対し、完全な IPv6 接続を提供する)で利用される。
fc00::/7 優先度3 fc00:0000:0000:0000:0000:0000:0000:0000/7 ユニークローカルアドレス。ローカルな通信のために使われる。IPv4のプライベートアドレス(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)に相当。後半半分(fd00::/8)は「確率論的にユニークな(probabilistically unique)」アドレスとして使用され、40ビットの擬似乱数を用いて/48の割り当てを得る。 ウチのDHCPv6がばらまいているのはこれで、仮によそのネットワークとつなぐことがあってもまず問題なくユニーク性が保てる
fec0::/10 優先度1 廃止 fec0:0000:0000:0000:0000:0000:0000:0000/10 サイトローカルアドレス。組織内のサイトネットワーク内でのみ有効であると特定されたアドレスだったが「サイト」という用語の定義が曖昧なためULAに置き換えられた。
3ffe::/16 優先度1 返還 3ffe:0000:0000:0000:0000:0000:0000:0000/16 6boneネットワークの試験目的に割り当てられたもので、現在はアドレスプールに返還された。
::/96 優先度1 廃止 0000:0000:0000:0000:0000:0000:0000:0000/96 IPv4互換アドレス。IPv4互換アドレスは、IPv6移行技術の中でIPv4アドレスを表現するのに使用されたが、現在は廃止された。

この上、接続にはより小さいスコープが優先されるため、ローカルリンクアドレスの優先度が高いとのこと。

ここまで学習してきたところで考えてみると、なぜユニークローカルアドレスの優先度が3に設定されているのかがうまく理解できない。IPv6優先ならばIPv4よりもULAが優先されるべきと思われるが、探してみたけれども理由が見つからなかった。ローカルの話なんだから、グローバールユニークアドレスよりも優先されていいんじゃないかとすら思う。

試しにコマンドプロンプトを「管理者として実行」し、プライオリティを変えてみると…

>netsh interface ipv6 set prefixpolicy fc00::/7 41 13
OK                                     ↑プレフィックス 優先順位 ラベル

>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        50      0  ::1/128
        41     13  fc00::/7 ← ココに持ってきてみた
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

>ping hogeserver

hogeserver.hogeserver.hogeddns.jp [fdxx:xxxx:xxxx:xxxx::100]に ping を送信しています 32 バイトのデータ:
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 =1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms

fdxx:xxxx:xxxx:xxxx::100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

 

ULAでアクセスができた。 もちろん、インターネットにもIPv6で出ていくことが確認できた。

 

やったこと

ここからは単なるメモ。未解決。

 

Ubuntuで優先度設定

Ubuntuでも完全な答えがココにある。
パソコンたすかるHowTo / IPv6の優先度の変更

だが、私が試してみたところでは、実際に優先度が変わることはなかった。

とりあえず設定方法を理解したつもりになったところで、こたつでPC(Ubuntu14.04ベースのBean)してみたらIPv4はDHCPv4から取得するしDDNSも機能するのだが、IPv6はDHCPv6から取得できず、ルーター発信のRAに基づくアドレスの自動構成のみ行っていた。

そのため、まず、バージョンによる差異はないのか試してみた。 Ubuntu18.04-desktop-amd64をミニマムインストール。インストール直後は IPv6 で通信。 ubuntu-mate-16.04.4-desktop-amd64をインストール。インストール直後はIPv4で通信。ping6は通る。/etc/gai.confをいじって再起動しても変化なし。 ubuntu-ja-14.04-desktop-amd64をインストール。IPv6はDHCPv6から取得できなかった。IPv6の設定をDHCPのみにするとようやくアドレスが取得できるが、ping6もできない状態。

いやいやおかしいよね、そんなはずないよね…とNetworkManagerの扉を開くことに。 NetPlanはとっても言うことを聞いてくれる感じがあって良いのだけれど、NetworkManagerとはうまく付き合ってこられなかったので、ここで色々と確認してみようと思った。

そもそもNetworkManagerというのは何なのか…
Wikipedia / NetworkManager
当時利用するのをやめようと思ったのは仕方がなかった、ちょっとわからない。

以下に書かれているのが概要を表しているように思う。
redhat / 第8章 NETWORKMANAGER

NetworkManager (ネットワークマネージャ) は、ネットワークデバイスと接続が利用可能な時にそれらをアクティブに維持するよう試行する動的ネットワーク制御及び設定システムです。NetworkManager は、コアデーモン、ネットワークステータス情報を提供する GNOME 通知スペースアプレット、及び接続とインターフェースの作成、編集、削除が可能なグラフィカル設定ツールで構成されています。NetworkManager を使用すると、イーサネット、ワイヤレス、モバイルブロードバンド (携帯 3G など)、DSL や PPPoE (Point-to-Point over Ethernet イーサネット経由のポイントツーポイントプロトコル) のようなタイプの接続を設定できます。さらに、 NetworkManager により、ネットワークエイリアス、静的ルート、DNS 情報、VPN 接続の他、多くの接続固有のパラメータの設定が可能になります。そして、NetworkManager は D-Bus により効果的な API を提供するため、アプリケーションはネットワークの設定と状態をクエリ、制御することができます。

 

NetworkManagerとGUI、コマンドラインツール、コマンドラインGUIツールからなっている。
@It / CentOS 7のネットワーク管理「NetworkManager」を極める (1/5)

Ubuntu14.04で動作しているのは0.9.8.8。

$ NetworkManager --version
0.9.8.8

 

DHCPv6のみを受け取るようにしたところ、配布されたアドレスを使うようになる。

で、もとに戻したらDHCPv6と自動構成が行われるようになる。

で、2日後に起動してみたらこんな事になった。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.101/16 brd 172.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 scope global ← これは今日取得したIPv6のアドレス
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 scope global ← これは最初に取得したIPv6のアドレス
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global temporary dynamic 
       valid_lft 14040sec preferred_lft 12240sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic 
       valid_lft 14040sec preferred_lft 12240sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

 

で、宅内へのpingを試してみた。pingはIPv4で動作し、ping6するとIPv6で動作した。

しかし、ココで気づく。なんで、DHCPからもらったアドレスがforeverなのよ?全然理解できないよこれ。

よくわからないから、アップデートを全部適用してみた。で、再起動してみた。しかし結果は、古いIPv6アドレスがなくなっただけで、ほかは何も変わらなかった。foreverだよ、なんでだよ。

NetworkManagerはDHCPクライアントを取り込もうとしているらしく、リースファイルは/var/lib/NetworkManagerにあった。dhclientの設定ファイルから自分で必要な物を取り出して設定ファイルなんかも作っていた。

有線接続を無効にすると、IPv4のDHCPクライアント設定は消えるが、IPv6のDHCPクライアント設定は消えなかった。確認してみたら、IPv6のローカルスコープのアドレスは残っていた。

ネットワークを無効にすると、IPv4とIPv6のDHCPクライアント設定が消えた。

さらに、/var/lib/NetworkManagerの中にleasesファイルが6つあった。 ファイル名は以下な感じ。

dhclient-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
dhclient6-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient6-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient6-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease

 

dhclient-ああああ-eth0.lease のところの「ああああ」は、UUIDとのことで、これは/etc/NetworkManager/system-connections の中にあるファイルに書かれているんだそうな。

UUIDが3回も変わってたのか…あー、もう、本当にわからないわ。
Linuxの缶詰 / Network ManagerとUUIDについて
調べて教えてくれている人がいました。何かの理由でネットワークインターフェースをコントロールできないと、UUIDを作って割り当てコントロール配下においているみたい。思い当たる操作といえば、アップデートを掛けたことくらいかなぁ。

試しに、NetworkManagerのinternalなDHCPクライアントを利用してみたところで、DHCPv6のアドレスが作れないときにはV6のleaseファイルが更新されていないことに気づいた。

GUIでネットワークを無効にして…
/etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

no-auto-default=xx:xx:xx:xx:xx:xx,

dhcp=internal

[ifupdown]
managed=false

 

GUIからネットワークを有効に。

$ ll /var/lib/NetworkManager
-rw-r--r--  1 root root   86 12月  9 08:17 NetworkManager.state
-rw-r--r--  1 root root 2291 12月  9 08:17 dhclient-eth0.conf
-rw-r--r--  1 root root  994 12月  9 08:17 dhclient-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
-rw-r--r--  1 root root  304 12月  9 08:17 dhclient6-eth0.conf
-rw-r--r--  1 root root 1001 12月  8 21:22 dhclient6-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
-rw-r--r--  1 root root  157 12月  9 08:17 timestamps

 

あぁ、RAが2種類飛んできたときの動作をちゃんと定義できていない可能性。

nmcliはこんな感じで使うみたい。

$ sudo nmcli nm enable false ← ネットワークを無効化
$ sudo nmcli nm enable true  ← ネットワークを有効化
$ sudo nmcli nm              ← ネットワークの状態確認(引数にstatusを付けても同じ動作)
実行中          状態            WIFI ハードウェア WIFI       WWAN ハードウェア WWAN      
実行中          接続済み        有効            有効       有効            有効      
$ nmcli device wifi list     ← 飛んでいるWifiの状態一覧(Wifi装置がなかったので何も出なかった)
SSID                              BSSID               モード           周波数     レート     信号     セキュリティ アクティブ
$ nmcli device list          ← デバイスの一覧が出てくる
GENERAL.デバイス:                   eth0
GENERAL.タイプ:                      802-3-ethernet
GENERAL.ベンダー:                   Advanced Micro Devices, Inc. [AMD]
…<省略>
$ nmcli device disconnect iface eth0 ← デバイスを指定して切断(IPv6のLLAは残る)
$ nmcli con up id 有線接続\ 1        ← IDを指定して接続
$ nmcli con down id 有線接続\ 1      ← IDを指定して切断(だけど自動接続することを禁じないためにすぐに再起動する)

 

Wifi装置がなくても、WifiハードウェアもWifiも有効と言われる。 WWANってのはワイヤレスWANだそうで、キャリアの通信SIMとかを挿して使う感じ?

 

2日後

さらに2日後、起動してみてDHCPクライアントの動作を見てみようと思った…
FreeKB / Obtain, renew, and release IP address using DHCLIENT command in Linux

$ cat /var/lib/dhcp/dhclient.leases
$

 

からっぽ?これはおかしい…IPアドレスをリリースするコマンドを叩いてもリリースできない。これは絶対変だ。

参照先のページでAvahiを止めて無効化すると書かれていた。調べてみると、お互いに自分の状態を伝えあって名前解決ができるようにする仕組みの模様。mDNSという。 ウチは全てをコントロールしようとしてDHCPを立ててDNSも動かしており、iPhone/iPadとプリンタとかが勝手にやり取りし合うことを止めることまではしないけれど、WindowsやLinuxでこのサービスを使う理由はまったくない状況。

そこで、avahi-daemonを止めることにした。

$ sudo apt install sysv-rc-conf
$ sudo sysv-rc-conf

 

avahi-daemonが起動しないように設定して再起動してみる。
・・・・・・avahi-daemonが起動してる。

仕方がないので、消して再起動。

$ sudo apt remove avahi-daemon

 

・・・・・・avahi-daemonが起動してる。本当にしぶとい。

$ sudo apt remove avahi-autoipd

 

まだ起動している。本当にどうなっているんだろう?

$ sudo apt remove avahi-daemon --purge
$ sudo apt remove avahi-autoipd --purge

 

これにより、/etc/network/if-up.d にあったavahi-daemonとavahi-autoipdが消えて起動しなくなった。 しかし、これでもリースファイルの中身は空っぽのまま。それでいてDHCPからIPアドレスが振り出されている。なぜ?

その後、再起動したところ、優先接続 1が有効にならずどこにもいけなくなった。

 

さらにその後

ガンガンテストしようとしたら、とにかくUbuntuのインストールが必要に。 都度SSHを設定するのも面倒だから、vmware-tools をインストールして色々と楽にしたかった。
kashiの日記 / ubuntu 16.04 インストール(2) vmware tools

$ sudo apt install open-vm-tools open-vm-tools-desktop
$ sudo reboot

 

これは大変ありがたい知識だった。

 

さいごに

まぁ、やりたいことができなかった愚痴なんですが、これじゃIPv6の普及って難しいのかなぁって思った。

IPv6オンリーなPCを作るとアクセスできないサイトが多数だし、IPv6オンリーなサーバーを作ってもテストのためのテザリングがIPv6に対応してない。IPv6でサービスを立てても外からアクセスできないじゃん。

宅内のIPv6だって実際には外から管理されてるわけで、自分の思い通りにしようと思ってもなかなかうまくいかない。どうにかしてサーバーを立てても、今度はクライアントが思い通りに動かない…と。

IPv4の枯渇って結局どうなったんだろう?

お気軽にどうぞ ~ 投稿に関するご意見・感想・他

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です