web-dev-qa-db-ja.com

IPv6接続のタイムアウト

IPv6接続に問題があります。それらだけで。それらはおよそ10分ごとにタイムアウトします（私が想定している更新に対処するため）。

さまざまなPCで有線とワイヤレスを問わず、1年ほどで試したLinuxのすべてのdebianベースのフレーバーx86とx64で起こります。

私は現在、カーネル3.13.0-37-generic x86_64（以前は3.2.0-60）とNetworkManager0.9.8.8でLinuxMint17.1を使用しています。ダウンロードをすぐに再開しようとすると、「ホストへのルートがない」というメッセージが表示されることがあります。私のIPv6アドレスが一時的になくなったように見えるからです。
これのように： http://Pastebin.com/4Xida2q

デュアルスタックIPv4-IPv6（PPPoE）を実行しています。これは、Netgear DGND3700v2ルーター（ファームウェアバージョンV1.1.00.22_1.00.22）の構成方法です： http://i.imgur.com/YgxAyQb。 png

問題のネットワークプロファイルはignoreIPv6に設定されていますが、とにかくグローバルIPv6アドレスを取得しています。自動に変更しても違いはありません。これは紛らわしいですが、カーネルがその仕事をしているだけだと思います。

ファイアウォールルールまたはその欠如は何の違いもありませんが、基本的には次のとおりです。

iptables -P INPUT DROP
ip6tables -P INPUT DROP
iptables -P FORWARD DROP
ip6tables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -I INPUT  -p icmpv6 -j ACCEPT

LANにautoconfの代わりにDHCPを使用しようとしましたが、Windowsではタイムアウトは発生しませんが、Linuxではipv6接続が発生しません（グローバルアドレスを持っているように見えますが、とにかく「ネットワークに到達できません」というエラーが発生します）。

tcpdump -vvni wlan0 icmp6出力の関連部分

到達できない宛先：

19:25:05.381081 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}
19:25:12.948944 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}
19:25:18.446900 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 88) {GW's ipv6 - redacted} > {My pc's ipv6 link-local addr - redacted}: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:760:ffff:b1::34, source address {My pc's ipv6 link-local addr - redacted}

ルーターの要請：

19:25:18.775794 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) {Unknown link-local ipv6 addr - redacted} > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
      source link-address option (1), length 8 (1): {Unknown MAC - redacted}
        0x0000:  {Unknown MAC - redacted}

ルーター広告：

19:25:18.777825 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) {GW's ipv6 - redacted} > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 112
    hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 30000s, retrans time 1000s
      prefix info option (3), length 32 (4): 2a01:2000:2001:91b1::/64, Flags [onlink, auto], valid time 360s, pref. time 360s
        0x0000:  40c0 0000 0168 0000 0168 0000 0000 2a01
        0x0010:  2000 2001 91b1 0000 0000 0000 0000
      unknown option (24), length 24 (3): 
        0x0000:  4000 0000 0168 2a01 2000 2001 91b1 0000
        0x0010:  0000 0000 0000
      rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a01:2000:2001:91b1:861b:{Gateway}
        0x0000:  8800 0000 0258 2a01 2000 2001 91b1 861b
        0x0010:  {gateway MAC - redacted}
      mtu option (5), length 8 (1):  1492
        0x0000:  0000 0000 05d4
      source link-address option (1), length 8 (1): {gateway MAC - redacted}
        0x0000:  {gateway MAC - redacted}

私も時々このようなものを手に入れていますが、それが重要かどうかはわかりません：

17:09:42.546840 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1240) {GW's ipv6 - redacted} > {My pc's temp ipv6 addr - redacted}: [icmp6 sum ok] ICMP6, packet too big, mtu 1462

ルーターのradvd.conf（telnetを使用して検出）

interface group1 {
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag on;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvSourceLLAddress on;
    AdvReachableTime 30000;
    AdvRetransTimer 1000;
    AdvDefaultLifetime 1800;
    AdvCurHopLimit 64;
    AdvLinkMTU 1492;
    prefix 2a01:2000:2001:cd96::/64 {
        AdvPreferredLifetime 360;
        AdvValidLifetime 360;
        AdvOnLink on;
        AdvAutonomous on;
    };
    route 2a01:2000:2001:cd96::/64 {
            AdvRouteLifetime 360;
    };
    RDNSS 2a01:2000:2001:cd96:XXXX:XXXX:XXXX:XXXX  {
        AdvRDNSSOpen on;
    };
};
debiannetworkingipv6timeout
6
ppparadox

IPv6アドレスの自動構成について

現在、IPv6自動構成（一般）は、常にICMPv6パケットの交換に基づくルーター検出に依存しています。基本的な考え方は、ルーターからクライアントまでのネットワークに関する情報を取得することです。クライアントがルーターアドバタイズメントと情報を受信すると、DHCPを使用するかどうか、特にDHCPを他の構成にのみ使用するか、アドレス構成に使用するかを学習します。 NetworkManagerでテストされた特定の設定は Fedora Wikiで説明されています です。

NetworkManagerを使用したIPv6の設定

NetworkManager 0.9.6以降、NetworkManagerでのIPv6サポートはほとんど使用可能ですが、制限されたカーネル自動設定機能に大きく依存しています。 NetworkManager 0.9.10以降、IPv6構成はユーザースペースによって完全に管理され、カーネルははるかにうまく機能するように構成されています。 NetworkManagerの現在のブランチは1.0です。

次のセクションは、同様の問題のデバッグに適した、NetworkManagerを使用したホストの適切なテストセットアップを構成するのに役立ちます。

接続構成

/ etc/NetworkManager/system-connections /：

[ipv6]
method=auto

IPv6接続が正しく機能することが期待される場合は、method=ignoreを使用しないでください。 ignoreは、DNSなどを使用せずに限定されたカーネルベースのIPv6構成を許可しますが、推奨される方法は、NetworkManagerにIPv6構成を処理させることです。実際には、将来的にignoreを削除したいと考えています。また、IPv6自動設定標準には[既知のバグ] [1]があり、method=autoのときにNetworkManagerが回避しようとしています。

ファイアウォールが重要なパケットをブロックしていないことを確認してください

簡単なテストのために、ファイアウォールを許容的にします。

ip6tables -P INPUT ACCEPT
ip6tables -F INPUT

ip6tables -P OUTPUT ACCEPT
ip6tables -F OUTPUT

プライバシー拡張機能を使用していないことを確認してください

過去にプライバシー拡張機能（一時アドレスとも呼ばれます）に問題がありました。 Linux Mintを使用しています。これは、デフォルトでそれらをオンにするディストリビューションの1つです。

注：プライバシー拡張のため、発生している問題はnotです。このセクションはおそらくスキップできますが、同様の症状を持つ別の問題をデバッグしている可能性のある人のために残しておきたいと思います。

/etc/sysctl.conf：

net.ipv6.conf.default.use_tempaddr = 0

通常はallinsetad ofdefaultを使用しますが、NetworkManagerはファイルを読み取ってdefaultを探しています具体的には。この設定は、接続にプライバシー拡張機能を使用したくないことをNetworkManagerに納得させるのに十分なはずです。 NetworkManagerは接続ごとのプライバシー設定を無視するようになりました。その後、NetworkManagerを再起動するだけです。

ルーター要請および通知タイミング

更新された質問から、Networkmanagerがルーター要請を送信すると、ルーターはルーターアドバタイズメントですぐに応答することがわかります。これは、必要な情報を受け取ると、ホストの観点からは適切な動作です。問題は、それが常に起こるかどうかです。

また、ルーターは、アドレスがタイムアウトするよりも頻繁に、ルーター通知を定期的に送信する必要があります。また、ルーターからの情報を見逃した場合に備えて、タイムアウトが近づくと、ホストはルーターの要請を送信する必要があります。 NetworkManagerのバージョンによっては、カーネルの責任になります。

他の更新から、ルーターが必要な頻度でルーターアドバタイズメントを送信しないことは明らかです。一部の情報の有効性は360秒と短いですが、ルーターアドバタイズメントの頻度は最大600秒です。正しい構成では、いくつかのルーターが失われた場合に備えて、360秒の時間間隔でいくつかのルーター広告を配信します。

一方、ライフタイムが間もなく切れるとき、ホストはおそらくルーターの要請を介して情報を要求する必要があります。 tcpdumpを使用して要請と広告を監視し、カーネルが最後の広告から約6分以内に要請を送信するかどうかを確認できます。そうでない場合は、接続が最後のアドバタイズメントから6分間しか持続しない、つまり接続が確立されてから6分以上続くという症状が考えられます。

推奨ルーター構成

標準はいくつかの値を推奨するようですが、私はむしろ常識を使用します。非常に悪いリンク（wifiなどに適用されます）では、多くのパケットが失われる可能性があります。したがって、基本的には、すべてのライフタイムを少なくとも最大ルーターアドバタイズメント間隔の適切な倍数に保ちます。

MaxRtrAdvIntervalは600秒で、10分以内に更新された情報を取得するので便利です。 MinRtrAdvIntervalの唯一の目的は、時間を少しランダム化することです。そのため、たとえば、時間を維持するか、300秒を使用できます。すべてのライフタイムを変更できます。最大間隔の5倍、つまり3600秒は、すべての情報が1時間有効ですが、およそ10分ごとに更新されることを意味します。

最終メモ

ベンダーに連絡して、マシンのタイミングを修正することをお勧めします。構成可能かどうかはわかりません。ただし、ファイルを直接変更しても、構成をコミットするときにルーターがファイルを書き換えるので、おそらく役に立ちません。

また、カーネルネットワーク開発者に連絡して、ルーター要請の送信についてコメントすることもできます。コミュニケーションに私を含めてください。

7
Pavel Šimerda