Din IPv4-VPN-regel siger intet om IPv6-trafik

En revision viser, at tunnelen er filtreret stramt for IPv4 og vidt åben for IPv6 på samme interface. Intet var fejlkonfigureret i betydningen tastefejl; regelsættet beskrev blot én familie, og alle antog, at den anden fulgte med. Det gør den sjældent. Tre betingelser afgør, om din regel faktisk dækker begge, og den første handler om platformen snarere end om politikken.

Betingelse et: har platformen én tabel eller to

Nogle pakkefiltre holder IPv4 og IPv6 i helt adskilte regelsæt, så en regel, der føjes til det ene, ikke har nogen virkning på det andet, før nogen duplikerer den. Andre tilbyder en familie, der matcher begge og oversætter adresserne per pakke. En tredje gruppe holder ét sprog for politikker men gemmer separate objekter per familie bag det.

Læs dokumentationen for det filter, du faktisk kører, og list derefter, hvilke tabeller der findes, og hvilken din ændring rørte ved. At tælle reglerne i IPv4-tabellen besvarer et spørgsmål, ingen stillede. List derefter, hvilke tabeller der findes, og hvilken din ændring rørte ved.

Betingelse to: hvor gælder politikken

Tre steder forveksles med hinanden: lytteren, der accepterer tunnelen, vejen der videresender trafik, og det almindelige interface, klienten bruger, når tunnelen ikke bærer en strøm. En gateway kan acceptere en session og samtidig droppe alt, der videresendes fra den, og det ligner en brudt tunnel snarere end et filter. Fjern den forveksling, før du skriver noget, fordi de tre steder har forskellige ejere og forskellige logfiler. At navngive dem i ændringsnotatet er det, der forhindrer, at en rettelse lander et lag væk fra fejlen.

Skriv ned, hvilket af de tre din regel skal styre. En regel, der beskytter lytteren, beskytter ikke den videresendte vej, og ingen af dem lukker klientens direkte rute. Bemærk, hvem der ejer hvert sted, fordi svaret i de fleste organisationer er et andet team.

Betingelse tre: hvad skal IPv6 gøre

Beslut, om IPv6 rejser gennem tunnelen, blokeres, mens beskyttelsen ikke er tilgængelig, eller følger en dokumenteret undtagelse. Hvert svar giver et andet regelsæt, og at lade spørgsmålet stå åbent er måden, hvorpå en klient med indfødt IPv6 når destinationer uden for tunnelen, som den når indeni den over IPv4.

Sig svaret højt, før du skriver regler. Blokering er et legitimt valg for en tunnel, der ikke bærer IPv6, så længe det er bevidst og testet og ikke det tilfældige resultat af en tom tabel. Alt udokumenteret vil blive besluttet igen af den, der næste gang rører ved reglerne, og som regel i en fart.

ICMPv6 er kontroltrafik

Nabo-opdagelse og sti-tilbagemelding kører begge på ICMPv6, så et generelt drop kopieret fra en IPv4-vane ødelægger adressering og store overførsler på samme tid. Et generelt allow er heller ikke svaret, fordi det udleverer en kanal, som ingen overvåger.

Følg filtreringsvejledningen for de meddelelsestyper, der betyder noget, og afvis resten med en begrundelse. Den fejl, der oftest fejldiagnosticeres, er en manglende Packet Too Big-meddelelse, som viser sig som en forbindelse, der åbner og derefter går i stå.

At bevise det, én familie ad gangen

Test en autoriseret anmodning over hver familie separat, og gentag derefter efter en genopkobling, hvis politikken skal overleve sessionen. En test på et netværk med kun IPv4 kan ikke udøve en IPv6-rute, så beståelsen siger intet om den lækage, du forsøger at lukke. Hold øje med tællerne, mens testen kører, fordi en regel, der aldrig matcher, ikke gør det, dens kommentar påstår.

Ændr én afgrænset regel per forsøg, og hav den tidligere konfiguration ved hånden. Hvor en administreret profil ejer politikken, skal du inddrage dens administrator, før du redigerer lokalt, fordi næste check-in overskriver en lokal rettelse og gendanner lækagen.