Adressierung und Routing mit ifconfig/route
IP-Aliase für IPv4
Ziel ist es, einer Netzwerkschnittstelle auf alte Art weitere IP-Adressen mitzugeben. Dazu werden IP-Aliase verwendet.
Auf Devuan-Linux oder einer anderen Debian-artigen Distribution mit installiertem Paket net-tools:
my@bash $ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.108 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 2003:f4:e717:ed0e:a00:27ff:fef3:630f prefixlen 64 scopeid 0x0<global>
inet6 2003:f4:e71f:86b2:a00:27ff:fef3:630f prefixlen 64 scopeid 0x0<global>
inet6 fe80::a00:27ff:fef3:630f prefixlen 64 scopeid 0x20<link>
ether 08:00:27:f3:63:0f txqueuelen 1000 (Ethernet)
RX packets 23438 bytes 7921672 (7.5 MiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 15291 bytes 1560590 (1.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.2.2.1 netmask 255.255.255.0 broadcast 10.2.2.255
inet6 fe80::a00:27ff:feb6:495 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:b6:04:95 txqueuelen 1000 (Ethernet)
RX packets 154 bytes 17315 (16.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 86 bytes 12888 (12.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 35 bytes 6020 (5.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35 bytes 6020 (5.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
my@bash $ ## >> Dank '-a' sind hierbai auch deaktivierte NICs zu sehen.
Zwei weitere Adressen für eth0 setzen, wobei ‚ifconfig‘ die Sub-Devices namens „subdev0“ und „subdev1“ erzeugt, die dieselbe MAC-Adresse benutzen (ein Doppenpunkt trennt den eigentlichen Schnittstellennamen vom Aliasnamen):
my@bash $ ifconfig eth0:subdev0 10.3.3.3 netmask 255.255.255.0 up
my@bash $ # >> ====
my@bash $ # >> Dieses 'up' passiert per Default und kann weggelassen werden.
my@bash $
my@bash $ # Alternativ in CIDR-Schreibweise: ifconfig eth0:0 10.3.3.3/24
my@bash $
my@bash $
my@bash $ ifconfig eth0:subdev1 10.4.4.4 netmask 255.255.255.0 up
my@bash $
my@bash $ ifconfig | grep eth0 -A1
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.108 netmask 255.255.255.0 broadcast 192.168.2.255
--
eth0:subdev0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.3.3.3 netmask 255.255.255.0 broadcast 10.3.3.255
--
eth0:subdev1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.4.4.4 netmask 255.255.255.0 broadcast 10.4.4.255
my@bash $
Neuere Kernel betrachten dies einfach nur als weitere Adressen für eth0, wie es ja für IPv6 zwingend erforderlich geworden ist, mehrere Adressen auf einer Schnittstelle zu haben. Entsprechend stellen es auch die neuen iproute-Tools dar (Debians Paket nennt sich iproute2):
my@bash $ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:f3:63:0f brd ff:ff:ff:ff:ff:ff
inet 192.168.2.108/24 brd 192.168.2.255 scope global dynamic eth0
valid_lft 1800641sec preferred_lft 1800641sec
inet 10.3.3.3/24 brd 10.3.3.255 scope global eth0:subdev0
valid_lft forever preferred_lft forever
inet 10.4.4.4/24 brd 10.4.4.255 scope global eth0:subdev1
valid_lft forever preferred_lft forever
inet6 2003:f4:e71f:86b2:a00:27ff:fef3:630f/64 scope global dynamic mngtmpaddr
valid_lft 14375sec preferred_lft 1775sec
inet6 2003:f4:e717:ed0e:a00:27ff:fef3:630f/64 scope global dynamic mngtmpaddr
valid_lft 13042sec preferred_lft 442sec
inet6 fe80::a00:27ff:fef3:630f/64 scope link
valid_lft forever preferred_lft forever
my@bash $
Mit den alten net-tools sprechen wir das Sub-Device so an:
my@bash $ ifconfig eth0:subdev0
eth0:subdev0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.3.3.3 netmask 255.255.255.0 broadcast 10.3.3.255
ether 08:00:27:f3:63:0f txqueuelen 1000 (Ethernet)
my@bash $
my@bash $ ## ifconfig eth0:subdev0 10.3.3.3 netmask 255.255.255.0 up
my@bash $ ##
Versuchen wir nun den Nachbarn via IP-Alias zu erreichen:
my@bash $ ping -c2 10.3.3.3
PING 10.3.3.3 (10.3.3.3) 56(84) Bytes Daten.
Von 62.155.247.115 icmp_seq=1 Zielnetz nicht erreichbar
Von 62.155.247.115 icmp_seq=2 Zielnetz nicht erreichbar
--- 10.3.3.3 ping statistics ---
2 Pakete übertragen, 0 empfangen, +2 Fehler, 100% Paketverlust, Zeit 1001ms
my@bash $
Das geht natürlich noch nicht. Es soll auch hier auf Ubuntu einen IP-Alias zum Einsatz kommen. Ausgangspunkt ist diese Situation:
my@bash $ ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.234 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 2003:f4:e71f:86b2:a00:27ff:fe5a:81a1 prefixlen 64 scopeid 0x0<global>
inet6 2003:f4:e717:ed0e:a00:27ff:fe5a:81a1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::a00:27ff:fe5a:81a1 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:5a:81:a1 txqueuelen 1000 (Ethernet)
RX packets 831661 bytes 360872653 (360.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 30468 bytes 2435688 (2.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.5.1 netmask 255.255.255.0 broadcast 192.168.5.255
inet6 fe80::a00:27ff:fe05:fb59 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:05:fb:59 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 144 bytes 14593 (14.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 665 bytes 59370 (59.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 665 bytes 59370 (59.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
my@bash $
Wir erzeugen nun den IPv4-Alias, wobei diesmal einfach „0“ als Aliasname für das Sub-Device verwendet wird:
my@bash $ ifconfig enp0s3:0 10.3.3.4/24
my@bash $
my@bash $ ping -c2 10.3.3.3
PING 10.3.3.3 (10.3.3.3) 56(84) Bytes Daten.
64 Bytes von 10.3.3.3: icmp_seq=1 ttl=64 Zeit=1.99 ms
64 Bytes von 10.3.3.3: icmp_seq=2 ttl=64 Zeit=0.373 ms
--- 10.3.3.3 ping statistics ---
2 Pakete übertragen, 2 empfangen, 0% Paketverlust, Zeit 1001ms
rtt min/avg/max/mdev = 0.373/1.183/1.993/0.810 ms
my@bash $
my@bash $ ## Zur Erfolgskontrolle den ARP-Cache ausgeben:
my@bash $ arp -a
_gateway (192.168.2.1) auf 9c:80:df:90:bb:c0 [ether] auf enp0s3
? (10.3.3.3) auf 08:00:27:f3:63:0f [ether] auf enp0s3
artix-wks (192.168.2.201) auf 08:00:27:d1:7f:d9 [ether] auf enp0s3
? (192.168.2.108) auf 08:00:27:f3:63:0f [ether] auf enp0s3
my@bash $
Während ein Dauerping läuft, deaktivieren wir auf der anderen Seite die Karte:
my@bash $ ping 10.3.3.3
PING 10.3.3.3 (10.3.3.3) 56(84) Bytes Daten.
64 Bytes von 10.3.3.3: icmp_seq=1 ttl=64 Zeit=0.413 ms
64 Bytes von 10.3.3.3: icmp_seq=2 ttl=64 Zeit=0.252 ms
64 Bytes von 10.3.3.3: icmp_seq=4 ttl=64 Zeit=0.265 ms
64 Bytes von 10.3.3.3: icmp_seq=5 ttl=64 Zeit=0.285 ms
my@bash $ ## Auf der anderen Seite:
my@bash $ ifconfig eth0:subdev0 down
my@bash $
Von 10.3.3.4 icmp_seq=74 Zielhost nicht erreichbar
Von 10.3.3.4 icmp_seq=75 Zielhost nicht erreichbar
Von 10.3.3.4 icmp_seq=76 Zielhost nicht erreichbar
my@bash $ ## Auf der anderen Seite die Adresse wieder setzen:
my@bash $ ifconfig eth0:subdev0 10.3.3.3/24
my@bash $
Von 10.3.3.4 icmp_seq=77 Zielhost nicht erreichbar
64 Bytes von 10.3.3.3: icmp_seq=78 ttl=64 Zeit=1033 ms
64 Bytes von 10.3.3.3: icmp_seq=79 ttl=64 Zeit=0.151 ms
64 Bytes von 10.3.3.3: icmp_seq=80 ttl=64 Zeit=0.270 ms
64 Bytes von 10.3.3.3: icmp_seq=81 ttl=64 Zeit=0.367 ms
^C
--- 10.3.3.3 ping statistics ---
86 Pakete übertragen, 34 empfangen, +31 Fehler, 60,4651% Paketverlust, Zeit 99024ms
rtt min/avg/max/mdev = 0.151/30.737/1033.412/174.543 ms, pipe 4
my@bash $
my@bash $ ping 10.3.3.4
PING 10.3.3.4 (10.3.3.4) 56(84) bytes of data.
64 bytes from 10.3.3.4: icmp_seq=1 ttl=64 time=0.577 ms
64 bytes from 10.3.3.4: icmp_seq=2 ttl=64 time=0.377 ms
64 bytes from 10.3.3.4: icmp_seq=3 ttl=64 time=0.318 ms
64 bytes from 10.3.3.4: icmp_seq=8 ttl=64 time=0.336 ms
64 bytes from 10.3.3.4: icmp_seq=9 ttl=64 time=0.529 ms
64 bytes from 10.3.3.4: icmp_seq=10 ttl=64 time=0.328 ms
^C
--- 10.3.3.4 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 207ms
rtt min/avg/max/mdev = 0.318/0.423/0.577/0.097 ms
my@bash $
Klarer Fall: Wird die Karte deaktiviert, stoppt der Ping, nach dem Neusetzen der Adresse läuft er wieder los.
Nun wollen wir aber die Konfiguration ein wenig ändern, so dass wir dann gezwungen sind, Routing-Regeln zu schreiben. Nach dem Ändern der Adresse auf 10.3.255.3 (unter Weglassung der Netzwerkmaske!), haben wir unsere Karte in ein Class-A Netzwerk platziert:
my@bash $ ifconfig eth0:subdev0 10.3.255.3
my@bash $
my@bash $
my@bash $ ifconfig eth0:subdev0
eth0:subdev0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.3.255.3 netmask 255.0.0.0 broadcast 10.255.255.255
ether 08:00:27:f3:63:0f txqueuelen 1000 (Ethernet)
my@bash $ # >> Dezimalmaske von 255.0.0.0 = Class A
my@bash $
my@bash $
my@bash $ ## Auf Ubuntu kommt es dabei aber zu folg. Fehler:
64 Bytes von 10.3.3.3: icmp_seq=135 ttl=64 Zeit=0.421 ms
Von 10.3.255.3 icmp_seq=136 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=137 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=138 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=139 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=140 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=141 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=140 Zielhost nicht erreichbar
Von 10.3.255.3 icmp_seq=141 Zielhost nicht erreichbar
Von 10.3.255.3 icmp_seq=145 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=143 Zielhost nicht erreichbar
Von 10.3.255.3 icmp_seq=149 Host umleiten(New nexthop: 3.3.3.10)
Von 10.3.255.3 icmp_seq=147 Zielhost nicht erreichbar
Von 10.3.255.3 icmp_seq=150 Zielhost nicht erreichbar
my@bash $ ## Die Ursache ist einfach: Netzwerkmasken-Mischmasch!
my@bash $
my@bash $ ifconfig enp0s3:0
enp0s3:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.3.3.4 netmask 255.255.255.0 broadcast 10.3.3.255
ether 08:00:27:5a:81:a1 txqueuelen 1000 (Ethernet)
my@bash $
my@bash $ ## >> Ubuntu sieht nur 256 Adressen: 255.255.255.0
my@bash $
my@bash $
my@bash $ ## Rein rechnerisch muss Ubuntu davon ausgehen, dass es sich um ein
my@bash $ # anderes Netz handelt:
my@bash $ ping -c3 10.3.3.3
PING 10.3.3.3 (10.3.3.3) 56(84) Bytes Daten.
Von 10.3.3.4 icmp_seq=1 Zielhost nicht erreichbar
Von 10.3.3.4 icmp_seq=2 Zielhost nicht erreichbar
Von 10.3.3.4 icmp_seq=3 Zielhost nicht erreichbar
--- 10.3.3.3 ping statistics ---
3 Pakete übertragen, 0 empfangen, +3 Fehler, 100% Paketverlust, Zeit 2026ms
pipe 3
my@bash $
my@bash $ ping -c3 10.3.255.3
PING 10.3.255.3 (10.3.255.3) 56(84) Bytes Daten.
Von 62.155.247.115 icmp_seq=1 Zielnetz nicht erreichbar
Von 62.155.247.115 icmp_seq=2 Zielnetz nicht erreichbar
Von 62.155.247.115 icmp_seq=3 Zielnetz nicht erreichbar
--- 10.3.255.3 ping statistics ---
3 Pakete übertragen, 0 empfangen, +3 Fehler, 100% Paketverlust, Zeit 2003ms
my@bash $
my@bash $ ## Und das ist die neue Adresse von Anderen (Devuan):
my@bash $ ping -c3 10.3.255.3
PING 10.3.255.3 (10.3.255.3) 56(84) Bytes Daten.
Von 62.155.247.115 icmp_seq=1 Zielnetz nicht erreichbar
Von 62.155.247.115 icmp_seq=2 Zielnetz nicht erreichbar
Von 62.155.247.115 icmp_seq=3 Zielnetz nicht erreichbar
--- 10.3.255.3 ping statistics ---
3 Pakete übertragen, 0 empfangen, +3 Fehler, 100% Paketverlust, Zeit 2003ms
my@bash $
my@bash $
my@bash $
my@bash $ ## Auf der linken Seite (Devuan), wo sich aus Sicht des
my@bash $ ## Rechners das große Class-A-Netz befindet:
my@bash $ ping 10.3.3.4
PING 10.3.3.4 (10.3.3.4) 56(84) bytes of data.
# es dauert und dauert...
my@bash $
my@bash $ ## Auf Ubuntu zurückgekehrt:
my@bash $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp0s3
10.3.3.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
192.168.5.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s8
my@bash $
my@bash $ route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.3.3.4
my@bash $ ## ========
my@bash $ ## Sonderfall: Ich bin mein eigenes Gatweway (ist ja kein Router dazwischen)
my@bash $
my@bash $ ip route
default via 192.168.2.1 dev enp0s3 proto static metric 100
10.0.0.0/8 via 10.3.3.4 dev enp0s3 scope link
10.3.3.0/24 dev enp0s3 proto kernel scope link src 10.3.3.4
169.254.0.0/16 dev enp0s3 scope link metric 1000
192.168.2.0/24 dev enp0s3 proto kernel scope link src 192.168.2.234 metric 100
192.168.5.0/24 dev enp0s8 proto kernel scope link src 192.168.5.1 metric 101
my@bash $
my@bash $
64 bytes from 10.3.3.4: icmp_seq=4 ttl=64 time=0.316 ms
64 bytes from 10.3.3.4: icmp_seq=5 ttl=64 time=0.277 ms
64 bytes from 10.3.3.4: icmp_seq=6 ttl=64 time=0.328 ms
^C
--- 10.3.3.4 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 108ms
rtt min/avg/max/mdev = 0.277/0.387/0.657/0.126 ms
my@bash $
my@bash $ ## >> Linkerhand (Devuan) läuft der Ping nun, weil Ubuntu nun weiß, wohin die Anwortpakete
my@bash $ ## zurückgesendet werden sollen.
my@bash $
my@bash $ ## Zur Verdeutlichung der Problematik:
my@bash $ ## DEVUAN im Netz 1:
my@bash $ ## ifconfig eth0:subdev0 10.3.255.3
my@bash $ ip route | grep -F 10.3.255.3
10.0.0.0/8 dev eth0 proto kernel scope link src 10.3.255.3
my@bash $
my@bash $
my@bash $
my@bash $
my@bash $ ## UBUNTU im Netz 2:
my@bash $ ## ifconfig enp0s3:0 10.3.3.4/24
my@bash $ ip route | grep -F 10.3.3.4
10.0.0.0/8 via 10.3.3.4 dev enp0s3 scope link
10.3.3.0/24 dev enp0s3 proto kernel scope link src 10.3.3.4
my@bash $
my@bash $ # >> Zeile 1: Unsere eben gesetzt GateWay-Route
my@bash $
my@bash $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp0s3
10.0.0.0 10.3.3.4 255.0.0.0 UG 0 0 0 enp0s3
10.3.3.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
192.168.5.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s8
my@bash $
my@bash $ # >> Hier ist in Zeile 2 diese GW-Route zu sehen.
my@bash $
my@bash $
my@bash $
my@bash $ ## UBUNTU: Diese Route wieder löschen:
my@bash $ route del -net 10.0.0.0 netmask 255.0.0.0
my@bash $
my@bash $ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 enp0s3
10.3.3.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
192.168.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
192.168.5.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s8
my@bash $
my@bash $
my@bash $ ## DEVUAN: Eine zu Ubuntu IP-Adressierung passende Adresse setzen:
my@bash $ ifconfig eth0:subdev0 10.3.3.254 netmask 255.255.255.0
my@bash $
my@bash $ ping -c3 10.3.3.4
PING 10.3.3.4 (10.3.3.4) 56(84) bytes of data.
64 bytes from 10.3.3.4: icmp_seq=1 ttl=64 time=0.700 ms
64 bytes from 10.3.3.4: icmp_seq=2 ttl=64 time=0.465 ms
64 bytes from 10.3.3.4: icmp_seq=3 ttl=64 time=0.279 ms
--- 10.3.3.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 32ms
rtt min/avg/max/mdev = 0.279/0.481/0.700/0.173 ms
my@bash $
my@bash $
my@bash $
my@bash $ ## UBUNTU:
my@bash $ arp -an
? (10.3.255.3) auf 08:00:27:f3:63:0f [ether] auf enp0s3
? (192.168.2.1) auf 9c:80:df:90:bb:c0 [ether] auf enp0s3
? (10.3.3.3) auf <unvollständig> auf enp0s3
? (10.3.3.254) auf 08:00:27:f3:63:0f [ether] auf enp0s3
? (192.168.2.201) auf 08:00:27:d1:7f:d9 [ether] auf enp0s3
? (192.168.2.108) auf 08:00:27:f3:63:0f [ether] auf enp0s3
my@bash $
my@bash $ ## >> Devuans neue Adresse 10.3.3.254
my@bash $ ## ist aufgetaucht.
my@bash $
my@bash $
my@bash $ ## Dies war das Setzen und Löschen eine Netzroute mit GW:
my@bash $ # route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.3.3.4
my@bash $ # route del -net 10.0.0.0 netmask 255.0.0.0
Fazit: Immer auf die Netzwerkmasken achten, was besonders bei ‚ifconfig‘ für Verwirrung sorgen kann!