Angeregt durch diesen Thread und mit dem Hintergedanken, dass mich genau dieses Problem vor einigen Wochen auch schon mal beschäftigt hat (erfolglos), versuch ich jetzt doch noch mal ne Lösung zu finden... vielleicht klappt das ja mit etwas Hilfe....
Ich habe meinem PC eine Bridge verpasst und dafür gesorgt, dass alles im gleichen Netzwerk abläuft. Die Idee war, die VM soll als regulärer LAN-Client mit eigener LAN-IP im Netz adressiert werden können. Mit dem macvtap-Device klappt das wie gewünscht, aber mit der Einschränkung, dass keine direkte Kommunikation zwischen Host und VM möglich ist. Jetzt hatte ich die Idee, das mit einer tun/tap-Bridge nachzubilden, ohne NAT... klappt aber nicht.
So sieht das im Überblick aus... und dann auch mit dem Nachweis, dass Ping-Pakete tatsächlich auch ankommen. Aber anscheinend verschwinden die TCP-Pakete in irgendein Loch, es gibt nämlich keinen Response.
Code: Alles auswählen
Netzwerk : 172.100.1/24
Default-GW : 172.100.1.1
PC (thomaspc) : 172.100.1.20
└─> Bridge : 172.100.1.200
└─> VM (virtpc) : 172.100.1.207
root@virtpc:~
# ping 172.100.1.1 -c 1 -w 1
PING 172.100.1.1 (172.100.1.1) 56(84) bytes of data.
--- 172.100.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# ping 172.100.1.20 -c 1 -w 1
PING 172.100.1.20 (172.100.1.20) 56(84) bytes of data.
--- 172.100.1.20 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# ping 172.100.1.200 -c 1 -w 1
PING 172.100.1.200 (172.100.1.200) 56(84) bytes of data.
--- 172.100.1.200 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
root@thomaspc:~
# ip r s
default via 172.100.1.1 dev enp2s0
172.100.1.0/24 dev enp2s0 proto kernel scope link src 172.100.1.20
172.100.1.0/24 dev br0 proto kernel scope link src 172.100.1.200
# tcpdump -n -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:14:05.071090 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28
16:14:06.086028 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28
16:14:07.110002 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28
16:14:13.464864 IP 172.100.1.207 > 172.100.1.20: ICMP echo request, id 901, seq 1, length 64
16:14:18.566080 ARP, Request who-has 172.100.1.20 tell 172.100.1.207, length 28
16:14:18.566107 ARP, Reply 172.100.1.20 is-at 52:54:00:9d:e9:4a, length 28
16:14:20.361278 IP 172.100.1.207 > 172.100.1.200: ICMP echo request, id 902, seq 1, length 64
16:14:25.478115 ARP, Request who-has 172.100.1.200 tell 172.100.1.207, length 28
16:14:25.478144 ARP, Reply 172.100.1.200 is-at 52:54:00:9d:e9:4a, length 28
# ping 172.100.1.207 -c 1 -w 1
PING 172.100.1.207 (172.100.1.207) 56(84) bytes of data.
--- 172.100.1.207 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms