blog/shl@INTERDOSE

Alt, aber hilft mit guter Laune durch jeden IOS Bug.

IPv4, IPv6

Ohne hier tiefer ins Detail gehen zu wollen:
wer auch so einen schicken Werbeanruf von der Telekom bekommt in dem VDSL angepriesen wird (spätestens bei “5MBit/s Upstream” hören wir doch alle zu)…

Ob man nun einen eingestaubten WRT, eine Cisco oder eine Apple Time Capsule stehen hat, der freundliche Telekom-Mitarbeiter wird höchstwahrscheinlich erklären, daß man dieses Gerät gegen ein Speedport 4711ASDF-whatever austauschen muß, damit VDSL nutzbar wird.

Zumindest erging es mir gestern Nachmittag so. Heute konnte ich allerdings die Finger nicht davon lassen, und habe mich in den Hotline-Jungle geworfen.
Das Ergebnis: natürlich gibt es reine VDSL-Modems, an deren jeder beliebige Router (oder sogar direkt ein PC) genutzt werden kann: das Speedport 221!

(Alternative Quelle)

Wenn ein Volume-Server an mehr als ein IP-Netz angebunden ist, bindet sich der OpenAFS Dienst an alle verfügbaren IP-Interfaces. Leider kann dies zu ungewollten und recht schlecht debugbaren Problemen in der VLDB führen.

# vos listaddrs
volserver01.standort1.example.com
192.168.0.1
volserver02.standort1.example.com
192.168.0.2
volserver01.standort2.example.com

Die Lösung bieten hier die zwei Dateien NetInfo und NetRestrict, unter Debian in /var/lib/openafs/local/ zu finden.

# cat /var/lib/openafs/local/NetInfo
1.2.3.4
# cat /var/lib/openafs/local/NetRestrict
192.168.0.1

Die Einträge in diesen beiden Dateien sagen in etwa folgendes:
Lieber vos, Du darfst Dich an die IP-Adresse 1.2.3.4 binden, aber lass’ die Finger weg von 192.168.0.1!

Mehrere IP-Adressen einfach in mehrere Zeilen schreiben, jeder nur ein Kreuz. Ob die Konfiguration funktioniert hat, sieht man nach einem Neustart z.B. mittels /etc/init.d/openafs-fileserver restart mit dem Befehl vos listaddrs.

# vos listaddrs
volserver01.standort1.example.com
volserver02.standort1.example.com
volserver01.standort2.example.com

Wer sich sein OpenAFS-Paket selbst gebaut hat, und/oder auf transarc-Pfade steht, der findet den richtigen Ort für die beiden Files in /usr/afs/local.

OpenAFS

Wiedermal hat mich Jakob auf die richtige Idee gebracht. ACLs innerhalb einer AFS-Zelle können auch IP-basiert genutzt werden.

Was bedeutet das nun:
Hier wird nicht der User bzw. Kerberos-Prinzipal mit ACLs versehen, sondern die Quell-IP des anfragenden Systems.

Anstatt

pts createuser JohnDoe
pts adduser JohnDoe Marketing
fs setacl $foo $bar $baz

wird für eine einzelne IP (z.B. einen dedizierten Server für einen Dienst, der sich nicht wirklich kerberisieren lässt)

pts creategroup HardToKerberize
pts createuser 172.23.42.666
pts adduser 172.23.42.666 HardToKerberize
fs setacl $foo $bar $baz

Um die Übersicht zu behalten bietet es sich an, neben exzessiver Dokumentation der eigenen Zelle (ja, das war ein Zaunpfahl), für IPs Gruppen zu erstellen, allein schon weil OpenAFS nicht mit der CIDR-Notation klar kommt.

Und bevor nun jemand ganze IP-Ranges von Hand eintippt:

1
2
3
4
5
6
7
8
9
10
11
12

#!/usr/bin/env python
# encoding: utf-8
 
def main():
  print "pts creategroup LAN-172.31"
  for i in range(0, 256):
    for j in range(0, 256):
      print "pts createuser 172.31." + str(i) + "." + str(j)
      print "pts adduser 172.31." + str(i) + "." + str(j) + " LAN-172.31"
 
if __name__ == '__main__':
	main()

Natürlich – wie immer – erst denken, dann anpassen, dann abtippen, dann ausführen.

OpenAFS, python

Problemstellung:
Ein recht umfangreiches Web-Projekt liegt auf einem einzelnen altersschwachen Server und soll auf die Web-Farm migriert werden. Der Umzug soll ohne nennenswerte Downtime erfolgen.

Hilfsmittel:

• IP Virtual Server als Load-Balancer
• iptables und böse Magie™
• einen Dominik (sehr praktisch, jeder sollte einen haben!)

Herangehensweise:
In drei Schritten soll der Umzug stattfinden.

Die Ausgangslage ist folgende:


Die DNS-Einträge zeigen alle auf den alten Host, sowohl Web- als auch Datenbank-Server laufen normal und der freundliche Mitarbeiter kopiert den Datenbestand auf die Web-Farm.
Sobald die Daten kopiert sind, kommt die böse Magie™ ins Spiel, und dem Load-Balancer wird mittels iptalbes und ein paar NAT-Regeln erklärt, daß IP “neu” (neue DNS-Einträge werden auf diese IP zeigen) auf IP “alt” (die IP des alten Servers) ge-NAT-tet werden soll.



Ab diesem Moment ist es möglich das Web-Projekt sowohl unter IP “neu” als auch unter IP “alt” anzusprechen – also Zeit den DNS zu ändern. Zur Sicherheit warten wir jetzt einige Stunden, so daß selbst in schlecht konfigurierten DNS-Caches keine Einträge auf IP “alt” mehr vorhanden sind. Gute Zeit für Feierabend, oder? Wir machen morgen weiter …

… gut geschlafen? Rann an’s Werk! Wir sind noch nicht fertig.
Der freundliche Mitarbeiter kommt wieder ins Spiel, schaltet das Web-Projekt auf read-only und migriert die letzten deltas an Daten. Sobald das geschehen ist, kommt der nächste Schritt:



In dem Moment in dem die iptables-Regel entfernt wird, wandern keine Pakete mehr von IP “neu” auf den alten Host, und alle Anfragen werden durch den Load-Balancer auf die Web-Farm verteilt.
Zeit der alten Maschine ihren Frieden zu lassen.

Wer von seiner preshared-key Infrastruktur weg möchte, dem sei gesagt: es geht auch viel schöner. Und wirklich so viel komplizierter ist dieser Weg auch nicht.

Leider sind gute Tutorials zu dieser Thematik recht selten, aber vielleicht hilft Euch ja das Folgende. Ich beziehe mich auf die aktuelle Version von OpenVPN aus Debian GNU/Linux. Das Prinzip ist allerdings bei jeder OpenVPN-Installation gleich.

Beginnen wir mit einem “leeren” Debian, und installieren als ersten Schritt die notwendigen Pakete.

apt-get update
apt-get install openvpn openssl

Debian wird den OpenVPN-Dienst direkt starten, welcher aber nicht wirklich weit kommen wird, daher beenden wir ihn per /etc/init.d/openvpn stop.

In /usr/share/doc/openvpn/examples/easy-rsa/2.0 finden wir die notwendigen Scripte um die Zerifikate für die Clients sowie den Server zu erstellen. Als erstes kopieren wir den Inhalt dieses Verzeichnises in /etc. (Wer noch kein Backup-System für /etc hat, dem sei etckeeper ans Herz gelegt – man sollte Backups machen. Wirklich.)

Die Datei vars enthält ein paar default Werte, die auf den persönlichen Geschmack geändert werden sollten, denn hier werden die Meta-Infos für die Zertifikate abgelegt. Sobald die Datei angepasst ist, den Inhalt “sourcen”.

. ./vars

Die zwei Punkte sind wichtig, kein Tippfehler. Da wir mit einer neuen Grund-Installation anfangen, übernimmt das Script clean-all etwas Aufräumarbeit für uns. Danach per

./build-ca

die Zertifizierungsstelle ins Leben rufen. Um bei vielen Zertifikaten nicht durcheinander zu kommen, empfiehlt es sich im Feld “common name” den FQDN des VPN-Servers oder ähnlich sinnvolle Inhalte anzugeben. Im nächsten Schritt erstellen wir das Server-Zertifikat, also das Zertifikat, welches später der OpenVPN-Dienst auf dem VPN-Server verwendet.

./build-key-server <Servername>

“common name” füllen wir wieder sinnvoll aus. Zeit den ersten Client-Schlüssel zu erstellen:

./build-key <Clientname>

Beim Client-Zertifikat soll sich bitte jeder selbst überlegen, ob ein “Challenge Password” Sinn ergibt oder nicht. Effektiv bedeutet das nichts anderes, als das der Benutzer ein Passwort eingeben muß um den Tunnel zu starten.

Als letzte Aktion vorerst, generieren wir noch die Diffie Hellman Parameter (nicht nachfragen – wer’s wirklich wissen will, Google hilft weiter.) und sind dann bereit für die OpenVPN-Config.

./build-dh

Im Unterverzeichnis keys finden sich nun die relavanten Dateien der Zertifkate, die wir an die richtige Stelle im Verzeichnisbaum kopieren.

cp ca.crt ca.key dh1024.pem <Servername>.crt <Servername>.key /etc/openvpn

Die Datei /etc/openvpn/openvpn.conf ist der nächste Schritt. Der Inhalt sollte in etwa so aussehen:

port 1194
proto tcp
dev tun
ca ca.crt
cert <Servername>.crt
key <Servername>.key
dh dh1024.pem
server 172.16.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status openvpn-status.log
verb 3
client-to-client

Wer verhindern möchte, daß die verbundenen Clients miteinander kommunizieren können, entfernt die letzte Zeile. Die Zeile server 172.16.0.0 255.255.255.0 enthält das Range an IP-Adressen, die den VPN-Clients ausgegeben werden (recht ähnlich zu DHCP). Hier bitte natürlich ein valides Subnetz eintragen.

Mit /etc/init.d/openvpn start starten wir den OpenVPN-Dienst, und ein beherztes ifconfig bzw. ip ad sh sollte uns ein tun0 Interface zeigen.

Nun zum Client.

Die OpenVPN-Config des Clients sollte in etwa diesen Inhalt haben:

client
dev tun
proto tcp
remote <Servername> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert <Clientname>.crt
key <Clientname>.key
comp-lzo
verb 3

Die Dateien ca.crt, <Clientname>.crt und <Clientname>.key müssen natürlich vorher vom Server auf den Client übertragen werden. Wenn der Client nun gestartet wird, sollte eine Verbindung zum VPN-Server aufgebaut werden. Falls nicht, Ruhe bewahren und Log-Dateien ansehen.

Was fehlt noch? Auf dem VPN-Server müssen wir noch IP-Routing aktivieren, um das VPN-Client Netz mit dem lokalen Netz zu verbinden. Auf Linux geht das recht simpel per:

echo 1 > /proc/sys/net/ipv4/ip_forward

Diese Zeile möchte man wohl in einem der init-Scripte oder im Firewall-Script verstecken, oder per post-up hook in der /etc/network/interfaces definieren.

Das war’s. Eigentlich einfach, oder? Soll ein weiteres Zertifikat für einen weiteren Client erstellt werden, einfach die Zeile ./build-key <Clientname> wiederholen. Es empfiehlt sich die Zertifikate nicht auf dem VPN-Server liegen zu lassen, also das ganze easy-rsa-Verzeichnis nach getaner Arbeit auf eine andere Maschine zu verschieben. Ebenfalls bitte regelmäßig Backups davon anfertigen.

Je nach Setup muß die Route in das VPN-Client Netz noch auf den anderen Maschinen gesetzt werden.

Auf Linux per route add -net 172.16.0.0/16 gw a.b.c.d und auf Windows per route -p add 172.16.0.0 mask 255.255.0.0 a.b.c.d.

Linux

Sehr häufig werde ich gefragt, wie Subnetze im IPv4-Netz sinnvoll und vor allem richtig berechnet werden. Lasst Euch gesagt sein, so schwer ist das gar nicht! Im Grunde genommen, muß man sich’s nur richtig vorstellen, ab da reichen ein paar Finger zum zählen und die guten alten Zweierpotenzen.
Und dank der Hilfe von ipcalc ist die Erklärung sogar sehr angenehm zu lesen.

Für den Anfang schauen wir uns zunächst die privaten IP-Bereiche, sogenannte RFC1918-Netze an:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Die RFC1918-Netz werden im Internet nicht geroutet, was bedeutet, daß hinter NAT-Gateways oder in rein internen Bereichen diese Netze ohne Genehmigung oder Ähnlichem genutzt werden dürfen. (Natürlich bitte trotzdem darauf achten, daß jede IP nur genau einmal im Netz vorkommen darf!)

Es gibt allerdings noch zwei Sonderfälle, die jedem Admin sehr häufig unterkommen werden:

• 127.0.0.0/8
• 169.254.0.0/16

Die folgenden Netze werde ich etwas ausführlicher erklären:

• 192.168.1.1/24
• 192.168.1.1/25
• 192.168.1.1/30
• 172.16.0.0/16
• 172.18.0.0/16
• 10.100.0.0/15
• 10.102.0.0/15
• 80.190.170.0/23
• 80.190.171.176/29

Sobald die Netze alle grob beschrieben sind, gibt’s noch ein paar allgemeine Hinweise.

10.0.0.0/8  [hoch]

Das größte private Subnetz ist 10.0.0.0/8. Wenn man sich die komplette Anzahl aller exitierenden IPs vorstellt, so ist ein /8 ein zweihundertsechsundfünfzigstel. Man stelle sich einen langen Strich als die gesammte Anzahl von existierenden IPs vor, und schneide ein zweihundertsechsundfünfzigstel davon ab. Das ist ein /8. /8-Netze wurden früher als Class-A bezeichnet, doch seit der Einführung von CIDR sollte man nicht mehr länger von Klassen sprechen.

172.16.0.0/12  [hoch]

Der nächste private IP-Block ist 172.16.0.0/12. Ebenfalls für die private Nutzung vorgesehen, umfasst dieser Block etwa eine Million IPs und enspricht damit einem sechtzehntel /8. Um die Klassen anzusprechen: ein /12 enthält insgesammt 16 Class-B Netze.
In den meisten Fällen werden aus 172.16.0.0/12 /16-Netze gemacht, in dem das komplette 172.16.0.0/12 in 16 Teile geschnitten wird (z.B. 172.16.0.0/16).

192.168.0.0/16  [hoch]

Der letzte private IP-Block ist 192.168.0.0/16 und entspricht damit einem zweihundertsechsundfünfzigstel /8. Der extrem lange Stich von eben, von dem wir ein zweihundertsechsundfünfzigstel abgebrochen haben? Dieses abgebrochene Teil brechen wir nochmals in 256 Teile. Jeder dieser Teile ist ein /16.
Ähnlich wie bei 172.16.0.0/12 geht man häufig dazu über den 192.168.0.0/16-Block in wieder 256 Teile zu brechen und /24 Netze aus dem 192.168.0.0/16-Bereich zu machen (z.B. 192.168.1.1/24).

127.0.0.0/8  [hoch]

Dies ist das sogenannte Loopback-Netz, was bedeutet, daß Pakete, die an eine der Adressen 127.X.X.X (X kann beliebig zwischen 0 und 255 gewählt werden) geschickt werden die Netzwerk-Hardware gar nicht verlassen, und das Betriebssystem automagisch auf sich selbst auflöst. Einfach mal versuchen, vielleicht funktioniert’s: http://127.0.0.1.

169.254.0.0/16  [hoch]

169.254.0.0/16 ist ein Spezialfall, bei dem sich der Admin – in den meisten Fällen – Gedanken machen sollte.

169.254.0.0/16 – This is the “link local” block. It is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.

Ansonsten aber: genug Ausnahmen, jetzt rann ans Werk!

192.168.1.1/24  [hoch]

Aus den meisten DSL-Routern und sonstiger Home-Hardware fallen IPs im Stile von 192.168.1.1/24 raus, was den 192.168.0.0/16-Block zu einem beliebten Ziel für Mißverständnisse und doppelten IPs macht. Wir betrachten hier ein /24, also den zweihundertsechsundfünfzigsten Teil eines /16, was der zweihundertsechsundfünfzigste Teil eines /8 ist, was wiederum der zweihundertsechsundfünfzigste Teil der gesammten Menge an IPs ist. Da fühlt man sich doch plötzlich klein, oder?

192.168.1.1/24 ist ein IP-Netz mit 256 IPs, doch auch hier – wie üblich – sind die erste und die letzte IP reserviert. Die erste IP in jedem IP-Netz ist die Netzwerk-IP, in diesem Beispiel die 192.168.1.0, und die letzte mögliche IP wird als Broadcast-IP bezeichnet – hier die 192.168.1.255. Diese beiden IPs dürfen unter gar keinen Umständen einer Maschine zugeordnet werden. Beide haben spezielle Aufgaben, auf die ich aber an dieser Stelle nicht eingehen möchte.
Innerhalb dieses /24 sind also alle IP-Adressen von 192.168.1.1 bis 192.168.1.254 nutzbar.

192.168.1.1/25  [hoch]

Es kann der Fall sein, daß 192.168.1.1/24 für das geplante Netz schlichtweg zu groß ist. Wenn nur etwa 100 IPs benötigt werden, kann die Größe des Netzes wunderbar angepasst werden. Bitte nochmals zum Messer greifen, und einen sauberen Schnitt in der Mitte des 192.168.1.1/24 anbringen. Wir haben nun zwei Netze mit jeweils einem halben /24, also einem /25 gewonnen. 192.168.1.1/25 und 192.168.1.128/25. Ein /25 enthält noch 128 IPs. Zieht man auch hier wieder Netzwerk-IP und Broadcast ab, bleiben 126 nutzbare IPs.
Im großen Zusammenhang ist als ein /25 die Hälfte des zweihundertsechsundfünfzigsten Teil eines /16, was der zweihundertsechsundfünfzigste Teil eines /8 ist, was wiederum der zweihundertsechsundfünfzigste Teil der gesammten Menge an IPs ist. Aber es geht noch kleiner!

192.168.1.1/30  [hoch]

Das Netz 192.168.1.1/30 ist schon wirklich sehr klein, denn es enthält noch genau 4 IPs. Solche Netze eignen sich wunderbar um genau zwei Geräte miteinander zu verbinden. Stichwort: Transfer-Netz. Genau zwei nutzbare IPs, also genau Platz für zwei Geräte. Ein /30 ist der vierundsechzigste Teil eines /24.

172.16.0.0/16  [hoch]

Die nächsten beiden werden wieder einfach, ich versprech’s. 172.16.0.0/16 ist ein /16, also einer der 256 Teile des /8 von oben. Der nutzbare Bereich dieses Netzes – ohne es weiter zu unterteilen – ist also 172.16.0.1 bis 172.16.255.254.

Wichtig ist hierbei zu verstehen, daß abgesehen von Netzwerk-IP (172.16.0.0) und Broadcast (172.16.255.255) jede andere IP nutzbar ist, also auch z.B. 172.16.13.0 oder 172.16.82.255. Hier liegt es im Sinne des Admins und seines ästhetischen Empfinden ob diese IPs genutzt werden oder nicht. Ich persönlich nutze sie nicht.

172.18.0.0/16  [hoch]

Wie eben schon 172.16.0.0/16 ist auch 172.18.0.0/16 an sich ein triviales Netz. Die Netzwerk-Maske ist identisch zu 172.16.0.0/16 und das Netz ist auch genauso groß. Nichts desto trotz ist es ein komplett eigenes Netz, und hat mit 172.16.0.0/16 nichts zu tun. Auch wenn beide Netze Teilstücke von 172.16.0.0/12 sind.

10.100.0.0/15  [hoch]

Alle Leser noch anwesend? Dann weiter. 10.100.0.0/15 ist kleiner als ein /8 jedoch größer als ein /16. Genau genommen doppelt so groß wie ein /16. Der nutzbare Bereich erstreckt sich also von 10.100.0.1 bis 10.101.255.254. Mit etwa 130000 nutzbaren IPs sollt dieses Netz groß genug sein um den DSL-Router, den kleinen iMac und die X-Box anzusprechen.
Man stelle sich nochmals den langen Strich vom /8 vor. Um /16-Netze zu erhalten, haben wir diesen Strich in 256 Teile zerschnitten. Fuer /15 zerschneiden wir ihn nur in 128 gleich große Teile.

10.102.0.0/15  [hoch]

10.100.0.0/15 war nicht schwer, also sollte 10.102.0.0/15 auch nicht schwer werden. Es ist nämlich einfach nur das nächste /15, also der nächste hundertachundzwanzigstel Fetzen des /8. Worauf ich hinaus will ist folgendes:
Wenn in einem Unternehmen 10.100.0.0/15 und 10.102.0.0/15 verwendet werden, und eines Tages den Admins die Anforderung eines einzelnen großen Netzes in der Inbox landet, ist das in diesem Falle sehr einfach, da beide Netze zu einem großen aggregiert (zusammengefasst) werden können. Beide /15 werden zu einem großen /14, nämlich zu 10.100.0.0/14, und das nur durch die Änderung der Netzwerk-Masken auf allen Teilnehmern des Netzes. Dieses /14 ist dann voll nutzbar, angefangen bei 10.100.0.1 bis schließlich 10.103.255.254. Das umfasst in etwa 260000 IPs.

80.190.170.0/23  [hoch]

Ein konkreteres Beispiel, denn alles was hier steht bezieht sich nicht nur auf RFC1918-Netze. 80.190.170.0/23 ist ein reelles Netz im Internet, zufälliger Weise der Firma Interdose zugeordnet. Es enthält insgesammt 512 IP-Adressen von denen – ohne weitere Aufteilung – 510 nutzbar sind. Der nutzbare Bereich ist also von 80.190.170.1 bis 80.190.171.254. Auch hier wieder sind 80.190.170.255 und 80.190.171.0 theoretisch nutzbar. 80.190.170.0/23 ist der hundertachtundzwanzigste Teil von 80.190.0.0/16.
Im nächsten Beispiel greifen wir ein Teil dieses Netzwerks noch weiter an.

80.190.171.176/29  [hoch]

Für den NoName e.V. haben wir ein /29 reserviert. Ein /29 enthält insgesammt 8 IPs von denen 6 nutzbar sind. Die IP-Adresse 80.190.171.179 ist eine der IPs aus diesem Netz, und damit ein Teil von 80.190.171.176/29.

Subnetze sollten jetzt keine unlösbare Herausforderung mehr sein. Doch in allen Beispielen gingen wir davon aus, dass immer in exakt gleich große Teile zerschnitten wird. Man kann aber z.B. aus einem /24 auch ein /25, ein /26 und zwei /27 machen. Beim Beispiel 10.102.0.0/15 sprach ich vom Aggregieren von Netzen, also dem Zusammenfassen kleinerer Netze zu einem großen.
Unterschiedlich große Teile erreicht man z.B. über den Umweg, daß erst das vorhandene Netz (bleiben wir beim /24) in die größe des kleinsten benötigten Netzes aufgeteilt wird – hier ein /28. Außerdem benötigen wir noch drei Netze der Größe /27 und ein /25. Das /24 zerteilen wir in 16 Teile, um das /28 zu erhalten. Zwei /28 ergeben ein /27, also können wir die drei /27 erstellen, in dem wir jeweils zwei /28 zusammenfassen – und das genau sechs mal. Ein /25 besteht aus zwei /26, also aus vier /27. Aus acht /28 können wir also das gewünschte /25 aggregieren. Von den 16 Teilen verbleibt also am Ende noch genau ein /28 übrig, der Rest ist zu den benötigten Netzen aggregiert worden. Eigentlich gar nicht so schwer, oder?

Dann bleibt ja nur noch die Frage der richtigen Netzwerk-Maske offen. Jedes Mal ipcalc anwerfen ist auch nicht die optimale Methode, aber hier kommen die Zweierpotenzen ins Spiel. Und das schönste: an dieser Stelle darf sogar wieder in den Klassen A, B und C gedacht werden.
Ein /8 hat die Netz-Maske 255.0.0.0, ein /16 bringt 255.255.0.0 mit sich und /24 entspricht 255.255.255.0. Sobald die Klassen-Netze weiter unterteilt werden, ändern sich natürlich die Stellen der Maske, an denen sich das Netz ändert. Was war aber von der IT anders zu erwarten? Es Ändert sich immer nach dem gleichen Muster. Die nachfolgende Tablelle zeigt den Werdegang der Maske an Hand des Weges von einem /24 zu einem /16:

Die Änderungen sind immer linear, was so viel bedeutet wie, daß sich beim Weg von einem /16 zu einem /8 die gleichen Änderungen ergeben, wenn auch eine Stelle weiter vorne in der Maske. Man brauch sich also eigentlich nur die folgenden Zahlen merken, und die Stelle der Maske. Ab da kann gezählt werden:

• 255
• 254
• 252
• 248
• 240
• 224
• 192
• 128
• 0

Oder die umgekehrte Reihenfolge, falls das Netz vekleinert werden soll:

• 0
• 128
• 192
• 224
• 240
• 248
• 252
• 254
• 255

War doch eigentlich gar nicht so schwer, oder?
Für Fragen und Anregungen bin ich natürlich immer offen. Ansonsten: viel Spaß mit den Netzen. Notfalls: ipcalc hilft!

IPv4