IPv4-VPN-regelen din sier ingenting om IPv6-trafikk

En revisjon finner at tunnelen er filtrert stramt for IPv4 og vidåpen for IPv6 på samme grensesnitt. Ingenting var feilkonfigurert i betydningen skrivefeil; regelsettet beskrev bare én familie, og alle antok at den andre fulgte etter. Det gjør den sjelden. Tre betingelser avgjør om regelen din faktisk dekker begge, og den første handler om plattformen snarere enn om policyen.

Betingelse én: har plattformen én tabell eller to

Noen pakkefiltre holder IPv4 og IPv6 i helt atskilte regelsett, slik at en regel som legges til det ene, ikke har noen virkning på det andre før noen dupliserer den. Andre tilbyr en familie som passer begge og oversetter adressene per pakke. En tredje gruppe holder ett policyspråk men lagrer separate objekter per familie bak det.

Les dokumentasjonen for filteret du faktisk kjører, og list deretter opp hvilke tabeller som finnes og hvilken endringen din berørte. Å telle reglene i IPv4-tabellen svarer på et spørsmål ingen stilte. List deretter opp hvilke tabeller som finnes og hvilken endringen din berørte.

Betingelse to: hvor gjelder policyen

Tre steder forveksles med hverandre: lytteren som godtar tunnelen, veien som videresender trafikk, og det vanlige grensesnittet klienten bruker når tunnelen ikke bærer en strøm. En gateway kan godta en sesjon og samtidig droppe alt som videresendes fra den, og det ser ut som en ødelagt tunnel snarere enn et filter. Fjern den forvirringen før du skriver noe, fordi de tre stedene har forskjellige eiere og forskjellige logger. Å navngi dem i endringsnotatet er det som hindrer at en rettelse lander et lag unna feilen.

Skriv ned hvilket av de tre regelen din skal styre. En regel som beskytter lytteren beskytter ikke den videresendte veien, og ingen av dem stenger klientens direkte rute. Legg merke til hvem som eier hvert sted, fordi svaret i de fleste organisasjoner er et annet team.

Betingelse tre: hva skal IPv6 gjøre

Bestem om IPv6 reiser gjennom tunnelen, blokkeres mens beskyttelse ikke er tilgjengelig, eller følger et dokumentert unntak. Hvert svar gir et annet regelsett, og å la spørsmålet stå åpent er måten en klient med innebygd IPv6 når destinasjoner utenfor tunnelen som den når inni den over IPv4.

Si svaret høyt før du skriver regler. Blokkering er et legitimt valg for en tunnel som ikke bærer IPv6, så lenge det er bevisst og testet og ikke det tilfeldige resultatet av en tom tabell. Alt udokumentert vil bli bestemt på nytt av den som neste gang berører reglene, og vanligvis i all hast.

ICMPv6 er kontrolltrafikk

Nabo-oppdagelse og sti-tilbakemelding går begge på ICMPv6, så en generell dropp kopiert fra en IPv4-vane ødelegger adressering og store overføringer samtidig. En generell tillatelse er heller ikke svaret, fordi den overlater en kanal ingen overvåker.

Følg filtreringsveiledningen for meldingstypene som betyr noe og avvis resten med en begrunnelse. Feilen som oftest feildiagnostiseres er en manglende Packet Too Big-melding, som viser seg som en forbindelse som åpnes og deretter stopper.

Å bevise det, én familie av gangen

Test en autorisert forespørsel over hver familie separat, og gjenta etter en gjentilkobling hvis policyen skal overleve sesjonen. En test på et nettverk med bare IPv4 kan ikke utøve en IPv6-rute, så beståelsen sier ingenting om lekkasjen du prøver å lukke. Følg med på tellerne mens testen kjører, fordi en regel som aldri treffer ikke gjør det kommentaren påstår.

Endre én avgrenset regel per forsøk og ha den forrige konfigurasjonen for hånden. Der en administrert profil eier policyen, involver administratoren før du redigerer lokalt, fordi neste innsjekk vil overskrive en lokal retting og gjenopprette lekkasjen.