Din IPv4-VPN-regel säger ingenting om IPv6-trafik

En granskning finner att tunneln är hårt filtrerad för IPv4 och vitt öppen för IPv6 på samma gränssnitt. Ingenting var felkonfigurerat i betydelsen skrivfel; regeluppsättningen beskrev helt enkelt en familj och alla antog att den andra följde efter. Det gör den sällan. Tre villkor avgör om din regel verkligen täcker båda, och det första handlar om plattformen snarare än om policyn.

Villkor ett: har plattformen en tabell eller två

Vissa paketfilter håller IPv4 och IPv6 i helt åtskilda regeluppsättningar, så en regel som läggs till i den ena har ingen verkan på den andra förrän någon duplicerar den. Andra erbjuder en familj som matchar båda och översätter adresserna per paket. En tredje grupp håller ett enda policyspråk men lagrar separata objekt per familj bakom det.

Läs dokumentationen för det filter du faktiskt kör och lista sedan vilka tabeller som finns och vilken din ändring rörde. Att räkna reglerna i IPv4-tabellen svarar på en fråga som ingen ställde. Lista sedan vilka tabeller som finns och vilken din ändring rörde.

Villkor två: var gäller policyn

Tre platser förväxlas med varandra: lyssnaren som tar emot tunneln, vägen som vidarebefordrar trafik och det vanliga gränssnittet som klienten använder när tunneln inte bär ett flöde. En gateway kan acceptera en session och samtidigt släppa allt som vidarebefordras från den, och det ser ut som en trasig tunnel snarare än ett filter. Ta bort den förvirringen innan du skriver något, eftersom de tre platserna har olika ägare och olika loggar. Att namnge dem i ändringsprotokollet är det som hindrar en rättelse från att landa ett lager bort från felet.

Skriv ner vilken av de tre din regel ska styra. En regel som skyddar lyssnaren skyddar inte den vidarebefordrade vägen, och ingen av dem stänger klientens direkta väg. Notera vem som äger varje plats, eftersom svaret i de flesta organisationer är ett annat team.

Villkor tre: vad ska IPv6 göra

Bestäm om IPv6 reser genom tunneln, blockeras medan skydd inte är tillgängligt, eller följer ett dokumenterat undantag. Varje svar ger en annan regeluppsättning, och att lämna frågan öppen är hur en klient med inbyggd IPv6 når mål utanför tunneln som den når inuti den över IPv4.

Säg svaret högt innan du skriver regler. Blockering är ett legitimt val för en tunnel som inte bär IPv6, så länge det är avsiktligt och testat och inte det slumpmässiga resultatet av en tom tabell. Allt odokumenterat kommer att avgöras på nytt av den som härnäst rör reglerna, och vanligtvis i hast.

ICMPv6 är kontrolltrafik

Granndetektering och sökvägsåterkoppling går båda på ICMPv6, så en generell drop kopierad från en IPv4-vana bryter adressering och stora överföringar samtidigt. En generell tillåtelse är inte heller svaret, eftersom den lämnar över en kanal som ingen bevakar.

Följ filtreringsvägledningen för de meddelandetyper som spelar roll och avvisa resten med en anledning. Felet som oftast feldiagnostiseras är ett saknat Packet Too Big-meddelande, som visar sig som en anslutning som öppnas och sedan stannar.

Att bevisa det, en familj i taget

Testa en auktoriserad begäran över varje familj separat och upprepa efter en återanslutning om policyn ska överleva sessionen. Ett test i ett nätverk med bara IPv4 kan inte utöva en IPv6-väg, så godkännandet säger ingenting om det läckage du försöker stänga. Håll koll på räknarna medan testet körs, eftersom en regel som aldrig matchar inte gör det kommentaren påstår.

Ändra en avgränsad regel per försök och ha den tidigare konfigurationen till hands. Där en hanterad profil äger policyn, involvera dess administratör innan du redigerar lokalt, eftersom nästa incheckning skriver över en lokal rättelse och återställer läckaget.