Site icon bintorosoft.com

14.12 NAT- und ACL-Probleme überprüfen und beheben

Red Snapper

Computer technology 3D illustration. Computation of big data center. Cloud computing. Online devices upload and download information. Modern 3D illustration. 3D rendering

NAT und ACLs gehören zu den häufigsten Fehlerquellen in Cisco-Netzwerken, weil beide Technologien direkt in den Datenverkehr eingreifen. Schon kleine Konfigurationsfehler können dazu führen, dass Clients das Internet nicht mehr erreichen, Server nicht antworten oder gewünschte Verbindungen unerwartet blockiert werden. Besonders tückisch ist dabei, dass NAT- und ACL-Probleme oft ähnliche Symptome zeigen: Pakete kommen scheinbar nicht an, Verbindungen brechen ab oder nur bestimmte Dienste funktionieren nicht. Genau deshalb ist eine strukturierte Fehlersuche entscheidend. Wer systematisch prüft, ob das Problem bei Routing, NAT, ACL-Reihenfolge, Interface-Zuordnung oder Port-Filterung liegt, kann Fehler deutlich schneller eingrenzen und beheben.

Warum NAT- und ACL-Probleme so häufig auftreten

NAT und ACLs arbeiten beide an zentralen Stellen im Paketfluss. NAT verändert Adressen und bei PAT zusätzlich Ports. ACLs entscheiden, ob ein Paket überhaupt passieren darf. Wenn eine dieser Funktionen falsch konfiguriert ist, wirkt sich das unmittelbar auf die Kommunikation aus.

In der Praxis kommt noch hinzu, dass NAT und ACLs oft zusammen eingesetzt werden. Ein Client-Netz wird beispielsweise per PAT ins Internet übersetzt, während ACLs gleichzeitig festlegen, welcher Traffic erlaubt ist. Dadurch kann ein Fehlerbild schnell unübersichtlich werden: Funktioniert NAT nicht, die ACL nicht oder beides?

Typische Gründe für Probleme

Typische Symptome bei NAT- und ACL-Problemen

Bevor die Fehlersuche beginnt, sollte das Fehlerbild sauber eingeordnet werden. Das spart Zeit, weil sich daraus oft schon ableiten lässt, ob eher NAT oder ACLs die Ursache sind.

Typische NAT-Symptome

Typische ACL-Symptome

Wichtige Grundfrage

Bei der Analyse sollte zuerst geklärt werden: Wird das Paket falsch übersetzt oder wird es gefiltert? Diese Unterscheidung ist zentral, weil sich NAT- und ACL-Fehler zwar ähnlich zeigen können, aber anders geprüft werden müssen.

Strukturierter Ablauf für die Fehlersuche

Eine gute Troubleshooting-Strategie arbeitet nicht planlos mit Einzelbefehlen, sondern systematisch. Zuerst wird die Basis geprüft, dann Routing, danach NAT und schließlich ACLs. So lässt sich der Fehler sauber eingrenzen.

Empfohlene Prüfreihenfolge

Schritt eins: Basis und Routing prüfen

Viele vermeintliche NAT- oder ACL-Probleme sind in Wirklichkeit Routing- oder Interface-Probleme. Wenn ein WAN-Interface down ist oder die Default Route fehlt, kann auch eine perfekte NAT-Konfiguration keinen Internetzugang ermöglichen.

Wichtige Basisbefehle

show ip interface brief
show interfaces GigabitEthernet0/0
show ip route
show ip route 0.0.0.0
ping 8.8.8.8

Mit diesen Befehlen lässt sich prüfen, ob Interfaces aktiv sind, ob das Routing grundsätzlich funktioniert und ob eine Standardroute vorhanden ist.

Worauf geachtet werden sollte

Typischer Denkfehler

Wenn der Router selbst das Internet nicht erreicht, ist NAT meist noch nicht der erste Prüfpunkt. In diesem Fall liegt das Problem häufig schon bei Routing, WAN-Konnektivität oder Upstream-Erreichbarkeit.

Schritt zwei: NAT-Grundkonfiguration kontrollieren

Wenn Routing funktioniert, sollte die eigentliche NAT-Konfiguration geprüft werden. Auf Cisco-Geräten sind dafür vor allem drei Punkte entscheidend: die Markierung der Interfaces, das Matching der Quellnetze und die eigentliche Übersetzungsregel.

Wichtige NAT-Bestandteile

Beispiel für klassisches PAT

access-list 1 permit 192.168.10.0 0.0.0.255

interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside

interface GigabitEthernet0/1
 ip address 203.0.113.10 255.255.255.248
 ip nat outside

ip nat inside source list 1 interface GigabitEthernet0/1 overload

Typische NAT-Fehlerquellen

Schritt drei: NAT-Translations prüfen

Wenn NAT korrekt arbeiten soll, müssen Übersetzungen sichtbar sein. Genau deshalb ist die NAT-Translation-Tabelle einer der wichtigsten Prüfbereiche. Fehlen dort Einträge, obwohl Client-Traffic erzeugt wird, liegt das Problem meist in der NAT-Regel oder im Matching.

Wichtige NAT-Befehle

show ip nat translations
show ip nat statistics
show running-config | section ip nat

show ip nat translations

Dieser Befehl zeigt aktive Übersetzungen. Bei PAT sollten hier Einträge mit privaten und öffentlichen Adressen sowie übersetzten Ports sichtbar werden.

show ip nat statistics

Mit diesem Befehl lassen sich Hits, Misses, aktive Übersetzungen und die Zuordnung der NAT-Interfaces prüfen.

Was fehlende Translations bedeuten können

Schritt vier: ACL-Konfiguration kontrollieren

Wenn NAT plausibel aussieht oder wenn das Fehlerbild stark nach Filterung aussieht, muss die ACL genau untersucht werden. Hier sind Inhalt, Reihenfolge, Richtung und Platzierung entscheidend.

Wichtige ACL-Befehle

show access-lists
show ip interface
show running-config | section access-list
show running-config | section ip access-list

show access-lists

Dieser Befehl zeigt nicht nur die ACL-Regeln, sondern oft auch Trefferzähler. Diese Counter sind besonders wertvoll, weil sie sichtbar machen, welche Regel tatsächlich Pakete matcht.

show ip interface

Damit lässt sich prüfen, welche ACL auf welchem Interface aktiv ist und ob sie inbound oder outbound angewendet wurde.

Typische ACL-Fehlerquellen

Zusammenspiel von NAT und ACL verstehen

Eine der häufigsten Fehlerquellen entsteht dort, wo NAT und ACLs gleichzeitig wirken. Ein Paket muss dann oft mehrere Bedingungen erfüllen: Es darf nicht durch eine ACL blockiert werden, muss das NAT-Matching treffen und braucht funktionierendes Routing. Fällt eine dieser Bedingungen weg, funktioniert die Verbindung nicht.

Wichtige Praxisfrage

Man sollte immer prüfen, an welcher Stelle im Paketfluss die ACL und das NAT greifen. Entscheidend ist dabei, dass ACLs und NAT nicht einfach austauschbar sind, sondern unterschiedliche Aufgaben haben.

Typisches Szenario

Dann funktioniert möglicherweise der Browser scheinbar nicht richtig, obwohl NAT korrekt arbeitet. Das Problem liegt in Wirklichkeit an der ACL, die DNS blockiert.

Praxisbeispiel: Client erreicht Internet nicht

Angenommen, ein Client aus 192.168.10.0/24 soll per PAT über GigabitEthernet0/1 ins Internet. Die Konfiguration sieht auf den ersten Blick korrekt aus, aber der Zugriff funktioniert nicht.

Beispielkonfiguration

access-list 1 permit 192.168.10.0 0.0.0.255

interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside

interface GigabitEthernet0/1
 ip address 203.0.113.10 255.255.255.248
 ip nat outside

ip nat inside source list 1 interface GigabitEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 203.0.113.9

Nun zeigt show ip nat translations keine Einträge.

Mögliche Ursachen

Sinnvolle Prüfschritte

show ip interface brief
show ip nat statistics
show access-lists
show ip interface GigabitEthernet0/0
show ip interface GigabitEthernet0/1

Wenn sich zeigt, dass eine ACL den Traffic bereits am LAN-Interface blockiert, muss zuerst diese ACL korrigiert werden. NAT kann nur mit Paketen arbeiten, die das NAT-Gerät überhaupt erreichen.

Praxisbeispiel: Web funktioniert, DNS nicht

Ein sehr typischer Fehler ist, dass eine Extended ACL nur HTTP und HTTPS erlaubt, aber DNS vergisst. Dann scheint der Webzugriff aus Benutzersicht kaputt zu sein, obwohl NAT korrekt übersetzt.

Fehlerhafte ACL

ip access-list extended INTERNET-FILTER
 permit tcp 192.168.10.0 0.0.0.255 any eq 80
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Hier wird DNS über UDP 53 nicht erlaubt. Webseiten lassen sich dann oft nicht per Name auflösen.

Korrigierte ACL

ip access-list extended INTERNET-FILTER
 permit udp 192.168.10.0 0.0.0.255 any eq 53
 permit tcp 192.168.10.0 0.0.0.255 any eq 80
 permit tcp 192.168.10.0 0.0.0.255 any eq 443
 deny ip any any

Wichtige Erkenntnis

Wenn NAT funktioniert, aber bestimmte Dienste nicht, sollte immer geprüft werden, ob eine ACL genau diesen Dienst oder dessen Hilfsprotokolle blockiert.

Praxisbeispiel: veröffentlichter Server von außen nicht erreichbar

Bei statischem NAT oder Portweiterleitung treten häufig Fehler auf, wenn entweder die NAT-Zuordnung oder die eingehende ACL nicht sauber abgestimmt ist.

Beispiel für statisches NAT

ip nat inside source static 192.168.20.10 203.0.113.20

Ein externer Client soll den internen Server 192.168.20.10 über 203.0.113.20 erreichen. Wenn das nicht funktioniert, muss mehr als nur NAT geprüft werden.

Typische Ursachen

Wichtige Prüfbefehle

show ip nat translations
show access-lists
show ip route
ping 192.168.20.10

Gerade bei Serververöffentlichungen sollte immer geprüft werden, ob der Rückweg ebenfalls funktioniert. NAT allein reicht nicht, wenn Server-Gateway oder ACL-Logik den Rückverkehr blockieren.

ACL-Reihenfolge gezielt überprüfen

Eine der häufigsten ACL-Ursachen ist die falsche Reihenfolge der Regeln. Da ACLs nach dem Prinzip „first match“ arbeiten, kann eine einzige zu allgemeine Regel späteren Einträgen die Wirkung nehmen.

Fehlerhaftes Beispiel

ip access-list extended BROKEN-ACL
 permit ip any any
 deny tcp 192.168.10.0 0.0.0.255 any eq 23

Die zweite Regel wird nie erreicht, weil bereits die erste Regel allen IP-Verkehr erlaubt.

Korrigierte Reihenfolge

ip access-list extended WORKING-ACL
 deny tcp 192.168.10.0 0.0.0.255 any eq 23
 permit ip any any

Worauf geachtet werden sollte

Richtung und Platzierung der ACL prüfen

Eine ACL kann inhaltlich korrekt sein und trotzdem falsch wirken, wenn sie am falschen Interface oder in der falschen Richtung eingesetzt wurde. Gerade bei komplexeren Netzwerken ist das ein sehr häufiger Fehler.

Typische Fehlplatzierungen

Wichtige Prüfbefehle

show ip interface
show running-config | section interface

Mit diesen Befehlen lässt sich kontrollieren, welche ACL auf welchem Interface aktiv ist und ob sie in der richtigen Richtung greift.

Debugging bei NAT- und ACL-Problemen

Wenn die Show-Befehle keine klare Ursache liefern, kann Debugging helfen. Auf produktiven Geräten sollte es allerdings vorsichtig eingesetzt werden, weil es CPU-Last erzeugen kann.

Nützliche NAT-Debugs

debug ip nat

Dieser Befehl zeigt, ob NAT-Übersetzungen erzeugt oder verarbeitet werden.

ACL-bezogenes Vorgehen

Bei ACL-Problemen helfen oft weniger klassische Debugs als vielmehr:

Debug wieder deaktivieren

undebug all

Best Practices für NAT- und ACL-Troubleshooting

Eine saubere Fehlersuche lebt davon, dass NAT und ACLs nicht isoliert, sondern im gesamten Paketfluss betrachtet werden. Ziel ist immer, den exakten Punkt zu finden, an dem das Paket scheitert: beim Eintritt, bei der Übersetzung, beim Routing oder beim Verlassen des Geräts.

Bewährte Vorgehensweisen

Praxisnaher Denkansatz

Die effektivste Fehlersuche bei NAT- und ACL-Problemen beginnt nicht mit dem Ändern der Konfiguration, sondern mit einer klaren Frage: Wo genau im Paketfluss geht die Kommunikation verloren? Wer diese Frage sauber beantwortet, findet meist sehr schnell, ob Routing, NAT oder ACLs die eigentliche Ursache sind.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version