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

Ein revisjon finn at tunnelen er filtrert stramt for IPv4 og vidopen for IPv6 på same grensesnitt. Ingenting var feilkonfigurert i tydinga skrivefeil; regelsettet skildra berre éin familie, og alle gjekk ut frå at den andre følgde etter. Det gjer han sjeldan. Tre vilkår avgjer om regelen din faktisk dekkjer begge, og det første handlar om plattforma snarare enn om policyen.

Vilkår éin: har plattforma éi tabell eller to

Nokre pakkefilter held IPv4 og IPv6 i heilt åtskilde regelsett, slik at ein regel som blir lagd til det eine, ikkje har noka verknad på det andre før nokon dupliserer han. Andre tilbyr ein familie som passar begge og omset adressene per pakke. Ei tredje gruppe held eitt policyspråk men lagrar separate objekt per familie bak det.

Les dokumentasjonen for filteret du faktisk køyrer, og list deretter opp kva tabellar som finst og kva endringa di rørte. Å telje reglane i IPv4-tabellen svarar på eit spørsmål ingen stilte. List deretter opp kva tabellar som finst og kva endringa di rørte.

Vilkår to: kvar gjeld policyen

Tre stader blir forveksla med kvarandre: lyttaren som godtek tunnelen, vegen som videresender trafikk, og det vanlege grensesnittet klienten brukar når tunnelen ikkje ber ein straum. Ein gateway kan godta ein sesjon og samstundes droppe alt som blir videresendt frå han, og det ser ut som ein øydelagd tunnel snarare enn eit filter. Fjern den forvirringa før du skriv noko, fordi dei tre stadene har ulike eigarar og ulike loggar. Å namngje dei i endringsnotatet er det som hindrar at ei retting landar eit lag unna feilen.

Skriv ned kva av dei tre regelen din skal styre. Ein regel som vernar lyttaren vernar ikkje den videresende vegen, og ingen av dei stenger den direkte ruta til klienten. Legg merke til kven som eig kvar stad, fordi svaret i dei fleste organisasjonar er eit anna team.

Vilkår tre: kva skal IPv6 gjere

Avgjer om IPv6 reiser gjennom tunnelen, blir blokkert medan vern ikkje er tilgjengeleg, eller følgjer eit dokumentert unntak. Kvart svar gir eit anna regelsett, og å la spørsmålet stå ope er måten ein klient med innebygd IPv6 når destinasjonar utanfor tunnelen som han når inni han over IPv4.

Sei svaret høgt før du skriv reglar. Blokkering er eit legitimt val for ein tunnel som ikkje ber IPv6, så lenge det er medvite og testa og ikkje det tilfeldige resultatet av ein tom tabell. Alt udokumentert blir avgjort på nytt av den som neste gong rører reglane, og vanlegvis i all hast.

ICMPv6 er kontrolltrafikk

Nabo-oppdaging og sti-tilbakemelding går begge på ICMPv6, så ein generell dropp kopiert frå ein IPv4-vane øydelegg adressering og store overføringar samstundes. Eit generelt løyve er heller ikkje svaret, fordi det overlèt ein kanal ingen overvakar.

Følg filtreringsrettleiinga for meldingstypane som betyr noko og avvis resten med ein grunn. Feilen som oftast blir feildiagnostisert er ei manglande Packet Too Big-melding, som viser seg som ei tilkopling som opnar og deretter stoppar.

Å prove det, éin familie om gongen

Test ein autorisert førespurnad over kvar familie separat, og gjenta etter ein ny tilkopling om policyen skal overleve sesjonen. Ein test på eit nettverk med berre IPv4 kan ikkje utøve ei IPv6-rute, så beståinga seier ingenting om lekkasjen du prøver å lukke. Følg med på teljarane medan testen køyrer, fordi ein regel som aldri treffer gjer ikkje det kommentaren påstår.

Endre éin avgrensa regel per forsøk og ha den førre konfigurasjonen for handa. Der ein administrert profil eig policyen, involver administratoren før du redigerer lokalt, fordi neste innsjekk vil skrive over ei lokal retting og gjenopprette lekkasjen.