Le 29.05.2014 06:56, Igor Cicimov a écrit :
Maybe something like this?
- Kernel config
# sysctl -p
net.ipv4.conf.default.rp_filter = 1
net.ipv4.ip_forward = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
- Network interfaces config
# This is the host interface
auto eth0
allow hot-plug eth0
iface eth0 inet static
address 172.20.14.121
netmask 255.255.255.0
network 172.20.14.0
broadcast 192.168.0.255
gateway 172.20.14.1
dns-nameservers 172.20.14.1 8.8.8.8
search virtual.local
auto virbr1
iface virbr1 inet static
address 192.168.100.1
netmask 255.255.255.0
bridge_ports eth0
bridge_fd 0
bridge_stp off
bridge_maxwait 0
- Firewall simple config
# Set Default Policy to DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
# Allow loopback and localhost access
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -s 127.0.0.1/32 [6] -j ACCEPT
# Defense for SYN flood attacks
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT
# Set Default Connection States - accept all already established
connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Open DHCP and DNS for virbr1
iptables -A INPUT -p udp -m multiport --dports 67:68 -i virbr1 -m
state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 67:68 -i virbr1 -m
state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 53 -i virbr1 -m state --state NEW
-j ACCEPT
iptables -A INPUT -p tcp --dport 53 -i virbr1 -m state --state NEW -j
ACCEPT
# Masquerade
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.100.0/24 [7] ! -d
192.168.100.0/24 [8] -j MASQUERADE
# Forward chain
iptables -A FORWARD -i eth0 -o virbr1 -d 192.168.100.0/24 [9] -m
state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i virbr1 -o eth0 -s 192.168.100.0/24 [10] -j
ACCEPT
iptables -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
Now you can create VM's with their own virtual devices, ie vmdev0,
vmdev1 etc, and simply add those devices to the virbr1. Then
each of the VM's would have static config of their eth0 interface
with ip of 192.168.100.0/24 [11] range and 192.168.100.1 as default
gateway.
If you want to have the VM's get their ip via DHCP then you can
install dnsmasq and attach a process to virbr1. Something like
this:
/usr/sbin/dnsmasq -u dnsmasq --strict-order --bind-interfaces
--pid-file=/var/run/dnsmasq/virbr1.pid --conf-file=
--except-interface lo --listen-address 192.168.100.1
--dhcp-range 192.168.100.10,192.168.100.20
--dhcp-leasefile=/var/run/dnsmasq/virbr1.leases
--dhcp-lease-max=11 --dhcp-no-override
I will try this stuff to discover what it does and how it does it, but
the previous reply from Pascal Hamburg work like a charm.
Thanks a lot anyway for your time.
The purpose of the VLAN you have created is not clear as they are
usually used to extend a virtual network to more than one host. You
will need 802.1Q kernel module enabled and 802.1Q VLAN enabled
switch(s) in your network for this to work. Anyway, you can try
adding
the VLAN in the above configuration as an exercise, ie attach the
vlan
to eth0 and then include the vlan in the virbr1.
About the use of this network, the goal is to simulate the network
infrastructure of a client for which we work, but without polluting the
LAN we work on. I'll use it to deploy client's network twice ( on
different VLANs, obviously, to avoid conflicts ) : one for development
purposes, which won't be stable and probably will have to be
automatically rebuild regularly, and an other one for release candidates
of our work.
Since we do not do development tasks only for one client, it will
probably contain other other VLANs for other clients at a point.
Why I do this is because, currently... erm... I'm ashamed to say that,
especially on a public list, but truth is that we send development
versions a server, same for release candidate, and same for final
version. The problem being that the server is always the same. Ugly imo,
so I try to improve the situation, but I'm not a sysadmin, and I do not
have the control of our local LAN structure, but I can control the
VLAN's structures since they run on a server that my colleagues on admin
"gave" me.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/bb33943e56ef690b6a15d2c868e25...@neutralite.org
