Eine Prüfung findet den Tunnel auf derselben Schnittstelle dicht für IPv4 gefiltert und weit offen für IPv6. Nichts war im Sinne eines Tippfehlers falsch konfiguriert; das Regelwerk beschrieb schlicht eine Familie, und alle nahmen an, die andere folge mit. Das tut sie selten. Drei Bedingungen entscheiden, ob Ihre Regel tatsächlich beide abdeckt, und die erste betrifft die Plattform statt die Richtlinie.

Bedingung eins: Hat die Plattform eine Tabelle oder zwei

Manche Paketfilter halten IPv4 und IPv6 in völlig getrennten Regelsätzen, sodass eine Regel, die man dem einen hinzufügt, keine Wirkung auf den anderen hat, bis jemand sie dupliziert. Andere bieten eine Familie, die auf beide passt und die Adressen pro Paket übersetzt. Eine dritte Gruppe hält eine gemeinsame Richtliniensprache, speichert dahinter aber getrennte Objekte je Familie.

Lesen Sie die Dokumentation für den Filter, den Sie tatsächlich betreiben, und listen Sie dann auf, welche Tabellen existieren und welche Ihre Änderung berührt hat. Die Regeln in der IPv4-Tabelle zu zählen, beantwortet eine Frage, die niemand gestellt hat. Listen Sie dann auf, welche Tabellen existieren und welche Ihre Änderung berührt hat.

Bedingung zwei: Wo gilt die Richtlinie

Drei Orte werden miteinander verwechselt: der Listener, der den Tunnel annimmt, der Pfad, der Verkehr weiterleitet, und die gewöhnliche Schnittstelle, die der Client nutzt, wenn der Tunnel keinen Fluss trägt. Ein Gateway kann eine Sitzung annehmen und zugleich alles verwerfen, was von ihr weitergeleitet wird, und das sieht wie ein defekter Tunnel aus, nicht wie ein Filter. Beseitigen Sie diese Verwechslung, bevor Sie etwas schreiben, denn die drei Orte haben verschiedene Eigentümer und verschiedene Protokolle. Sie im Änderungsnachweis zu benennen, verhindert, dass eine Korrektur eine Schicht neben dem Fehler landet.

Notieren Sie, welchen der drei Orte Ihre Regel steuern soll. Eine Regel, die den Listener schützt, schützt nicht den weitergeleiteten Pfad, und keine von beiden schließt die direkte Route des Clients. Vermerken Sie, wem jeder Ort gehört, denn die Antwort ist in den meisten Organisationen ein anderes Team.

Bedingung drei: Was soll IPv6 tun

Entscheiden Sie, ob IPv6 durch den Tunnel läuft, blockiert wird, solange kein Schutz verfügbar ist, oder einer dokumentierten Ausnahme folgt. Jede Antwort ergibt ein anderes Regelwerk, und die Frage offen zu lassen, führt dazu, dass ein Client mit nativem IPv6 Ziele außerhalb des Tunnels erreicht, die er innerhalb über IPv4 erreicht.

Sprechen Sie die Antwort laut aus, bevor Sie Regeln schreiben. Blockieren ist eine legitime Wahl für einen Tunnel, der kein IPv6 trägt, solange sie bewusst und getestet ist und nicht das zufällige Ergebnis einer leeren Tabelle. Alles Undokumentierte wird von demjenigen neu entschieden, der die Regeln als Nächstes anfasst, und meist in Eile.

ICMPv6 ist Steuerverkehr

Nachbarschaftserkennung und Pfadrückmeldung laufen beide über ICMPv6, sodass ein pauschales Verwerfen, das aus einer IPv4-Gewohnheit kopiert wurde, Adressierung und große Übertragungen zugleich bricht. Ein pauschales Erlauben ist ebenso wenig die Antwort, denn es übergibt einen Kanal, den niemand beobachtet.

Folgen Sie der Filteranleitung für die wichtigen Nachrichtentypen und weisen Sie den Rest mit Begründung zurück. Der am häufigsten falsch diagnostizierte Fehler ist eine fehlende Packet Too Big-Nachricht, die sich als Verbindung zeigt, die sich öffnet und dann stockt.

Es beweisen, eine Familie nach der anderen

Testen Sie eine autorisierte Anfrage über jede Familie getrennt und wiederholen Sie das nach einem erneuten Verbindungsaufbau, wenn die Richtlinie die Sitzung überstehen soll. Ein Test in einem reinen IPv4-Netz kann keine IPv6-Route ausüben, daher sagt das Bestehen nichts über das Leck aus, das Sie schließen wollen. Beobachten Sie die Zähler während des Tests, denn eine Regel, die nie trifft, tut nicht, was ihr Kommentar behauptet.

Ändern Sie pro Versuch eine abgegrenzte Regel und halten Sie die vorherige Konfiguration bereit. Wo ein verwaltetes Profil die Richtlinie besitzt, beziehen Sie dessen Administrator ein, bevor Sie lokal bearbeiten, denn der nächste Check-in überschreibt eine lokale Korrektur und stellt das Leck wieder her.

Ähnliche Artikel