web-dev-qa-db-ja.com

KVMゲストで20分後にIPv6接続が失われる

HetznerでKVM=仮想化サーバーを設定しています。HetznerはマスターIP（95.xxx.xxx.235）と/ 29 IPv4サブネット（95.xxx.xxx.184/29）および/ 64 IPv6ネットワーク（2a01：xxxx：xxxx：xxxx ::/64）。

KVM Guest（Debian Stretch）は、ネットワーキングサービスの再起動でいずれかの再起動から20分後にIPv6接続を失います。接続が失われても、デフォルトゲートウェイ（fe80 :: 1）にpingできます。IPv4接続は常に維持され、問題はありません。

現在、インターフェースはブリッジモードでmacvlanとして設定されており、VEPAモードとプライベートモードも試してみました。また、NICタイプはe1000に設定されていますが、virtioを試してみました。

接続が失われた後、私は物理的にTCPダンプをホストから取得しましたNICホストにエコー要求があり、エコー応答が到着することを示していますインターフェイス、しかしゲストから取られたtcpdump NIC NICを離れる要求だけを見ることができました.

/ etc/network/interfaces on Host：

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp2s0
iface enp2s0 inet static
  address 95.xxx.xxx.235
  netmask 255.255.255.192
  gateway 95.xxx.xxx.193
  up route add -net 95.xxx.xxx.192 netmask 255.255.255.192 gw 95.xxx.xxx.193 dev enp2s0

iface enp2s0 inet6 static
  address 2a01:xxx:xxx:xxx::2
  netmask 64
  gateway fe80::1

/ etc/network/interfaces on Guest：

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto ens3
iface ens3 inet static
    address 95.xxx.xxx.187
    netmask 255.255.255.248
    gateway 95.xxx.xxx.185

iface ens3 inet6 static
    address 2a01:xxx:xxx:xxx::20
    netmask 64
    gateway fe80::1

＃route -6 -n on Host：

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2a01:xxxx:xxxx:xxxx::/64          ::                         U    256 8  1162 enp2s0
fe80::/64                      ::                         U    256 0     0 macvtap0
fe80::/64                      ::                         U    256 0     0 enp2s0
::/0                           fe80::1                    UG   1024 8  4534 enp2s0
::/0                           ::                         !n   -1  1 11069 lo
::1/128                        ::                         Un   0   9    81 lo
2a01:xxxx:xxxx:xxxx::/128         ::                         Un   0   1     0 lo
2a01:xxxx:xxxx:xxxx::2/128        ::                         Un   0   9    82 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:1069/128   ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:22e1/128   ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:201/128   ::                         Un   0   2    79 lo
ff00::/8                       ::                         U    256 0     0 macvtap0
ff00::/8                       ::                         U    256 0     0 enp2s0
::/0                           ::                         !n   -1  1 11069 lo

＃route -6 -n on Guest：

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2a01:xxxx:xxxx:1414::/64          ::                         U    256 0     0 ens3
fe80::/64                      ::                         U    256 0     0 ens3
::/0                           fe80::1                    UG   1024 2    77 ens3
::/0                           ::                         !n   -1  1  6846 lo
::1/128                        ::                         Un   0   5   525 lo
2a01:xxxx:xxxx:xxx::20/128       ::                         Un   0   3    70 lo
fe80::xxxx:xxxx:xxx:22e1/128   ::                         Un   0   2     6 lo
ff00::/8                       ::                         U    256 0     0 ens3
::/0                           ::                         !n   -1  1  6846 lo

＃ip -6ホスト上の近隣：

2a01:xxxx:xxxx:xxxx::20 dev enp2s0  FAILED
fe80::1 dev enp2s0 lladdr xx:xx:xx:8d:22:06 router STALE

＃ip -6ゲストの隣人：

fe80::1 dev enp2s0 lladdr xx:xx:xx:8d:22:06 router REACHABLE

おそらくホスト上の/etc/sysctl.confから関連するもの：

net.ipv4.ip_forward=1
net.ipv4.conf.enp2s0.send_redirects=0
net.ipv6.conf.all.forwarding=1

おそらくゲストの/etc/sysctl.confから関連するもの：

net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.all.autoconf=1
net.ipv6.conf.ens3.accept_ra=2
net.ipv6.conf.ens3.autoconf=1

おそらくゲストlibvirt-configの関連セクション：

<interface type='direct' trustGuestRxFilters='yes'>
  <mac address='xx:xx:xx:xx:xx:xx'/>
  <source dev='enp2s0' mode='bridge'/>
  <model type='e1000'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

私はこれに約2週間も苦労していて、同様の問題のあるほぼすべての関連する投稿を読んでいるので、Hetznerが何らかの魚のようなIPv6実装を行っているようです。私はすでに彼らに連絡しましたが、ルーティングの問題が私自身にあるのではないかと彼らは疑問に思いました。 20分後、ゲストに転送されていなくても、物理NICでエコー応答を受信して​​いるため、それは本当かもしれません。

では、仲間のIPv6愛好家からのアイデアはありますか？

更新：

そのためHetznerは私に、2a01：xxxx：xxxx：xxxx ::/64ネットワークが物理インターフェイスのリンクローカルアドレスにルーティングされていることを確認しました。ネットワークを再起動すると、NDPエントリは20分間留まりますが、VMは異なるリンクローカルアドレスで応答しないため、MACアドレスが異なるため、後で削除されます。

ここではmacvtap-interfacesを使用できないように見え始めていますが、そのためのブリッジを作成する必要があります。しかし、IPv4がまだ機能しているのに、なぜホストがIPv6でゲストを見ることができない（またはその逆も）のでしょうか。メインリンクローカルアドレスから直接トラフィックをルーティングできるようになると思います。

networkingdebiankvm-virtualizationipv6
4
Uitto

Hetznerサーバーでも同じ問題がありましたが、KVMの代わりにVirtualBoxを使用しています。

問題：

Hetznerは、/ 64サブネット内のターゲットIPを持つすべてのIPv6パケットを物理ホストのMACアドレスにルーティングします。つまり、インターネットのどこかからpingをホストに送信する場合、VM IPv6アドレスにホストと同じプレフィックスが付いている場合、ヘッツァーのゲートウェイは近隣を要請して、 VMのMACアドレスですが、代わりに単にホストのMACにICMPパケットを転送します。これが、VMではなく物理ホストでエコー応答を表示できる理由です。 VMのMACではなく、ホストのMACをターゲットにします。

ただし、HetznerのIPv6実装にはバグがあるようです（または意図的に行われているのかもしれませんが、わかりません）。VMがMACアドレスを検索するために近隣要請を送信する場合ゲートウェイの（fe80 :: 1）であり、要請の送信元アドレスとしてグローバルIPv6 IPを使用しているため、どういうわけかヘッツナーのゲートウェイは内部IPv6-to-MACアドレステーブルを更新しているようです。次の20分間、ヘッツナーのゲートウェイはVMのIPv6アドレスをターゲットとするパケットをVMのMACアドレスに送信します。20分以内にVMのMACとVMのグローバルIPからの要請がゲートウェイに送信されない場合、フォールバックしてホストのMACにIPv6パケットを送信します。

VM-ネットワーク起動直後、おそらくリンクローカルアドレスがこの時点で割り当てられていないためかもしれません-ONCEはグローバルIPv6アドレスをソースとして使用して要請を送信するため、「誤って」更新されますHetznerのMACアドレステーブルを1度使用します。実行中、VMは引き続き要請を送信してゲートウェイのMACアドレスを検索し、MACアドレステーブルを最新の状態に保ちますが、リンクローカルを使用します。そうするためのIPv6アドレス（IPv6の観点からは完全に問題ありません）でも、ヘッツナーのゲートウェイのMACアドレステーブルは更新されません。そのため、VM起動後にIPv6が完全に機能しているように見えますが、 20分間。

ソリューション：

ダーティソリューションとクリーンソリューションがあります。

  • 汚い解決策：あなたのVMは時々、グローバルIPv6アドレスを使用してゲートウェイのMACアドレスの要請を送信する必要があります（5分ごとに言う））これはトリッキーです：あなたのVMは要請を送信しますが、リンクローカルIPv6を使用します。そのため、ここでは安価なトリックを使用しました：リンクローカルIPをインターフェースから削除し、要請を送信します（グローバルIPの使用を強制されます）リンクローカルIPを再接続します。

    ip -6 addr del fe80::a00:27ff:fecf:e270/64 dev enp0s3
ndisc6 fe80::1 enp0s3
ip -6 addr add fe80::a00:27ff:fecf:e270/64 dev enp0s3

  • クリーンなソリューション：ブリッジを使用しないでください。現在、ホストオンリーネットワークを使用しています。つまり、VMは別のNIC（vboxnet0）に接続されています。ホストからVMのIPv6アドレスにすべてのトラフィックを転送するIPv6ルートを追加しました：

    ip -6 route add <my IPv6 pefix>::20 dev vboxnet0

VMでは、デフォルトのGWであるホストのリンクローカルIPv6アドレスを使用します。ホストがVM IPv6 IP、私は同じ/ 64サブネットから別のIPをvboxnet0に割り当てました。私にとっては、これは完全に機能します。

6
T. Jungblut