Mit qemu ins Netz [geht|geht nicht]

[GregorS]

Hallo allerseits!

Ich mache manche Dinge gerne mal in einer qemu-VM, die unter Slackware bestens läuft. Mit Debian 10.3 komme ich jedoch nicht mehr ins Internet. Da ich den Host der VM pingen kann, den DNS-Server jedoch nicht (beides im Netz 192.168.0.x), muss es wohl an Debian liegen. Nur, woran?! Und was kann ich tun, um auch unter Debian ins Internet kann?

in /etc/rc.local befindet sich jeweils:

Code: Alles auswählen

ip tuntap add mode tap; ifconfig -a tap0 192.168.1.1
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.1.1/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.1.0/24 -j MASQUERADE 

rc.local wird auch unter Debian ausgeführt. Ansonsten (unter Debian):

Code: Alles auswählen

root@mimi:/home/gszaktilla# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:e0:5c:00:3b:e7 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 40:16:7e:aa:e8:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.19/24 brd 192.168.0.255 scope global noprefixroute eno1
       valid_lft forever preferred_lft forever
    inet6 2a02:8071:b695:2900:5941:17a3:7138:769b/64 scope global temporary dynamic 
       valid_lft 164890sec preferred_lft 59541sec
    inet6 2a02:8071:b695:2900:4216:7eff:feaa:e859/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 164890sec preferred_lft 78490sec
    inet6 fe80::4216:7eff:feaa:e859/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:ac:b3:d4:15:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::f8ac:b3ff:fed4:1503/64 scope link 
       valid_lft forever preferred_lft forever
       
root@mimi:/home/gszaktilla# ip route show
default via 192.168.0.1 dev eno1 proto static metric 100 
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.19 metric 100 
192.168.1.0/24 dev tap0 proto kernel scope link src 192.168.1.1

Was tun?

TIA

Gregor

[TomL]

Das offensichtliche Problem liegt in Deinem Masquerading, weil Du dort ein Interface handhabst, was es gar nicht gibt. Das würde ich zunächst mal korrigieren.

[GregorS]

Das offensichtliche Problem liegt in Deinem Masquerading, weil Du dort ein Interface handhabst, was es gar nicht gibt. Das würde ich zunächst mal korrigieren.

Uh, tatsächlich. Ich habe immer nur auf die IP-Nummern gestarrt.

Wer kam eigentlich auf die Idee, die Namen der Schnittstellen zu ändern? Und warum? Und wann?

Gruß

Gregor

[MSfree]

Wer kam eigentlich auf die Idee, die Namen der Schnittstellen zu ändern? Und warum? Und wann?

https://www.freedesktop.org/wiki/Softwa ... faceNames/

Als Vorteile werdenaufgeführt:

1. Stable interface names across reboots
2. Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place (to the level the firmware permits this)
3. Stable interface names when kernels or drivers are updated/changed
4. Stable interface names even if you have to replace broken ethernet cards by new ones
5. The names are automatically determined without user configuration, they just work
6. The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
7. Fully stateless operation, changing the hardware configuration will not result in changes in /etc
8. Compatibility with read-only root
9. The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
10. Applicability to both x86 and non-x86 machines
11. The same on all distributions that adopted systemd/udev
12. It's easy to opt out of the scheme (see below)

Wobei 1-5 schon lange gewährleistet ist.
Punkt 6 nicht stimmt
Punkte 7-9 durchaus Vorteile haben kann, aber in den meisten Fällen nicht relevant ist.
Punkt 12 der wichtigste Punkt überhaupt ist, man kann es abschalten.