Jou IPv4-VPN-reël sê niks oor IPv6-verkeer

’n Oudit vind die tonnel styf gefiltreer vir IPv4 en heeltemal oop vir IPv6 op dieselfde koppelvlak. Niks is verkeerd opgestel in die sin van ’n tikfout nie; die reëlversameling het bloot een familie beskryf en almal het aangeneem die ander volg. Dit gebeur selde. Drie voorwaardes bepaal of jou reël werklik albei dek, en die eerste een gaan oor die platform, nie oor die beleid nie.

Voorwaarde een: het die platform een tabel of twee

Sommige pakketfilters hou IPv4 en IPv6 in heeltemal aparte reëlversamelings, so ’n reël wat by die een gevoeg word, het geen uitwerking op die ander voordat iemand dit dupliseer nie. Ander bied ’n familie wat albei pas en die adresse per pakkie vertaal. ’n Derde groep hou een beleidstaal maar stoor aparte objekte per familie agter dit.

Lees die dokumentasie vir die filter wat jy werklik gebruik, en lys dan watter tabelle bestaan en watter een jou verandering geraak het. Om die reëls in die IPv4-tabel te tel, beantwoord ’n vraag wat niemand gevra het nie. Lys dan watter tabelle bestaan en watter een jou verandering geraak het.

Voorwaarde twee: waar geld die beleid

Drie plekke word met mekaar verwar: die luisteraar wat die tonnel aanvaar, die pad wat verkeer verder aanstuur, en die gewone koppelvlak wat die kliënt gebruik wanneer die tonnel nie ’n vloei dra nie. ’n Gateway kan ’n sessie aanvaar terwyl alles wat daarvan aangestuur word, laat val word, en dit lyk soos ’n stukkende tonnel eerder as ’n filter. Verwyder daardie verwarring voordat jy iets skryf, want die drie plekke het verskillende eienaars en verskillende logboeke. Om hulle in die veranderingsrekord te noem, is wat verhoed dat ’n regstelling een laag weg van die fout beland.

Skryf neer watter van die drie jou reël bedoel is om te beheer. ’n Reël wat die luisteraar beskerm, beskerm nie die aangestuurde pad nie, en nie een van die twee sluit die kliënt se direkte roete nie. Let op wie elkeen van die plekke besit, want die antwoord is in die meeste organisasies ’n ander span.

Voorwaarde drie: wat moet IPv6 doen

Besluit of IPv6 deur die tonnel reis, geblokkeer word terwyl beskerming onbeskikbaar is, of ’n gedokumenteerde uitsondering volg. Elke antwoord lewer ’n ander reëlversameling, en om die vraag oop te laat, is hoe ’n kliënt met inheemse IPv6 bestemmings buite die tonnel bereik wat hy binne die tonnel oor IPv4 bereik.

Sê die antwoord hardop voordat jy reëls skryf. Blokkering is ’n geldige keuse vir ’n tonnel wat geen IPv6 dra nie, solank dit doelbewus en getoets is, en nie die toevallige gevolg van ’n leë tabel nie. Enigiets wat nie gedokumenteer is nie, sal deur die volgende persoon wat aan die reëls raak, weer besluit word, en gewoonlik in ’n haas.

ICMPv6 is beheerverkeer

Buurontdekking en padterugvoer ry albei op ICMPv6, so ’n algehele verwerping wat van ’n IPv4-gewoonte gekopieer is, breek adressering en groot oordragte tegelyk. ’n Algehele toelating is ook nie die antwoord nie, want dit gee ’n kanaal oor wat niemand dophou nie.

Volg die filterriglyne vir die boodskaptipes wat saak maak en verwerp die res met ’n rede. Die fout wat die meeste verkeerd gediagnoseer word, is ’n ontbrekende Packet Too Big-boodskap, wat opduik as ’n verbinding wat oopgaan en dan vasval.

Bewys dit, een familie op ’n slag

Toets ’n gemagtigde versoek oor elke familie afsonderlik, en herhaal dit ná ’n herverbinding as die beleid veronderstel is om die sessie te oorleef. ’n Toets op ’n slegs-IPv4-netwerk kan nie ’n IPv6-roete uitoefen nie, so die slaag sê niks oor die lek wat jy probeer toemaak nie. Dophou die tellers terwyl die toets loop, want ’n reël wat nooit pas nie, doen nie wat sy kommentaar beweer nie.

Verander een afgebakende reël per poging en hou die vorige konfigurasie byderhand. Waar ’n bestuurde profiel die beleid besit, betrek sy administrateur voordat jy plaaslik wysig, want die volgende aanmelding sal ’n plaaslike regstelling oorskryf en die lek herstel.