Hallo,
die Frage ist eigentlich ganz einfach und doch fällt es mir schwer, darüber vorab-Informationen zu finden (auch wegen vieler "falscher" Treffer).
Was ich machen will:
Recher A kommuniziert mit Rechner B über ein VPN (z.B. openvpn, tun oder tab Device)
Auf Rechner A läuft ein virtuelle Maschine A1 (und A2, A3, usw.)
A1 soll mit B (ausschließlich) durch den von A aufgebauten Tunnel kommunizieren. Es soll auch kein Byte an die physische Schnittstelle von Rechner A gehen, das unverschlüsselt ist.
A1 und A2 sollen ggf. auch über das virt. Netz *in* A miteinander schwatzen können.
Ok, meine Fragen sind:
1. Geht das und wie? (z.B. virt. Switch an tun Device, daran virt. Netzwerkkarte von A1 ggf. auch A2?)
2. Weiß jemand, wo die Kommandos (command line) für so eine Konfiguration brauchbar erklärt werden? Gibt's vielleicht sogar ein GUI zur Darstellung?
Danke, ixo
Netzerke und KVM
Message
Es sollten keine zwei Tap Devices sein.
Die Verschlüsselung (als das VPN) sollte nur in A laufen, nicht in A1.
A1 soll das VPN von A benutzen, und zwar ohne das etwas über das physische Interface von A (also z.B. eth0) geht oder anliegt.
In etwa so:
A1 -> virt. eth0 (A1) -> interne virt. Bridge (A) -> Tap(A) -> über eth0 (A) -> phys. Netzwerkkabel (A) -> ...
So ungefähr stelle ich mir das vor. Der Vorteil ist, dass die VMs nichts von der Verschlüsselung mitbekommen, die dann (für den physischen Rechner) zentral im native laufenden OS (identisch mit Hypervisor) läuft.
Ist das machbar oder geht das anders besser!?
Grüße, ixo
Die Verschlüsselung (als das VPN) sollte nur in A laufen, nicht in A1.
A1 soll das VPN von A benutzen, und zwar ohne das etwas über das physische Interface von A (also z.B. eth0) geht oder anliegt.
In etwa so:
A1 -> virt. eth0 (A1) -> interne virt. Bridge (A) -> Tap(A) -> über eth0 (A) -> phys. Netzwerkkabel (A) -> ...
So ungefähr stelle ich mir das vor. Der Vorteil ist, dass die VMs nichts von der Verschlüsselung mitbekommen, die dann (für den physischen Rechner) zentral im native laufenden OS (identisch mit Hypervisor) läuft.
Ist das machbar oder geht das anders besser!?
Grüße, ixo
Ok,
für mich war ein Tab Device etwas, was mit einem VPN zusammenhängt.
Wenn ich das jetzt richtig verstanden haben, handelt es sich um ein virtuelles Device, das für irgendetwas verwendet wird, also nicht nur für VPNs (das war der Denkfehler).
Allso das heißt, es geht. Sehr schön.
Kennst Du vielleicht zufällig noch eine gute Anleitung zur Erstellung von virtuellen Netzwerken (also mit Switch etc.)?
Danke, ixo
für mich war ein Tab Device etwas, was mit einem VPN zusammenhängt.
Wenn ich das jetzt richtig verstanden haben, handelt es sich um ein virtuelles Device, das für irgendetwas verwendet wird, also nicht nur für VPNs (das war der Denkfehler).
Allso das heißt, es geht. Sehr schön.
Kennst Du vielleicht zufällig noch eine gute Anleitung zur Erstellung von virtuellen Netzwerken (also mit Switch etc.)?
Danke, ixo
Hmm, also irgendwie klappt das nicht.
tun0 ist ein funktionierendes openvpn Device.
Das letzte Kommando klappt, wenn ich mit statt an tun0 z.B. an eth0 hänge.
Weiß jemand, was ich falsch mache?
Grüße, ixo
tun0 ist ein funktionierendes openvpn Device.
Code: Select all
# ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.19.1 netmask 255.255.255.255 destination 10.8.19.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# brctl addbr bri0
# brctl show
bridge name bridge id STP enabled interfaces
bri0 8000.000000000000 no
# brctl addif bri0 tun0
can't add tun0 to bridge bri0: Invalid argument
Weiß jemand, was ich falsch mache?
Grüße, ixo
Hallo,
ich bin jetzt etwas weiter - aber noch nicht ganz fertig (außer mit den Nerven
).
Für die virtuellen Switches habe ich jetzt openvswitch genommen (mit Kompatibilitätsunterstützung).
Nochmal zu Übersicht:
Alle Netzmasken sind 255.255.255.0
es gibt einen physischen Rechner mit ip Adresse br0=192.168.172.49 (per dhcp, ist aber egal)
auf dem laufen zwei virtuelle Maschinen (kvm): ovs1 und ovs2
ovs1 hat ip Adresse br0=192.168.172.100
ovs2 hat ip Adresse br0=192.168.172.110
auf ovs1 habe ich einen virtuellen Switch eingerichtet (internalBridge0) und auf diesen openvpn losgelassen.
/etc/openvpn/server.conf auf ovs1:
auf ovs2 haben ich einen openvpn Client eingerichtet.
/etc/openvpn/client-hq.conf auf ovs2:
ping etc. über die Bridge funktioniert von ovs1 (ping 192.168.192.11) oder osv2 (ping 192.168.192.10).
Die Switches auf ovs1 sehen so aus:
(Das vnet0 kommt von einer weiteren virtuellen Maschine, s.u.)
Auf ovs2 sehen die Switches so aus:
Sieht soweit ganz nett aus.
ABER:
Wie man an den Ausgaben von ifconfig sieht, hängt die ip Adresse des internen Netzes (192.168.192.x) an "internalBridge0". Das tap0 Interface hat keine.
Ich habe innerhalb von ovs1 eine weitere virtuelle Maschine (also virtuelle Maschine in virtueller Maschine
) ovs1-1 installiert und gestartet, welches ich an die interne Bridge "internalBridge0" gehängt habe. Von ovs1-1 konnte ich über die Bridge ovs2 (192.168.192.11) anpingen. Von ovs1-1 geht's auch über ovs1 (mit Routing) ins Internet (ovs1 ist als Router konfiguriert war (echo 1 > /proc/sys/net/ipv4/ip_forward)).
Das sieht also ganz gut aus.
Auf ovs2 sieht's schlechter aus. Da hängt die ip-Adresse vom tap0 Device (von openvpn dynamisch vergeben) und *nicht* an "internalBridge0". Wenn ich das umdrehe, funktioniert die Bridge nicht mehr.
Eine VM auf ovs2 lässt sich in der dargestellten Konfiguration (ip auf tap0) nur an "internalBridge0" hängen (wie bei ovs1), aber über das Interface in der VM ist dann keine Kommunikation möglich - nach meinem bescheidenen Verständnis, weil internalBridge0 keine ip Adresse hat.
Weiß jemand, wie man hier (also auf ovs2) eine interne VM (ovs2-1) netzwerktechnisch eingebunden bekommt, so dass sie ensprechend angebunden ist wie ovs1-2 (also an das gebridgte Netwerk)?
Viele Grüße und Danke,
ixo
ich bin jetzt etwas weiter - aber noch nicht ganz fertig (außer mit den Nerven
).Für die virtuellen Switches habe ich jetzt openvswitch genommen (mit Kompatibilitätsunterstützung).
Code: Select all
root@ovs1:~# service openvswitch-switch status
ovsdb-server is running with pid 1442
ovs-vswitchd is running with pid 1452
ovs-brcompatd is running with pid 1531
Alle Netzmasken sind 255.255.255.0
es gibt einen physischen Rechner mit ip Adresse br0=192.168.172.49 (per dhcp, ist aber egal)
auf dem laufen zwei virtuelle Maschinen (kvm): ovs1 und ovs2
ovs1 hat ip Adresse br0=192.168.172.100
ovs2 hat ip Adresse br0=192.168.172.110
auf ovs1 habe ich einen virtuellen Switch eingerichtet (internalBridge0) und auf diesen openvpn losgelassen.
/etc/openvpn/server.conf auf ovs1:
Code: Select all
port 1194
proto udp
server-bridge 192.168.192.10 255.255.255.0 192.168.192.11 192.168.192.19
dev tap0
ca ca.crt
cert server.crt
tun-mtu 1454
key server.key
dh dh1024.pem
up "/etc/openvpn/up.sh internalBridge0"
down "/etc/openvpn/down.sh internalBridge0"
ifconfig-pool-persist ipp.txt
keepalive 10 600
comp-lzo
persist-key
persist-tun
verb 3
mute 20
status openvpn-status.log
client-config-dir ccd
client-to-client
/etc/openvpn/client-hq.conf auf ovs2:
Code: Select all
client
dev tap
proto udp
remote 192.168.172.100 1194
tun-mtu 1454
nobind
persist-tun
ca ca.crt
cert ovs2.crt
key ovs2.key
comp-lzo
verb 3
mute 20
auth-nocache
Die Switches auf ovs1 sehen so aus:
Code: Select all
root@ovs1:~# ovs-vsctl show
8f424950-c1a6-4002-83cf-e006b5f3e94d
Bridge "internalBridge0"
Port "vnet0"
Interface "vnet0"
Port "ibr0"
Interface "ibr0"
Port "tap0"
Interface "tap0"
Port "internalBridge0"
Interface "internalBridge0"
type: internal
Bridge "br0"
Port "eth0"
Interface "eth0"
Port "br0"
Interface "br0"
type: internal
ovs_version: "1.4.0+build0"
Auf ovs2 sehen die Switches so aus:
Code: Select all
root@ovs2:~# ovs-vsctl show
5196df7a-a503-4955-81d1-e4cf68e2f16a
Bridge "internalBridge0"
Port "ibr0"
Interface "ibr0"
Port "internalBridge0"
Interface "internalBridge0"
type: internal
Port "vnet0"
Interface "vnet0"
Bridge "br0"
Port "br0"
Interface "br0"
type: internal
Port "eth0"
Interface "eth0"
ovs_version: "1.4.0+build0"
ABER:
Code: Select all
root@ovs1:~# ifconfig
br0 Link encap:Ethernet Hardware Adresse 46:09:f7:96:34:4f
inet Adresse:192.168.172.100 Bcast:192.168.172.255 Maske:255.255.255.0
inet6-Adresse: fe80::9c62:f2ff:fe4e:d6a/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:2427239 errors:0 dropped:0 overruns:0 frame:0
TX packets:3127303 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:13577766674 (13.5 GB) TX-Bytes:9412968668 (9.4 GB)
eth0 Link encap:Ethernet Hardware Adresse 52:54:00:2d:dc:c8
inet6-Adresse: fe80::5054:ff:fe2d:dcc8/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:2429679 errors:0 dropped:0 overruns:0 frame:0
TX packets:3128628 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:13608785562 (13.6 GB) TX-Bytes:9413087115 (9.4 GB)
internalBridge0 Link encap:Ethernet Hardware Adresse 52:a3:01:03:6c:44
inet Adresse:192.168.192.10 Bcast:192.168.192.255 Maske:255.255.255.0
inet6-Adresse: fe80::50a3:1ff:fe03:6c44/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1454 Metrik:1
RX packets:11711 errors:0 dropped:0 overruns:0 frame:0
TX packets:29372 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:1001907 (1.0 MB) TX-Bytes:387597418 (387.5 MB)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX packets:1424068 errors:0 dropped:0 overruns:0 frame:0
TX packets:1424068 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:961922199 (961.9 MB) TX-Bytes:961922199 (961.9 MB)
tap0 Link encap:Ethernet Hardware Adresse 7e:de:c8:c8:7c:fe
inet6-Adresse: fe80::7cde:c8ff:fec8:7cfe/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1454 Metrik:1
RX packets:91 errors:0 dropped:0 overruns:0 frame:0
TX packets:521 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX-Bytes:15806 (15.8 KB) TX-Bytes:112545 (112.5 KB)
vnet0 Link encap:Ethernet Hardware Adresse fe:54:00:3d:b2:30
inet6-Adresse: fe80::fc54:ff:fe3d:b230/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1454 Metrik:1
RX packets:7640 errors:0 dropped:0 overruns:0 frame:0
TX packets:20118 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX-Bytes:617312 (617.3 KB) TX-Bytes:265424296 (265.4 MB)
Code: Select all
root@ovs2:~# ifconfig
br0 Link encap:Ethernet Hardware Adresse ce:40:dd:64:0a:42
inet Adresse:192.168.172.110 Bcast:192.168.172.255 Maske:255.255.255.0
inet6-Adresse: fe80::cc40:ddff:fe64:a42/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:109055 errors:0 dropped:0 overruns:0 frame:0
TX packets:110900 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:181638425 (181.6 MB) TX-Bytes:167996535 (167.9 MB)
eth0 Link encap:Ethernet Hardware Adresse 52:54:00:26:6d:22
inet6-Adresse: fe80::5054:ff:fe26:6d22/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:109048 errors:0 dropped:0 overruns:0 frame:0
TX packets:110921 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:181637937 (181.6 MB) TX-Bytes:168001109 (168.0 MB)
internalBridge0 Link encap:Ethernet Hardware Adresse 4e:5c:29:4d:79:42
inet6-Adresse: fe80::4c5c:29ff:fe4d:7942/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:173 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:12474 (12.4 KB) TX-Bytes:14046 (14.0 KB)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX packets:197131 errors:0 dropped:0 overruns:0 frame:0
TX packets:197131 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:170398956 (170.3 MB) TX-Bytes:170398956 (170.3 MB)
tap0 Link encap:Ethernet Hardware Adresse ae:4f:75:a2:4d:e3
inet Adresse:192.168.192.11 Bcast:192.168.192.255 Maske:255.255.255.0
inet6-Adresse: fe80::ac4f:75ff:fea2:4de3/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1454 Metrik:1
RX packets:481 errors:0 dropped:0 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX-Bytes:105711 (105.7 KB) TX-Bytes:16058 (16.0 KB)
vnet0 Link encap:Ethernet Hardware Adresse fe:54:00:0b:06:17
inet6-Adresse: fe80::fc54:ff:fe0b:617/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:86 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX-Bytes:6516 (6.5 KB) TX-Bytes:4136 (4.1 KB)
Ich habe innerhalb von ovs1 eine weitere virtuelle Maschine (also virtuelle Maschine in virtueller Maschine
) ovs1-1 installiert und gestartet, welches ich an die interne Bridge "internalBridge0" gehängt habe. Von ovs1-1 konnte ich über die Bridge ovs2 (192.168.192.11) anpingen. Von ovs1-1 geht's auch über ovs1 (mit Routing) ins Internet (ovs1 ist als Router konfiguriert war (echo 1 > /proc/sys/net/ipv4/ip_forward)).Das sieht also ganz gut aus.
Auf ovs2 sieht's schlechter aus. Da hängt die ip-Adresse vom tap0 Device (von openvpn dynamisch vergeben) und *nicht* an "internalBridge0". Wenn ich das umdrehe, funktioniert die Bridge nicht mehr.
Eine VM auf ovs2 lässt sich in der dargestellten Konfiguration (ip auf tap0) nur an "internalBridge0" hängen (wie bei ovs1), aber über das Interface in der VM ist dann keine Kommunikation möglich - nach meinem bescheidenen Verständnis, weil internalBridge0 keine ip Adresse hat.
Weiß jemand, wie man hier (also auf ovs2) eine interne VM (ovs2-1) netzwerktechnisch eingebunden bekommt, so dass sie ensprechend angebunden ist wie ovs1-2 (also an das gebridgte Netwerk)?
Viele Grüße und Danke,
ixo