Dotaz: Striktní určení IP pro KVM hosta

[snajpa]

Dobrý den,
potřeboval bych vyřešit, jak KVM-Qemu hostovi přidělit IP adresu, a aby si nemohl sám vevnitř nastavit IP jak chce (resp mohl, ale aby mu nefungovaly jiné než povolené).
Napadlo mě použít routing, na straně hostitele by byly tapX, jenže ty tapX musí mít svoji IP. Problém je v tom, že se pohybují v subnetu veřejných IP a aby měl hostitel tolik IP, kolik virtuálů, je nesmysl. Ebtables? Co myslíte?

Odpovědi

[pht]

Nad bridgem normálně fungují iptables. Nebo nerozumím v čem je současný problém.

[snajpa]

No jo, ale mám možnost určit pár IP-virtuál? To si může každej virtuál vzít IP někoho jinýho, ne?

[trekker.dk]

Přece víš, s čím jsi ten virtuál startoval.

Můžeš udělat to, že pro každý virtuál bude síťovka tapX a ty se spojí do bridge společně s eth0. Na fyzickém stroji se tedy eth0 přepne do promiskuitního režimu a spojení do bridge už zajistí, že se pakety pro hosty dostanou tam, kam mají. Je potřeba s tím trochu polaborovat, občas mi přišlo, že záleží na pořadí nahození tap síťovky (ip l s tapX up) a vložení do bridge (brctl addif br0 tapX) a že chvilku trvá, než jádro přijde na to, co jsi tím nastavením vlastně myslel, ale pak už spojení funguje dobře.

A pak už jednoduchá pravidla do netfilteru, kdy z dané síťovky povolíš jenom jednu zdrojovu IP a ze všech ostatních drop.

[snajpa]

Díky moc.

[trekker.dk]

Jenom mě napadlo, jestli to filtrování nebude nějak ovlivněné tím, že síťovka je v bridge... (spojení virtuálů přes bridge s eth0 přímo do fyzické sítě vyzkoušené mám, ale filtrování provozu za takové podmínky už ne)

[snajpa]

Asi to udělám tak, že si vytvořím nějakej 192.168/24 subnet, v něm budu mít ty tapX, virtuály budou mít taky neveřejnou IP a pomocí natu přemapuju veřejný IP na vnitřní.

[trekker.dk]

Jo, to by vlastně taky šlo. Nepotřebuješ ani /24 rozsah, stačí používat rozsahy /30 s tím, že hostitel bude mít na tapX adresu .1 a host .2 (+4^X)

V tomhle případě už máš jisté, že filtrování bude fungovat a možná to bude i efektivnější co se výkonu týče.

[pht]

Proč je neroutovat rovnou (pokud to je 1:1) ?

[trekker.dk]

To by IMO bylo docela problematické, respektive vrací tě to do situace, kdy musíš dát všechny rozhraní do bridge - to není takový problém, ale jak jsem psal výše, nemám tušení, kdy se uplatňuje netfilter, tudíž je otázka, jestli by bylo možné filtrovat, ze kterého rozhraní může daná IP komunikovat.

[pht]

Netfilter se uplatňuje při vstupu a výstupu paketu, a je docela jedno jestli je to na bridge nebo jinde. Proč to komplikujete... je Vám líto že se fláká procesor a fungujou nativně všechny IP služby?

[pht]

PS jestli se bojíte bridge (ačkoliv v něm není problém) tak můžete ty reálné IP stejně routovat a to buď tak, že na routeru za Vámi se nastaví na ně routa přes Vás a nebo tak, že použijete proxyarp. Oboje je mnohem slušnější než NAT.

[2009]

ARP?