Teie IPv4 VPN-i reegel ei ütle IPv6 liikluse kohta midagi
Kolm tingimust otsustavad, kas teie reegel katab mõlemad pered: platvormi reeglimudel, koht, kus see kehtib, ja tee, mille IPv6 peaks läbima.
Audit leiab, et tunnel on samal liidesel IPv4 jaoks tihedalt filtreeritud ja IPv6 jaoks pärani avatud. Midagi ei olnud valesti seadistatud trükivea mõttes; reeglistik kirjeldas lihtsalt üht perekonda ja kõik eeldasid, et teine järgib. Harva järgib. Kolm tingimust otsustavad, kas teie reegel tegelikult katab mõlemad, ja esimene puudutab platvormi, mitte poliitikat.
Tingimus esimene: kas platvormil on üks tabel või kaks
Mõned paketifiltrid hoiavad IPv4 ja IPv6 täiesti eraldi reeglistikes, nii et ühte lisatud reegel ei mõjuta teist enne, kui keegi selle dubleerib. Teised pakuvad perekonda, mis sobib mõlemaga ja tõlgib aadressid iga paketi kohta. Kolmas rühm hoiab üht poliitikakeelt, kuid hoiab selle taga iga perekonna jaoks eraldi objekte.
Lugege selle filtri dokumentatsiooni, mida te tegelikult käitate, seejärel loetlege, millised tabelid on olemas ja millist teie muudatus puudutas. IPv4 tabeli reeglite loendamine vastab küsimusele, mida keegi ei esitanud. Seejärel loetlege, millised tabelid on olemas ja millist teie muudatus puudutas.
Tingimus teine: kus poliitika kehtib
Kolm kohta aetakse üksteisega segi: kuulaja, mis võtab tunneli vastu, tee, mis edastab liiklust edasi, ja tavaline liides, mida klient kasutab, kui tunnel voogu ei kanna. Lüüs võib seansi vastu võtta, lastes samal ajal kõik sellest edasi saadetu maha, ja see näeb välja nagu katkine tunnel, mitte filter. Kõrvaldage see segadus enne millegi kirjutamist, sest kolmel kohal on erinevad omanikud ja erinevad logid. Nende nimetamine muudatuse kirjes on see, mis hoiab paranduse langemast rikkest ühe kihi kaugemale.
Kirjutage üles, millist kolmest kohast teie reegel peaks juhtima. Kuulajat kaitsvad reegel ei kaitse edastatavat teed ja kumbki neist ei sulge kliendi otsest marsruuti. Pange tähele, kellele iga koht kuulub, sest vastus on enamikus organisatsioonides teine meeskond.
Tingimus kolmas: mida peaks IPv6 tegema
Otsustage, kas IPv6 liigub tunnelist läbi, blokeeritakse seni, kuni kaitse pole saadaval, või järgib dokumenteeritud erandit. Iga vastus annab erineva reeglistiku, ja küsimuse lahtiseks jätmine on see, kuidas klient, kellel on oma IPv6, jõuab tunnelist väljapoole sihtkohtadesse, kuhu ta jõuab selle sees IPv4 kaudu.
Öelge vastus valjusti enne reeglite kirjutamist. Blokeerimine on õigustatud valik tunnelile, mis IPv6 ei kanna, kui see on tahtlik ja testitud, mitte tühja tabeli juhuslik tulemus. Kõik dokumenteerimata otsustatakse uuesti selle poolt, kes järgmisena reegleid puudutab, ja tavaliselt kiirustades.
ICMPv6 on juhtimisliiklus
Naabrite avastamine ja tee tagasiside sõidavad mõlemad ICMPv6 peal, nii et IPv4 harjumusest kopeeritud pimesi mahaviskamine lõhub aadressimise ja suured ülekanded korraga. Ka pimesi lubamine ei ole vastus, sest see annab üle kanali, mida keegi ei jälgi.
Järgige filtreerimisjuhiseid oluliste sõnumitüüpide puhul ja keelduge ülejäänutest põhjust viidates. Viga, mida kõige sagedamini valesti diagnoositakse, on puuduv Packet Too Big sõnum, mis ilmneb ühendusena, mis avaneb ja seejärel takerdub.
Selle tõestamine, üks perekond korraga
Testige volitatud päringut iga perekonna kaudu eraldi, seejärel korrake pärast taasühendamist, kui poliitika peaks seansile vastu pidama. Test ainult IPv4 võrgus ei saa IPv6 marsruuti harjutada, seega ei ütle läbiminek teie sulgemisele kuuluva lekkimise kohta midagi. Jälgige testi ajal loendureid, sest reegel, mis kunagi ei vasta, ei tee seda, mida tema kommentaar väidab.
Muutke katse kohta üht piiratud reeglit ja hoidke eelmine konfiguratsioon käepärast. Kui poliitikat omab hallatav profiil, kaasake selle administraator enne kohalikku muutmist, sest järgmine kontroll kirjutab kohaliku paranduse üle ja taastab lekkimise.