Via IPv4-VPN-regulo diras nenion pri IPv6-trafiko
Tri kondiĉoj decidas, ĉu via regulo kovras ambaŭ familiojn: la regula modelo de la platformo, la loko, kie ĝi validas, kaj la vojo, kiun IPv6 devas sekvi.
Revizio trovas la tunelon strikte filtrita por IPv4 kaj tute malfermita por IPv6 sur la sama interfaco. Nenio estis misagordita laŭ la senco de tajperaro; la regularo simple priskribis unu familion kaj ĉiuj supozis, ke la alia sekvas. Tio malofte okazas. Tri kondiĉoj decidas, ĉu via regulo vere kovras ambaŭ, kaj la unua temas pri la platformo, ne pri la politiko.
Kondiĉo unua: ĉu la platformo havas unu tabelon aŭ du
Kelkaj pakaĵfiltriloj tenas IPv4 kaj IPv6 en tute apartaj regularoj, do regulo aldonita al unu havas neniun efikon sur la alia ĝis iu duobligas ĝin. Aliaj proponas familion, kiu kongruas kun ambaŭ kaj tradukas la adresojn po pakaĵo. Tria grupo tenas unu politikan lingvon sed konservas apartajn objektojn po familio malantaŭ ĝi.
Legu la dokumentaron pri la filtrilo, kiun vi efektive funkciigas, poste listigu, kiuj tabeloj ekzistas kaj kiun via ŝanĝo tuŝis. Nombri la regulojn en la IPv4-tabelo respondas demandon, kiun neniu faris. Poste listigu, kiuj tabeloj ekzistas kaj kiun via ŝanĝo tuŝis.
Kondiĉo dua: kie validas la politiko
Tri lokoj konfuziĝas unu kun la alia: la aŭskultanto, kiu akceptas la tunelon, la vojo, kiu plusendas trafikon, kaj la ordinara interfaco, kiun la kliento uzas kiam la tunelo ne portas fluon. Klariga pordego povas akcepti sesion dum ĝi forĵetas ĉion plusenditan de ĝi, kaj tio aspektas kiel rompita tunelo, ne kiel filtrilo. Forigu tiun konfuzon antaŭ ol skribi ion ajn, ĉar la tri lokoj havas malsamajn posedantojn kaj malsamajn protokolojn. Nomado de ili en la ŝanĝregistro estas tio, kio malhelpas, ke riparo surteriĝu unu tavolon for de la difekto.
Notu, kiun el la tri via regulo celas regi. Regulo, kiu protektas la aŭskultanton, ne protektas la plusendan vojon, kaj neniu el la du fermas la rektan itineron de la kliento. Rimarku, kiu posedas ĉiun lokon, ĉar la respondo en plej multaj organizoj estas malsama teamo.
Kondiĉo tria: kion devus fari IPv6
Decidu, ĉu IPv6 vojaĝas tra la tunelo, ĉu ĝi estas blokata dum protekto ne haveblas, aŭ ĉu ĝi sekvas dokumentitan escepton. Ĉiu respondo produktas malsaman regularon, kaj lasi la demandon malfermita estas kiel kliento kun denaska IPv6 atingas celojn ekster la tunelo, kiujn ĝi atingas interne per IPv4.
Diru la respondon laŭte antaŭ ol skribi regulojn. Blokado estas legitima elekto por tunelo, kiu portas neniun IPv6, kondiĉe ke ĝi estas intenca kaj testita, ne la hazarda rezulto de malplena tabelo. Ĉio nedokumentita estos redecidita de tiu, kiu sekve tuŝos la regulojn, kaj kutime haste.
ICMPv6 estas rega trafiko
Najbara malkovro kaj voja reago ambaŭ veturas sur ICMPv6, do senkrita forĵeto kopiita el IPv4-kutimo rompas adresadon kaj grandajn transigojn samtempe. Ankaŭ senkrita permeso ne estas la respondo, ĉar ĝi transdonas kanalon, kiun neniu observas.
Sekvu la filtradan gvidadon por la mesaĝtipoj, kiuj gravas, kaj malakceptu la ceterajn kun kialo. La difekto, kiu plej ofte estas mise diagnozita, estas mankanta mesaĝo Packet Too Big, kiu montriĝas kiel konekto, kiu malfermiĝas kaj poste haltas.
Pruvi ĝin, unu familion samtempe
Testu rajtigitan peton en ĉiu familio aparte, poste ripetu post rekonekto se la politiko devas postvivi la sesion. Testo en reto nur-IPv4 ne povas ekzerci IPv6-itineron, do la sukceso diras nenion pri la liko, kiun vi provas fermi. Observu la nombrilojn dum la testo rulas, ĉar regulo, kiu neniam kongruas, ne faras tion, kion asertas ĝia komento.
Ŝanĝu unu limigitan regulon po provo kaj tenu la antaŭan agordon preta. Kie administrata profilo posedas la politikon, engaĝigu ĝian administranton antaŭ ol redakti loke, ĉar la sekva kontrolo anstataŭigos lokan riparon kaj restarigos la likon.