On 2009-07-16_01:08:08, lee wrote: > On Wed, Jul 15, 2009 at 07:57:36PM +0700, Sthu Deus wrote: > > > Meaning that all packets come to and back from - only for/from the > > v-server. That the home machine will not be processing the packets. > > In a way, that isn't possible because there has to be at least one > physical network card which would be installed on the physical host. > > Logically, you need to give each OS that is running in a VM its own IP > address. You could also install a physical network card for each VM > and assign each VM its own card. >
I have no practical experience on VM, but it occurs to me that if one can implement a virtual host, one can also implement virtual lan cards, and a virtual '192.168.0.0-type' network entirely with the VM server. Then use net-address-translation of the several virtual hosts, and have one virtual host serve as the translator and actually manage the single real network card for communication that is 'outside of the box' ;-) I could not begin to advise you on how to actually DO this. I am just playing with ideas. I can well imagine that actually doing this is vastly more complicated than this quick note makes sound. Hope this is at least a little amusing as in idea... > With each VM having its own IP address, the host the VMs are running > on isn't (logically) the recipient or sender of network traffic going > to a VM. The traffic would go to the IP address of the VM, not to the > IP address of the host. > > I guess that's what you want --- but I don't know how secure that > is. It is also what you need to do in order for the VMs to have a > network connection. If they don't have each their own IP address, > there is no (good) way to decide which of the VMs is supposed to get > which network traffic. > > > > > *filter > > > Which firewall script are you using? There are some, like shorewall ... > > > > It is my hand made script. Is it wrong? > > Does it work? If it doesn't, it's probably wrong. > > You can make your own firewall script if you want to, but it's, hmm, > tricky. I sort of did that once, but I was starting with an example > script that was accompanied with documentation and adapted that to > what was needed. This script and documentation were for learning how > to set up a firewall, and that's how I learned it and how I got an > understanding of what the firewall does and how it works. > > But there are firewall scripts like shorewall and others that can make > it very simple to set up a firewall. > > > > The related packages are probably dropped, as you have set. But > > > without more detailed information, I can only guess. > > > > Which detailed info I should provide? > > Like all the IP addresses and network interfaces involved, what ports > and IPs are allowed to be used by which source IPs to which > destinations. > > Once you know that, you have done quite some of the work. If you write > it down, you can as well use the notation iptables uses, and when you > do that, you have most of your firewall. > > However, I see two ways to make it easy: > > > a.) If you run Linux in the VMs, use shorewall (or another script) on > each VM and set the firewall up as is needed for that VM. Then > you can use shorewall on the host itself and set it up there > as needed. > > b.) If you have another computer running Linux, you could use that as a > firewall for all the others. That's probably safer anyway. > > > In any case, if you have an internet connection via a router/firewall > you want to use with your VMs, you can be somewhat limited in what you > can do, depending on the capabilities of the router and the > capabilities of the software to deal with NAT. If you have a good > router, you can use that --- if you don't, connect the computer from > option b.) instead of the router. Then you might want to use > additional software to increase safety ... > > > > It's probably because input and output are being accepted instead of > > > dropped. > > > > That's right, but my question was, Why do I need to set ACCEPT for > > INPUT/OUTPUT > > chains while all I want is FORWARD? - Why FORWARD seems to not function with > > dropped INPUT/OUTPUT? > > Yeah, that is because there is nothing to forward when input and > output are dropped: You don't get to forward anything because the > traffic is dropped *before* you could forward it. > > Unfortunately, I don't remember exactly how it worked --- the script I > learned from created its own tables to drop all traffic and then to > allow only the traffic that it wanted to allow. Hmmm ... > > Yeah, I still have that: > > -rw-rw-r-- 1 lee lee 760879 2003-03-15 05:17 > /home/lee/infos/firewall/iptables-tutorial.html.tgz > > You might be able to find it when googling for it, but I can mail it > to you if you want to. It might be somewhat out of date, but I found > it very helpful and understandable. > > > > Don't you need to assign a network card --- or at least an IP address > > > --- to each of the different OSs you're running on the same computer > > > before you can apply firewall rules to them? > > > > So I have: for home OS I have ip x.x.0.2 while for the v-server - x.x.1.1 > > Yeah, each OS/VM needs its own IP. > > Are you sure that you can use x.x.0.x and x.x.1.x when there is only > one physical network card in the host? And is it a good idea to use > different network segments in this case? > > > I want that those v-servers have networking. > > Ok, did they have networking before you started setting up a firewall? > If not, that would be the first step. Once they have networking, you > can set up the firewalling. > > > > If you want to set up a firewall from scratch, one way of doing it is > > > to drop all network traffic and then to make rules which only allow > > > traffic for those combinations of IPs, ports and protocols you want to > > > allow traffic for. > > > > Does my script do the very same thing?! > > For instance, > > > > -A FORWARD -p tcp -m tcp -m --state ESTABLISHED,RELATED -j ACCEPT > > -A FORWARD -i eth0 -p tcp -m tcp -d 192.168.1.1 --dport 80 -j ACCEPT > > > > -A POSTROUTING -o eth0 -j SNAT --to-source=192.168.0.2 > > > > -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1:80 > > > > ? > > > > How I can do that not from scratch?! > > I'm not sure what this does, but I think you shouldn't use the -m > option that way. Afair you need to mark packets in some way before you > can check if they match (-m) something (i. e. if they match your mark) > ... You probably don't need matching at all. > > If you don't want to do it from scratch, check out shorewall. There > are other scripts making it easier to set up a firewall, but I don't > remember how they were called. > > But even if you use one of those scripts, I think it's a good idea to > take a look at the tutorial to get a basic understanding because that > will make it easier to use those scripts. If I hadn't learned from the > tutorial, I wouldn't have been able to understand the documentation of > shorewall and to set it up within half an hour or so. > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
