Uw IPv4-VPN-regel zegt niets over IPv6-verkeer

Een audit vindt de tunnel op dezelfde interface strak gefilterd voor IPv4 en wijd open voor IPv6. Niets was verkeerd geconfigureerd in de zin van een typefout; de regelset beschreef simpelweg één familie en iedereen ging ervan uit dat de andere volgde. Dat doet hij zelden. Drie voorwaarden bepalen of uw regel werkelijk beide dekt, en de eerste gaat over het platform en niet over het beleid.

Voorwaarde één: heeft het platform één tabel of twee

Sommige packetfilters houden IPv4 en IPv6 in volledig gescheiden regelsets, zodat een regel die aan de ene wordt toegevoegd geen effect heeft op de andere tot iemand hem dupliceert. Andere bieden een familie die op beide past en de adressen per pakket vertaalt. Een derde groep houdt één beleidstaal aan maar bewaart daarachter aparte objecten per familie.

Lees de documentatie voor het filter dat u daadwerkelijk draait, en lijst dan op welke tabellen bestaan en welke uw wijziging heeft geraakt. De regels in de IPv4-tabel tellen beantwoordt een vraag die niemand stelde. Lijst daarna op welke tabellen bestaan en welke uw wijziging heeft geraakt.

Voorwaarde twee: waar geldt het beleid

Drie plaatsen worden met elkaar verward: de listener die de tunnel accepteert, het pad dat verkeer doorstuurt, en de gewone interface die de client gebruikt wanneer de tunnel geen stroom draagt. Een gateway kan een sessie accepteren terwijl hij alles wat daaruit wordt doorgestuurd weggooit, en dat ziet eruit als een kapotte tunnel in plaats van een filter. Verwijder die verwarring voordat u iets schrijft, want de drie plaatsen hebben verschillende eigenaren en verschillende logboeken. Ze in het wijzigingsrecord benoemen is wat voorkomt dat een correctie een laag verder van de fout belandt.

Schrijf op welke van de drie uw regel moet beheersen. Een regel die de listener beschermt, beschermt het doorgestuurde pad niet, en geen van beide sluit de directe route van de client. Let op wie elke plaats bezit, want het antwoord is in de meeste organisaties een ander team.

Voorwaarde drie: wat moet IPv6 doen

Beslis of IPv6 door de tunnel reist, wordt geblokkeerd terwijl bescherming niet beschikbaar is, of een gedocumenteerde uitzondering volgt. Elk antwoord levert een andere regelset op, en de vraag openlaten is hoe een client met native IPv6 bestemmingen buiten de tunnel bereikt die hij erbinnen via IPv4 bereikt.

Zeg het antwoord hardop voordat u regels schrijft. Blokkeren is een legitieme keuze voor een tunnel die geen IPv6 draagt, zolang het bewust en getest is en niet het toevallige resultaat van een lege tabel. Alles wat niet gedocumenteerd is, wordt opnieuw beslist door wie de regels hierna aanraakt, en meestal in haast.

ICMPv6 is stuurverkeer

Buurdetectie en padterugkoppeling rijden beide op ICMPv6, dus een algemene drop die uit een IPv4-gewoonte is gekopieerd breekt adressering en grote overdrachten tegelijk. Een algemene toestemming is ook niet het antwoord, want die geeft een kanaal weg dat niemand in de gaten houdt.

Volg de filterrichtlijnen voor de berichttypen die ertoe doen en weiger de rest met een reden. De fout die het vaakst verkeerd wordt gediagnosticeerd is een ontbrekend Packet Too Big-bericht, dat verschijnt als een verbinding die opent en dan vastloopt.

Het bewijzen, één familie per keer

Test een geautoriseerd verzoek over elke familie afzonderlijk, en herhaal dat na opnieuw verbinden als het beleid de sessie moet overleven. Een test op een netwerk met alleen IPv4 kan geen IPv6-route uitoefenen, dus de slagingsmelding zegt niets over het lek dat u probeert te dichten. Houd de tellers in de gaten terwijl de test loopt, want een regel die nooit matcht doet niet wat zijn commentaar beweert.

Wijzig één afgebakende regel per poging en houd de vorige configuratie bij de hand. Waar een beheerd profiel het beleid bezit, betrek zijn beheerder voordat u lokaal bewerkt, want de volgende check-in overschrijft een lokale correctie en herstelt het lek.