まず第一に、すべての再構成は対応する脳の状態で夜間に実行されたため、サービスの提供の中断が望ましくない、活発に使用されている生きた技術マシンですべてが発生したことに注意する必要があります;）
したがって、eth0をそのままにして（重要なプロダクションサービスが中断されないように）、すべてのエイリアスを削除し、br0ブリッジを作成し、それにeth0を挿入して、仮想マシンを起動します。
出来上がり-IPが表示され、車がお互いにpingを実行し、インターネットからホストのみが利用できることが判明したときにシャンパンを開く時間です。 問題の検索の複雑さを省略して、私はすぐにポイントに戻ります-サーバーがコロケーションにあったプロバイダーで、スイッチはポートセキュリティで構成されています、つまり MACのインストール時にのみ釘付けしてください。 プロバイダーは仮想マシンのポピーを許可しませんでしたが、私は彼を責めません。内部の技術ポリシーを確立するのは彼の権利です。 混乱した質問への回答：「何をすべきか？」答えは再びKVMプライマーからでした：インターフェースにエイリアスを残し、仮想マシンの10番目のグリッドを示し、「iptables -j DNAT bla-bla-bla」
このようなソリューションの不器用さを少し悲しみ、思慮深くGoogleを喫煙したため、キーワードproxy_arpの代替案が見つかりました。
まず最初に、
apt-get install uml-utilities
/etc/network/interfaces
ように記述します。
auto eth0
iface eth0 inet static
address 1.2.3.1
netmask 255.255.255.0
network 1.2.3.0
broadcast 1.2.3.255
gateway 1.2.3.254
post-up sysctl -w net.ipv4.ip_forward=1
post-up sysctl -w net.ipv4.conf.eth0.proxy_arp=1
pre-down sysctl -w net.ipv4.ip_forward=0
auto qtap1
iface qtap1 inet manual
tunctl_user root
uml_proxy_arp 1.2.3.2
uml_proxy_ether eth0
up ip link set qtap1 up
down ip link set qtap1 down
auto qtap2
iface qtap2 inet manual
tunctl_user root
uml_proxy_arp 1.2.3.3
uml_proxy_ether eth0
up ip link set qtap2 up
down ip link set qtap2 down
仮想マシンを起動します。
kvm -m 512 -hda image.img -net nic,macaddr=00:01:02:03:04:05 -net tap,ifname=qtap1,macaddr=00:01:02:03:04:05,script=no -daemonize -vnc :1
など
次に、仮想マシンでは、ホストアドレス1.2.3.1をgwとして指定し、プロバイダーからホストマシンのMACの背後でつまずいた仮想マシンの作業束を取得します。
まだネットワークの第一人者であると考えていない人のために、proxy_arpについてのいくつかの言葉と、それがbridgeとどのように異なるかについて。
デフォルトでは、通常のブリッジは単純に1つのインターフェイスから別のインターフェイスにパケットを変更せずに転送します。 パケットの送信方向を決定するために、パケットのハードウェアアドレスのみが考慮されます。 これは、Linuxがあらゆる種類のトラフィックを転送できることを意味します。パケットにハードウェアアドレスがあるかどうかわからないトラフィックも転送できます。
疑似ブリッジの動作は多少異なり、ブリッジよりも隠れたルーターのように見えますが、ブリッジのように、ネットワークアーキテクチャにある程度の影響があります。 確かに、これはまったくブリッジではありません。パケットは実際にコアを通過し、別のルートに沿ってフィルタリング、変更、リダイレクト、または方向付けできるためです。
疑似ブリッジのもう1つの利点は、「理解できない」プロトコルパケットを送信できないことです。これにより、ネットワークがあらゆる種類の「ゴミ」でいっぱいになるのを防ぎます。
このスキームでは、プロバイダースイッチがホストの背後にある仮想マシンとの接続を確立するときに、ホストにARP要求パケットを送信します。これは、人間の言語に翻訳され、次のように聞こえます。 1.2.3.254に報告してください。」 リクエストへの応答として、1.2.3.1は短いパケットで応答します。 私のハードウェアアドレスはxx：xx：xx：xx：xx：xxです。 "
1.2.3.254が応答を受信すると、ハードウェアアドレス1.2.3.2を記憶し、しばらくキャッシュに保存します。
proxy_arpを構成する際、eth0インターフェースにARP要求に応答するように指示しました。 これにより、ルーターが強制的にブリッジにパケットを送信し、ブリッジがパケットを処理して適切な仮想マシンに転送します。
したがって、ブリッジの片側のプロバイダールーターが反対側にあるコンピューターのハードウェアアドレスを要求するたびに、ブリッジは「すべてを通過させます」と言うように要求に応答し、その結果、すべてのトラフィックがeth0に送信され、望ましいvirtualka。
この記事の準備では、Linux Advanced Routing＆Traffic Control HOWTOの資料が使用されました。