Posted inネットワーキング

Linuxでradvdを使用したIPv6 SLAACとRDNSSの設定：DHCPv6なしでIPv6を自動構成する

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

深夜2時15分。社内クラスターへのデュアルスタックネットワークの展開を終えたばかりのところで、新たにプロビジョニングした48台のKubernetesワーカーノードが一斉にフラッピングを始めました。どのノードもIPv6のデフォルトゲートウェイやDNSリゾルバーを取得できていません。

枕元でPagerDutyのアラートが鳴り響いています。このような障害が発生した際、反射的にステートフルなISC Keaやwide-dhcpv6サーバーを立ち上げようとしがちですが、大抵の場合は悪手です。大規模なノード群に真に必要なのは、予測可能で自己修復性を持つステートレスなアドレス割り当てです。

Router Advertisement Daemon（radvd）は、ICMPv6のRouter Advertisement（RA）フレームをブロードキャスト（マルチキャスト）することで、この問題をスマートに解決します。ノードはStateless Address Autoconfiguration（SLAAC）を通じて自律的にグローバルアドレスを設定し、RDNSS（RFC 8106）経由で再帰型DNSサーバーを取得します。何より最大の利点は、ゲートウェイ側でクライアントの状態を一切保持・追跡する必要がない点です。

クイックスタート（5分）：SLAACとRDNSSを稼働させる

時間との闘いの中では、一刻も早くパケットを疎通させる必要があります。Debian/UbuntuまたはRHELベースのLinuxルーターで自動構成を有効化する手順は以下の通りです。

1. IPv6フォワーディングの有効化

LinuxカーネルでIPv6パケットの転送が無効になっていると、radvdは起動時に致命的なエラーログを出力して即座に終了します。sysctlフラグを変更して即時反映させます。

# カーネルメモリへ即時反映
sysctl -w net.ipv6.conf.all.forwarding=1

# 再起動後も設定を永続化
echo "net.ipv6.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-ipv6-forwarding.conf
sudo sysctl --system

2. LANインターフェースへの静的IPv6プレフィックスの割り当て

内部インターフェース（ここではeth1を使用）に、対象となる/64サブネット内の静的アドレスを割り当てます。

sudo ip -6 addr add 2001:db8:1000:1::1/64 dev eth1
sudo ip link set eth1 up

3. radvdのインストールと設定

# Ubuntu/Debianの場合
sudo apt-get update && sudo apt-get install -y radvd

# RHEL/AlmaLinux/Rockyの場合
sudo dnf install -y radvd

以下の実績ある設定を/etc/radvd.confに書き込みます。スタックしたクライアントを迅速に復旧させるため、広告間隔を3〜10秒に短縮しています。

sudo tee /etc/radvd.conf << 'EOF'
interface eth1 {
    AdvSendAdvert on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;

    prefix 2001:db8:1000:1::/64 {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr on;
    };

    RDNSS 2001:db8:1000:1::1 2606:4700:4700::1111 {
        AdvRDNSSLifetime 30;
    };
};
EOF

4. サービスの起動と確認

sudo systemctl restart radvd
sudo systemctl status radvd

5秒以内に、eth1上のクライアントは2001:db8:1000:1::/64に一致するグローバルアドレスを生成します。また、ルーターのリンクローカルアドレスをデフォルトルートとして登録し、ローカルのリゾルバ設定を自動的に構成します。

徹底解説：SLAACとRDNSSの内部動作の仕組み

対症療法は目の前の火消しには役立ちますが、本番環境の負荷の下でシステムを安定運用し続けるには、背後にあるプロトコルのやり取りを正しく理解することが不可欠です。

ステートレスアーキテクチャ

従来のDHCPv4やステートフルなDHCPv6サーバーは、集中型のリースデータベースを保持し、MACアドレスとIPアドレスのマッピングを追跡して更新タイマーを管理します。これに対し、SLAACはこのモデルを根本から覆します。ルーターは単なる情報通知ビーコンとして振る舞い、IPアドレスの生成そのものをクライアント側に完全に委ねます。このアプローチにより、大規模なベアメタルサーバー群や頻繁に生成・破棄されるコンテナブリッジにおいて、単一障害点（SPOF）を排除できます。

主要な設定ディレクティブ

  • AdvSendAdvert on: radvdに対して定期的なマルチキャストRAの送信を指示し、ICMPv6 Type 133（Router Solicitation）に対して数ミリ秒以内に応答するようにします。
  • AdvManagedFlag off（Mフラグ）: アドレス取得のためにステートフルDHCPv6サーバーへ問い合わせを行わないようクライアントに指示します。これをonに設定すると、クライアントはDHCPv6経由でアドレスリースを要求するようになります。
  • AdvOtherConfigFlag off（Oフラグ）: NTPサーバーやSIPゲートウェイなどの追加パラメータを取得するために、ステートレスDHCPv6へ問い合わせを行うかどうかを制御します。MフラグとOフラグの両方をoffにしておくことで、純粋な自律型SLAAC環境を維持できます。
  • AdvAutonomous on（prefix内のAフラグ）: SLAACの根幹を担うスイッチです。通知された64ビットのプレフィックスと、クライアント自身のローカルな64ビットインターフェース識別子を組み合わせることを許可します。クライアントはこのサフィックスを、固定的なEUI-64またはRFC 7217に基づくランダム化されたプライバシー拡張機能を用いて生成します。
  • RDNSS（RFC 8106）: 初期段階のSLAAC展開ではルートとプレフィックスしか配信できず、DNSサーバーを配布するためだけに別途DHCPv6デーモンを並行稼働させる必要がありました。現在のLinux、macOS、Windows 10/11、Androidは、RAフレームから直接RDNSSおよびDNSSLのペイロードを解析して適用できます。

高度な運用テクニック：ルート優先度、無停止リナンバリング、MTU調整

冗長化されたトポロジーにおいてデフォルト設定のまま運用していると、いずれ非対称ルーティングやパケットドロップが発生する原因となります。

ダウンタイムゼロのプレフィックス移行（リナンバリング）

上位の上流プロバイダーを切り替える際やデータセンターのリナンバリングを行う際は、新旧両方のサブネットを同時に広告します。廃止予定のプレフィックスに対してAdvPreferredLifetimeを0に設定することで、エンドポイントは既存のTCP接続を旧アドレスで維持しつつ、すべての新規ソケットは新ブロックのアドレスにバインドするようになります。

interface eth1 {
    AdvSendAdvert on;
    MinRtrAdvInterval 30;
    MaxRtrAdvInterval 100;

    # 新規プライマリプレフィックス
    prefix 2001:db8:2000:1::/64 {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 86400;      # 24時間有効
        AdvPreferredLifetime 14400;  # 4時間推奨（Preferred）
    };

    # 旧ブロックの段階的廃止：既存の接続は維持、新規ソケットは作成不可
    prefix 2001:db8:1000:1::/64 {
        AdvOnLink on;
        AdvAutonomous on;
        AdvValidLifetime 7200;       # 2時間後に完全破棄
        AdvPreferredLifetime 0;      # 即座に非推奨化（Deprecated）
    };

    DNSSL internal.infra.local corp.example.com {
        AdvDNSSLLifetime 100;
    };
};

ルーター優先度とMTUクランプ

同一のレイヤー2セグメント上でアクティブ・パッシブ構成のエッジルーターを稼働させる場合は、AdvDefaultPreferenceを設定します。これにより、セカンダリノードが予期せずアウトバウンドトラフィックを横取りするのを防ぐことができます。

interface eth1 {
    AdvSendAdvert on;
    AdvDefaultPreference high; # 設定可能な値: low, medium, high
    AdvLinkMTU 1500;
    AdvCurHopLimit 64;
};

トラブルシューティングと切り分け：応答しないノードの復旧

クライアントがデフォルトルートやアドレスを取得できない場合は、以下のトリアージチェックリストに従って確認を進めてください。

1. radvdumpによる広告パケットのキャプチャ

推測に頼るのはやめましょう。デーモンに付属しているパケットデコーダーツールを使用します。

sudo radvdump

このユーティリティは全ノードマルチキャストグループff02::1にバインドし、リアルタイムのRAフレームを有効な設定ブロック形式で出力します。10秒経過してもターミナルに何も出力されない場合は、途中のスイッチがマルチキャストトラフィックをドロップしていないか確認してください。

2. ICMPv6フィルタリングの検証

ICMPv4の遮断はずさんな設計ですが、ICMPv6の遮断は致命的です。ICMPv6を破棄すると、近隣探索プロトコル（NDP）、Path MTU Discovery、そしてSLAACが完全に機能しなくなります。

ホストのファイアウォールとスイッチのACLの双方で、ICMPv6 Type 133から136までが明示的に許可されていることを確認してください。

# Router Solicitation（ルーター要請）およびRouter Advertisement（ルーター広告）を明示的に許可
sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT

# Neighbor Solicitation（近隣要請）およびNeighbor Advertisement（近隣広告、ARP相当）を明示的に許可
sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT
sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT

3. マルチホームクライアントにおけるaccept_raカーネルの罠の解消

コンテナホストやVPNエンドポイントとして構成されたLinuxシステムで頻繁に直面する落とし穴があります。クライアント側でnet.ipv6.conf.all.forwarding=1が有効になっている場合、カーネルは受信したすべてのRouter Advertisementを自動的に無視し、accept_raパラメータが自動的・暗黙的に0に設定されてしまいます。

クライアント側のインターフェースの状態を確認します。

sysctl net.ipv6.conf.eth0.accept_ra
sysctl net.ipv6.conf.eth0.autoconf

転送ノード（ルーター設定）であっても、クライアントのカーネルにRAを強制的に受け入れさせます。

sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2

accept_ra=2を設定することで、内部ブリッジやコンテナ間でパケットを転送している状態でも、インターフェースがデフォルトルートとSLAACアドレスを確実にバインドするようになります。

/etc/radvd.confをGitでバージョン管理し、すべてのVLANでICMPv6を確実に通過させておけば、ステートフルなDHCPのオーバーヘッドなしに、IPv6ノード群を安定して自動構成できるようになります。

Share:
Tags: