TCP/IP – Grundlagen

Was ist TCP/IP?

TCP/IP ist kein einzelnes Protokoll, sondern eine ganze Protokollfamilie – das Fundament, auf dem jede moderne Netzwerkkommunikation aufbaut. Egal ob du eine E-Mail versendest, eine Website aufrufst oder via Teams telefonierst: Im Hintergrund läuft immer TCP/IP.

Die zwei wichtigsten Mitglieder dieser Familie:

• IP (Internet Protocol) – kümmert sich um die Adressierung und das Routing von Datenpaketen. Jedes Paket bekommt eine Absender- und Zieladresse.
• TCP (Transmission Control Protocol) – stellt eine zuverlässige, verbindungsorientierte Verbindung sicher. Pakete kommen an, werden bestätigt und bei Verlust neu gesendet.

Daneben gibt es noch UDP (User Datagram Protocol): schneller als TCP, aber ohne Bestätigung. Wird für VoIP, Videocalls oder DNS genutzt – wo Geschwindigkeit wichtiger ist als absolute Zuverlässigkeit.

Das TCP/IP-Schichtenmodell

TCP/IP wird oft als 4-Schichten-Modell dargestellt. Als Vergleich siehst du daneben das bekanntere 7-Schichten-OSI-Modell – das OSI-Modell dient vor allem als Referenzrahmen für Troubleshooting (Layer 1 bis 7 von unten nach oben prüfen).

Im Alltag hilft das Modell, Probleme einzugrenzen: Wenn ping funktioniert (Schicht 3), aber ein Dienst nicht erreichbar ist, liegt das Problem auf Schicht 4 (Port/Firewall) oder höher.

IPv4-Adressen verstehen

Eine IPv4-Adresse besteht aus 32 Bits, dargestellt als vier Dezimalzahlen von 0 bis 255, getrennt durch Punkte – zum Beispiel 192.168.1.42.

Jede Adresse teilt sich auf in:

• Netzwerkteil – welches Netzwerk (bestimmt durch die Subnetzmaske)
• Hostteil – welcher Rechner innerhalb dieses Netzwerks

Private vs. öffentliche Adressen

Für interne Netzwerke sind drei Adressbereiche reserviert – diese Adressen werden niemals im Internet geroutet:

Subnetzmaske und CIDR-Notation

Die Subnetzmaske teilt eine IP-Adresse in Netzwerk- und Hostteil auf. Sie wird entweder als Dezimalzahl (255.255.255.0) oder in CIDR-Notation (/24) angegeben.

Die CIDR-Zahl gibt an, wie viele Bits von links für den Netzwerkteil reserviert sind.

Wie viele Hosts passen rein? Formel: 2^(32 - CIDR) - 2. Das Minus 2 kommt daher, dass die erste Adresse die Netzwerkadresse und die letzte die Broadcast-Adresse ist.

Beispiel: /24 → 2^8 - 2 = 254 nutzbare Hosts.

Beispiel aus dem Alltag

Dein KMU nutzt 192.168.10.0/24:

• Netzwerkadresse: 192.168.10.0
• Erste nutzbare IP: 192.168.10.1 (oft der Router/Gateway)
• Letzte nutzbare IP: 192.168.10.254
• Broadcast: 192.168.10.255
• Subnetzmaske: 255.255.255.0

VLSM – Subnetze in der Praxis aufteilen

Im echten Betrieb hast du selten das Glück, dass alle Abteilungen gleich viele Hosts brauchen. Genau dafür gibt es VLSM (Variable Length Subnet Mask): Ein grösseres Netz wird in ungleich grosse Subnetze mit jeweils passender Maske aufgeteilt, statt starr überall dieselbe CIDR zu verwenden. Das spart Adressraum und ist Standard-Praxis bei jeder Segmentierung (siehe auch VLAN-Grundlagen für die Layer-2-Seite davon).

Krumme Host-Zahlen berechnen

Die Frage lautet meistens: “Ich brauche X nutzbare Hosts – welche Maske brauche ich?” Faustregel: nimm die nächsthöhere Zweierpotenz und ziehe 2 ab (Netz- und Broadcast-Adresse).

Rechenweg für 20 Hosts: 2^5 - 2 = 30 nutzbare Adressen ≥ 20 → 5 Host-Bits reichen, also /27 (32 - 5 = 27).

Ein /24 in ungleiche Subnetze aufteilen

Beispiel: 192.168.10.0/24 soll auf drei Standorte verteilt werden – Hauptsitz (100 Hosts), Filiale A (50 Hosts), Filiale B (20 Hosts). Vorgehen: immer mit dem grössten Bedarf beginnen, damit die Blöcke sauber ausgerichtet bleiben.

1. Hauptsitz, 100 Hosts → braucht /25 (126 nutzbar) → 192.168.10.0/25 (Bereich .0–.127)
2. Filiale A, 50 Hosts → braucht /26 (62 nutzbar) → nächster freier Block ab .128 → 192.168.10.128/26 (Bereich .128–.191)
3. Filiale B, 20 Hosts → braucht /27 (30 nutzbar) → nächster freier Block ab .192 → 192.168.10.192/27 (Bereich .192–.223)
4. Rest – 192.168.10.224/27 bleibt für spätere Erweiterung frei (30 Adressen Reserve)

Standard-Gateway und Routing

Das Standard-Gateway ist die IP-Adresse des Routers in deinem Netzwerk. Wenn dein PC ein Paket an eine IP ausserhalb des eigenen Subnetzes schicken will, leitet er es zuerst an den Router weiter – dieser weiss, wohin das Paket als nächstes muss.

Ohne korrektes Gateway: Du kannst andere PCs im selben Netzwerk erreichen, aber keine externen Ressourcen (Internet, andere Standorte).

Typische Gateway-Adressen in KMU:

• 192.168.0.1 oder 192.168.1.1 (Consumer-Router)
• 192.168.x.254 (oft bei Managed Switches/Firewalls)
• 10.0.0.1 (grosse Netzwerke)

Statisches Routing vertieft: Routentabelle, Metric und manuelle Routen

Jeder Windows-Rechner (und jeder Router) führt eine eigene Routentabelle: eine Liste von Zielnetzen mit dazugehörigem Gateway, Interface und Metric. Das Standard-Gateway ist dabei nur ein Sonderfall – die Route für “alles andere” (0.0.0.0/0). Für vertiefte Routing-Konzepte (dynamisches Routing, OSPF/BGP-Grundlagen) siehe Routing-Grundlagen.

Die Routentabelle anzeigen

route print

Zeigt die komplette IPv4- und IPv6-Routentabelle: Netzwerkziel, Netzmaske, Gateway, Schnittstelle und Metric. Wichtig für Support-Fälle mit mehreren Netzwerkkarten (z.B. LAN + VPN-Adapter gleichzeitig aktiv) – hier entscheidet die Metric, welcher Weg genommen wird.

Get-NetRoute
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

PowerShell-Äquivalent, besser filter- und skriptbar. Zeigt zusätzlich ifMetric und RouteMetric getrennt – die effektive Priorität ist die Summe aus beiden.

Metric verstehen

Die Metric ist ein Kostenwert: Je niedriger, desto bevorzugter wird eine Route genutzt, wenn mehrere passende Routen existieren. Windows berechnet automatisch eine Metric basierend auf der Interface-Geschwindigkeit, du kannst sie aber manuell überschreiben – zum Beispiel um dem VPN-Adapter bewusst eine schlechtere Metric zu geben, damit lokaler Traffic nicht versehentlich durch den Tunnel läuft (“Split Tunneling”, siehe VPN-Grundlagen).

Route hinzufügen und löschen

route add 172.16.0.0 mask 255.255.0.0 192.168.1.254 metric 5

Fügt eine Route zum Netz 172.16.0.0/16 über das Gateway 192.168.1.254 hinzu. Ohne Zusatz gilt sie nur bis zum nächsten Neustart.

route -p add 172.16.0.0 mask 255.255.0.0 192.168.1.254 metric 5

Mit -p (persistent) bleibt die Route auch nach einem Neustart erhalten – Windows speichert sie in der Registry unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes.

route delete 172.16.0.0

Entfernt die Route wieder.

New-NetRoute -DestinationPrefix "172.16.0.0/16" -InterfaceAlias "Ethernet" -NextHop 192.168.1.254 -RouteMetric 5
Remove-NetRoute -DestinationPrefix "172.16.0.0/16" -Confirm:$false

PowerShell-Varianten von route add/route delete – New-NetRoute ist standardmässig persistent, ein Neustart löscht die Route also nicht automatisch wieder.

NAT im Detail: SNAT, DNAT und Port-Forwarding

NAT (Network Address Translation) übersetzt private IP-Adressen in öffentliche und zurück – ohne NAT hätte jedes private Gerät (siehe RFC-1918-Bereiche oben) keinen Weg ins Internet, weil diese Adressen dort nicht geroutet werden.

SNAT – Source NAT (der Normalfall)

SNAT ersetzt die Absender-IP eines Pakets, das von innen nach aussen geht. Der klassische Router-Fall heisst genauer PAT (Port Address Translation) oder “NAT Overload”: Alle internen Clients teilen sich eine öffentliche IP, unterschieden werden sie über den Quellport.

Intern:  192.168.1.50:51230  →  Router  →  Extern: 203.0.113.9:61230
Intern:  192.168.1.51:51230  →  Router  →  Extern: 203.0.113.9:61231

Der Router merkt sich in einer NAT-Tabelle, welcher interne Client/Port zu welchem übersetzten Port gehört, und übersetzt die Antwort beim Rückweg wieder zurück.

DNAT – Destination NAT und Port-Forwarding

DNAT übersetzt die Zieladresse eines eingehenden Pakets – der Anwendungsfall ist praktisch immer Port-Forwarding: Ein Dienst im internen Netz soll von aussen erreichbar sein, ohne eine öffentliche IP direkt auf dem Server zu haben.

Beispiel: Ein interner RDP-Server (192.168.1.20:3389) soll von aussen über einen ungewöhnlichen Port erreichbar sein (nie Port 3389 direkt ins Internet öffnen – siehe RDP-Grundlagen und Firewall-Grundlagen):

Extern:  203.0.113.9:33890  →  DNAT  →  Intern: 192.168.1.20:3389

Auf einer klassischen SOHO-Firewall/Router-Oberfläche heisst das meist “Port Forwarding” oder “Virtual Server”: externer Port, interne IP, interner Port, Protokoll (TCP/UDP) angeben.

NAT-Traversal bei VPN und VoIP

NAT bricht das Grundprinzip von Ende-zu-Ende-Konnektivität – das wird bei zwei Diensten besonders spürbar:

• VPN: IPsec nutzt ursprünglich Protokolle (ESP, Protokoll 50), die kein Portkonzept haben und durch PAT-NAT nicht sauber durchgeleitet werden. Die Lösung heisst NAT-T (NAT Traversal, RFC 3947): ESP-Pakete werden in UDP-Port 4500 gekapselt, sobald eine NAT-Gerät auf dem Pfad erkannt wird. Mehr dazu in VPN-Grundlagen.
• VoIP/SIP: Bei SIP-Telefonie steht die Ziel-IP für den Medienstrom (RTP) oft im SIP-Signalisierungspaket selbst – nach NAT stimmt diese IP nicht mehr mit der tatsächlichen Absender-IP überein (“SIP-ALG-Problem”). Lösungen sind STUN (Client ermittelt seine öffentliche NAT-Adresse selbst) oder TURN (Relay-Server, wenn direkte Verbindung nicht möglich ist) – siehe Tabelle oben (Port 3478–3481) und VoIP-Grundlagen.

Wichtige Ports kennen

Ports sind wie Türnummern an einer IP-Adresse. Eine IP-Adresse führt zum richtigen Gerät, der Port zum richtigen Dienst. Ports unter 1024 sind bekannte “Well-Known Ports”.

TCP-Internals: Handshake, Window Scaling, TIME_WAIT

Für den Alltag reicht “TCP ist zuverlässig”. Für tiefere Fehlersuche – etwa mit Wireshark – lohnt sich der Blick unter die Haube.

Der 3-Way-Handshake

Bevor Daten fliessen, bauen zwei Hosts eine TCP-Verbindung mit drei Paketen auf:

Client  → SYN               →  Server
Client  ← SYN, ACK           ←  Server
Client  → ACK                →  Server

1. SYN – Client schlägt eine Sequenznummer vor (“ich fange bei X an zu zählen”)
2. SYN, ACK – Server bestätigt X+1 und schlägt seine eigene Startsequenz Y vor
3. ACK – Client bestätigt Y+1, die Verbindung steht

Erst danach beginnt der eigentliche Datenaustausch. Bricht der Handshake ab (Client sendet SYN, bekommt aber nie ein SYN/ACK zurück), landet die Verbindung in SYN_SENT – klassisches Zeichen für eine Firewall, die das Paket stillschweigend verwirft, statt es sauber mit RST abzulehnen.

Window Scaling

Das TCP-Fenster (Window Size) legt fest, wie viele Bytes ein Sender verschicken darf, bevor er auf eine Bestätigung warten muss. Das ursprüngliche TCP-Header-Feld ist nur 16 Bit breit – maximal 65’535 Byte. Auf schnellen Verbindungen mit hoher Latenz (z.B. Standortanbindungen über Satellit oder interkontinentale Leitungen) bremst das massiv aus, weil der Sender ständig auf ein ACK warten muss, statt durchzuschreiben.

Window Scaling (RFC 1323) löst das: Beim Handshake handeln beide Seiten einen Skalierungsfaktor aus, der das effektive Fenster auf bis zu 1 GB vergrössert. Moderne Windows- und Linux-Systeme aktivieren das automatisch. Sichtbar wird das Problem meist erst, wenn ein Firewall/Router in der Mitte die Window-Scaling-Option beim NAT fälschlicherweise entfernt (“Window Scaling gebrochen”) – Symptom: Durchsatz bricht bei grossen Transfers auf einen Bruchteil der Leitungsgeschwindigkeit ein, obwohl ping unauffällig ist.

Verbindungsabbau und TIME_WAIT

Der Abbau einer TCP-Verbindung läuft über einen Vier-Wege-Abschied (FIN/ACK von beiden Seiten). Die Seite, die den Abbau zuerst aktiv einleitet, geht danach in den Zustand TIME_WAIT – sichtbar in netstat -ano. Windows hält eine Verbindung standardmässig für 2×MSL (Maximum Segment Lifetime), also rund 4 Minuten, in diesem Zustand, bevor der Port wieder freigegeben wird.

Grund: Verspätete Pakete der alten Verbindung könnten noch unterwegs sein – TIME_WAIT verhindert, dass sie fälschlicherweise einer neuen Verbindung auf demselben Port zugeordnet werden.

MTU, Fragmentierung und Path MTU Discovery

Die MTU (Maximum Transmission Unit) ist die grösste Paketgrösse, die ein Netzwerksegment ohne Aufteilung transportieren kann. Ethernet-Standard ist 1500 Byte; bei VPN-Tunneln, PPPoE oder VLAN-Tags mit zusätzlichen Headern ist auf dem Tunnel-Interface effektiv weniger Platz.

Fragmentierung

Ist ein Paket grösser als die MTU des nächsten Hops, wird es bei IPv4 fragmentiert – in mehrere kleinere Pakete aufgeteilt, die der Empfänger wieder zusammensetzt. Das kostet Performance und ist bei IPv6 komplett abgeschafft: Router fragmentieren dort nicht mehr, der Sender muss selbst die richtige Grösse kennen.

Path MTU Discovery (PMTUD)

Damit ein Sender die kleinste MTU entlang des gesamten Pfads kennt, ohne sie zu erraten, gibt es PMTUD: Pakete werden mit gesetztem DF-Bit (Don’t Fragment) verschickt. Kann ein Router unterwegs das Paket wegen zu geringer MTU nicht durchreichen, verwirft er es und schickt ein ICMP-”Fragmentation Needed”-Paket (Typ 3, Code 4) mit der zulässigen Grösse zurück an den Sender. Der Sender passt darauf seine Paketgrösse an.

ping -f -l 1472 8.8.8.8

Testet mit gesetztem DF-Bit (-f) und einer Nutzlast von 1472 Byte (+28 Byte IP/ICMP-Header = 1500 Byte gesamt). Meldet Windows “Paket muss fragmentiert werden, DF gesetzt”, ist die effektive MTU auf dem Pfad kleiner als angenommen – nützlich, um die MTU eines VPN-Tunnels systematisch einzugrenzen (Wert schrittweise reduzieren, bis der Ping durchgeht).

Der Blackhole bei Tunneln

Ein häufiges, schwer zu diagnostizierendes Problem: PMTU-Blackhole. Viele Firewalls blockieren ICMP pauschal aus Sicherheitsgründen – damit kommt die “Fragmentation Needed”-Nachricht nie beim Sender an. Ergebnis: kleine Pakete (DNS-Anfragen, Ping) funktionieren einwandfrei, aber sobald eine Anwendung grössere Pakete schickt (z.B. eine vollständige HTTPS-Seite oder ein RDP-Login über VPN), hängt die Verbindung einfach – ohne Fehlermeldung, ohne Timeout-Meldung, einfach still.

Typisches Symptom bei VPN-Tunneln: SSH- oder RDP-Verbindung baut auf, aber sobald grössere Daten fliessen (z.B. Dateiliste laden, Terminal-Ausgabe), friert die Sitzung ein.

Abhilfe in der Praxis:

• MSS-Clamping auf dem Tunnel-Endpunkt aktivieren: reduziert automatisch die maximale TCP-Segmentgrösse (MSS) auf allen Paketen, die durch den Tunnel gehen, sodass sie inklusive Tunnel-Overhead nie über die tatsächliche MTU hinauswachsen
• MTU auf dem VPN-Interface manuell reduzieren (z.B. auf 1400 statt 1500 bei IPsec/OpenVPN)
• ICMP Typ 3 (Destination Unreachable) an Firewalls gezielt durchlassen, statt ICMP komplett zu blocken

Netzwerk-Diagnose: Die wichtigsten Befehle

Windows-Konfiguration prüfen

ipconfig

Zeigt IP-Adresse, Subnetzmaske und Gateway aller Netzwerkadapter. Schnell für den ersten Überblick.

ipconfig /all

Detaillierte Ausgabe: zusätzlich MAC-Adresse, DHCP-Status, DNS-Server, DHCP-Server, Lease-Zeiten. Das ist der erste Befehl bei fast jedem Netzwerkproblem.

Get-NetIPConfiguration

PowerShell-Äquivalent – übersichtlicher und skriptfreundlicher.

Erreichbarkeit testen

ping 8.8.8.8
ping google.com

Sendet ICMP-Pakete und misst die Antwortzeit. Funktioniert ping 8.8.8.8, aber nicht ping google.com, liegt ein DNS-Problem vor, kein Konnektivitätsproblem.

ping -t 192.168.1.1

Dauerhafter Ping (bis Ctrl+C). Nützlich um intermittierende Verbindungsabbrüche zu erkennen.

Test-NetConnection -ComputerName google.com -Port 443

Testet sowohl Ping als auch ob ein bestimmter TCP-Port erreichbar ist. Unverzichtbar zum Prüfen von Firewall-Regeln.

Route verfolgen

tracert 8.8.8.8

Zeigt alle Router (Hops) auf dem Weg zum Ziel. Jeder Hop ist ein Router. Wo die Antworten aufhören, liegt das Problem. Sternchen (* * *) bedeuten: dieser Router antwortet nicht auf ICMP.

pathping 8.8.8.8

Kombiniert ping und tracert: misst Paketverlust pro Hop. Dauert länger (ca. 3 Minuten), liefert dafür detailliertere Informationen.

ARP-Tabelle und MAC-Adressen

arp -a

Zeigt die ARP-Tabelle: welche IP-Adresse zu welcher MAC-Adresse gehört (im lokalen Netzwerk). Nützlich um zu prüfen, ob ein Gerät überhaupt im Netzwerk kommuniziert hat.

Offene Verbindungen und Ports

netstat -ano

Zeigt alle aktiven TCP/UDP-Verbindungen mit Prozess-ID (PID). Nützlich um zu sehen, welcher Prozess auf welchem Port lauscht.

Get-NetTCPConnection | Where-Object State -eq 'Listen' | Sort-Object LocalPort

PowerShell-Variante: zeigt alle lauschenden TCP-Ports, sortiert nach Portnummer.

Schritt-für-Schritt: Netzwerkproblem eingrenzen

Wenn ein User meldet “Ich komme nicht ins Internet”, geh systematisch vor:

1. Kabel/WLAN prüfen – Ist die Verbindung physisch hergestellt? LED am Switch-Port? WLAN verbunden?

2. IP-Konfiguration prüfen

   ipconfig /all

   Hat der PC eine gültige IP (kein 169.254.x.x)? Gateway und DNS eingetragen?

3. Gateway anpingen

   ping 192.168.1.1

   Antwortet der Router? Falls nein: lokales Netzwerkproblem (Switch, VLAN, Kabel).

4. Internet-IP anpingen

   ping 8.8.8.8

   Antwortet ein externer Server? Falls nein: Internet-Verbindung oder Routing-Problem beim Router/Firewall.

5. DNS testen

   ping google.com
   nslookup google.com

   Wird der Hostname aufgelöst? Falls nein: DNS-Problem (falscher DNS-Server, DNS-Server nicht erreichbar).

6. Port-Erreichbarkeit prüfen

   Test-NetConnection -ComputerName google.com -Port 443

   Falls DNS geht, aber HTTPS nicht: Firewall-Regel oder Proxy-Problem.

IPv6 vertieft: SLAAC, DHCPv6, Präfix-Delegation, Dual-Stack

IPv6 ist der Nachfolger von IPv4 und nutzt 128-Bit-Adressen (statt 32 Bit), dargestellt als acht Gruppen von je vier Hexadezimalziffern: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

Im KMU-Alltag begegnest du IPv6 hauptsächlich bei:

• Link-Local-Adressen (fe80::/10) – werden automatisch jedem Interface zugewiesen, gelten nur im lokalen Segment
• Dual-Stack – PC hat gleichzeitig IPv4 und IPv6-Adresse
• Tunnel-Protokollen – IPv6 über IPv4-Infrastruktur

Für die meisten KMU-Netzwerke reicht IPv4 noch aus. Trotzdem: wenn ipconfig /all eine fe80::-Adresse zeigt, ist das normal und kein Fehler.

SLAAC vs. DHCPv6 – wer vergibt die Adresse?

Anders als bei IPv4 (fast immer DHCP) gibt es bei IPv6 zwei grundsätzlich verschiedene Wege, wie ein Client seine Adresse bekommt:

Gesteuert wird das über zwei Flags im Router Advertisement:

• M-Flag (Managed) = 1 → Client soll die Adresse per stateful DHCPv6 holen
• O-Flag (Other Configuration) = 1 → Client soll zusätzliche Optionen (z.B. DNS) per DHCPv6 holen, Adresse aber via SLAAC

Für den Support relevant: Windows-Clients zeigen bei reinem SLAAC oft temporäre Adressen (Privacy Extensions, RFC 4941) zusätzlich zur SLAAC-Adresse an – in ipconfig /all erscheinen dann mehrere IPv6-Adressen pro Interface, das ist normal.

Präfix-Delegation (DHCPv6-PD)

In grösseren oder mehrstufigen Netzen (z.B. Provider-Router → interner Router → mehrere VLANs) reicht eine einzelne Adresse nicht – hier kommt Präfix-Delegation (DHCPv6-PD) ins Spiel: Der vorgelagerte Router (oft der Internet-Provider) delegiert dem nachgelagerten Router ein ganzes Subnetz-Präfix (typisch /56 oder /48), das dieser wiederum in einzelne /64-Subnetze für seine eigenen VLANs aufteilt. Jedes IPv6-Subnetz ist per Konvention ein /64 – anders als bei IPv4 wird hier nicht auf Host-Zahlen hin optimiert, sondern grosszügig nach Zweck (pro VLAN, pro Standort) vergeben.

Dual-Stack-Troubleshooting

Im Dual-Stack-Betrieb (IPv4 und IPv6 gleichzeitig aktiv) entscheidet der Client anhand der Adressauswahl-Regeln (RFC 6724), welches Protokoll er für eine Verbindung bevorzugt – standardmässig gewinnt IPv6, falls eine funktionierende IPv6-Route existiert.

Typisches Fehlerbild: IPv4 funktioniert einwandfrei, aber Verbindungen sind langsam (spürbare Verzögerung beim Verbindungsaufbau, z.B. beim Öffnen von Webseiten). Ursache ist oft ein defektes oder halb funktionierendes IPv6 – der Client versucht zuerst IPv6, wartet auf einen Timeout, und fällt erst danach auf IPv4 zurück (“Happy Eyeballs” soll das eigentlich abfedern, funktioniert aber nicht immer zuverlässig).

Vorgehen bei Verdacht auf Dual-Stack-Problem:

Get-NetIPConfiguration
Test-NetConnection -ComputerName heise.de -InformationLevel Detailed

Zeigt, ob eine IPv6-Adresse und ein IPv6-Gateway vorhanden sind und ob die Route tatsächlich funktioniert.

ping -6 heise.de
ping -4 heise.de

Erzwingt gezielt IPv6 respektive IPv4, um zu isolieren, welches Protokoll das Problem verursacht.

Typische Fehlerbilder und Ursachen

Weiterlernen

• TCP/IP-Adressierung und Subnetze – Microsoft Learn
• Subnetting-Grundlagen – elektronik-kompendium.de
• TCP/IP, OSI, Subnetting & Ethernet erklärt – hagel-it.de
• RFC 1918 – Private IP-Adressbereiche (IETF)
• RFC 3947 – NAT Traversal für IPsec (IETF)
• route – Befehlsreferenz (Microsoft Learn)
• Get-NetRoute (Microsoft Learn)
• Troubleshooting-Methodik für IT-Support
• DNS-Grundlagen – Namensauflösung verstehen
• DHCP-Grundlagen – automatische IP-Vergabe
• VPN-Grundlagen – verschlüsselte Tunnel ins Firmennetz
• Routing-Grundlagen – dynamisches Routing und mehr
• Firewall-Grundlagen – Regeln und Port-Freigaben
• VoIP-Grundlagen – Telefonie über IP
• VLAN-Grundlagen – Netzwerksegmentierung
• Wireshark-Grundlagen – Pakete mitschneiden und analysieren

Videos

YouTube