Dotaz: MAC maskarada virtualboxovej virtualky s bridgovanym interfacom

[victor8]

Zdravim vospolok,

riesim jeden problem s dost specifickymi poziadavkami na konektivitu virtualnej masiny beziacej na virtualboxe, ktora ma network interface zbrigdovany na eth0 interface na hoste. Velmi mi to nejde a napady dochadzaju, preto dufam, ze mie niekto bude schopny pomoct.

Na fyzickej masine (debian) mam nahodenu virtualku s bridgovanym interfacom na eth0 interface na hostovi.

Problemom je, ze switch overuje MAC adresy voci whitelistu a len vyvolene MAC adresy sa dostanu do spravnej VLANy, kde DHCP server vyslysi prosby o pridelenie IP adresy.

Dalsim obmedzenim je, ze na jeden port na switchi moze byt pripojena len jedna "whitelistovana" MAC adresa.

Vo fyzickom hoste mam sietovu kartu vyhradenu pre pouzitie virtualkami, jej MAC adresa je vo whiteliste a host ju nijako nepouziva.

root@host:~# ip a
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether b0:48:7a:81:15:58 brd ff:ff:ff:ff:ff:ff

relevantne nastavenia virtualnej masiny:

virtualbox@host:~$ VBoxManage showvminfo client
NIC 1:           MAC: 080027959BD1, Attachment: Bridged Interface 'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny

Potrebujem zabezpecit, aby vsetka prevadzka vychadzajuca z eth0 na hostovi mala ako source MAC adresu prave adresu fyzickej karty.

skusil som na hostovi nastavit toto:

PHYS_MAC="b0:48:7a:81:15:58"
VIRT_MAC="08:00:27:95:9B:D1"

ebtables -t nat -A POSTROUTING -o eth0 -j snat --to-src $PHYS_MAC --snat-arp --snat-target ACCEPT
ebtables -t nat -A PREROUTING -i eth0  -j dnat --to-dst $VIRT_MAC --dnat-target ACCEPT

avsak vysledok sa nedostavil, klient stale nedostava IP adresu od DHCP klienta

vypis z tcpdumpu (neviem nakolko je relevantny, nie som si isty v ktorom mieste odchytava pakety, ci pred, alebo az za postroutingom...

root@host:~# tcpdump -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
...
22:06:49.300151 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:95:9b:d1 (oui Unknown), length 300
22:06:49.300174 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:95:9b:d1 (oui Unknown), length 300
22:07:03.294648 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:95:9b:d1 (oui Unknown), length 300
22:07:03.294674 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 08:00:27:95:9b:d1 (oui Unknown), length 300
...
^C
136 packets captured
136 packets received by filter
0 packets dropped by kernel

Mate nejake napady ako tento problem vyriesit? Nemusim nutne pouzit MAC maskaradu, rozmyslal som nad nastavenim MAC adresy fyzickeho adaptera aj pre virtualny, no nie som si isty ako by sa bridge zachoval, keby na oboch jeho koncoch boli adaptery s rovnakou MAC adresou...

Vdaka za (akukolvek) pomoc.

---

---

Odpovědi

[NN]

No mohl by jsi ty MAC adresy proste otocit.. tu kterou potrebujes nakonfigurovat navrdo do virtualu, a na hostu vytvorit nejakou nahodnou..

[victor8]

Mě to připadá jako flikování. Možnosti jsou asi takové.

1. Domluvím se se správcem switche, aby na konkrétním interface pro mne povolil více MAC. Asi síťově nejčistší řešení.
2. Udělám to co píše NN. Na interface nastavím povolenou adresu do virtuálu a na reálného hostitele jakoukoli jinou.
3. Virtuál zanořím za NAT a potřebné porty napřímo forwardnu do virtuálu.

Nic jiného z podstaty síťových protokolů, udělat nejde. Bridge do virtuálu funguje tak, že hostitel převede kartu do promiskuitního modu a pakety se zpracovávají až v systému a také tímto způsobem odesílají.

[Michal Makovec]

přimlouvám se za možné řešení č. 1, správci sítě jsou také lidé, nevidím důvod proč by se nešlo domluvit...

[victor8]

Dakujem za reakciu.

Bohuzial moznost c.1 v uvahu nepripada, je to celofiremna politika, na jej zmenu nema dosah ani spravca siete.

moznost c.2 podla NN ale zabrala, ze ma to nenapadlo skor :)

nastavil som na hoste:

VBoxManage modifyvm aston-gw-test --macaddress1 b0:48:7a:81:15:58 && macchanger --mac=b0:48:7a:81:15:59 eth0

na prvu supu to neslo, tak som este fyzicku sietovku prepol do promisc modu

ip l s promisc on dev eth0

a voila :)

[Sten]

ebtables

[Sten]

ebtables -t nat -A PREROUTING -p ipv4 --ip-destination vi.r.tu.al -i eth0 -j dnat --to-destination 55:44:33:22:11:00
ebtables -t nat -A POSTROUTING -p ipv4 --ip-source vi.r.tu.al -o eth0 -j snat --snat-arp --to-source 00:11:22:33:44:55

[victor8]

take nieco som samozrejme skusal, vid otazka.

--ip-destination pouzit ale nemozem, ip nie je vzdy vopred znama, musim sa obmedzit na L2 vrstvu.

[Sten]

Aha, tam je DHCP. No s tím to nepůjde, to totiž identifikuje klienty právě pomocí MAC adres.