Een /23 in plaas van twee /24's: wat in die onderhandeling verander

Twee aangrensende /24's val netjies in een /23 saam, en daardie oulike rekenkunde oortuig mense dat die verandering net kosmeties is. Dit is rekenkunde oor adresse, en die tonnel gee om selektore, wat 'n onderhandelingsaanbod is eerder as 'n beskrywing van 'n netwerk. Die korter reël kan dieselfde verkeer beskerm laat bly, meer beskerm as wat bedoel is, of helfte daarvan nie dek nie, afhangend van wat die twee portuurs bereid is om te aanvaar. Om die geïnstalleerde resultaat te lees is die enigste manier om te weet watter van dié drie gebeur het.

Drie feite wat mense in een saamsmelt

Die adresversameling sê watter hosts beskerm moet word. Die groepering sê hoe daardie adresse aangebied word, een selektor of verskeie, in een assosiasie of meer. Die onderhandelde resultaat sê wat die twee portuurs werklik geïnstalleer het, en dit kan smaller wees as enigeen van die eerste twee.

Skryf hulle afsonderlik in die veranderingsrekord. 'n Enkele reël konfigurasie verberg dikwels drie verskillende antwoorde. 'n Resensent wat hulle nie kan skei nie, kan die verandering ook nie goedkeur nie.

Wat die responder met jou samevatting mag doen

'n IKEv2-responder mag 'n aangebode selektorpaar vernou tot 'n subset wat hy bereid is om te aanvaar, en hy mag die aanbod heeltemal weier as niks aanvaarbaar bestaan nie. Hy kan ook aandui dat bykomende verkeer 'n ander assosiasie nodig het eerder as om in hierdie een te pas.

'n Responder wat niks aanvaar nie, gee eerder 'n fout terug, wat ten minste sê die aanbod is verwerp eerder as stilweg vernou.

Dit beteken 'n suksesvolle uitruiling bewys die portuurs het oor iets ooreengekom, nie dat hulle oor alles wat jy gelys het ooreengekom het nie. Die aanvanklike suksesboodskap is 'n beginpunt om die resultaat te lees, nooit 'n gevolgtrekking nie. Die aanvaarde subset kan kleiner wees as 'n enkele /24, wat die geïnstalleerde stel heeltemal anders laat lyk as die aanbod.

Waar 'n samevatting stilweg 'n grens uitwis

Twee /24's kan verskillende diensreëls hê: een mag net 'n bestuursprotokol toelaat, die ander 'n algemene toepassing. 'n Selektor wat beide adresse op die IP-vlak dek, bewaar nie daardie reëls nie, en die samevatting skuif die grens na watter filtering ook al agter die tonnel bestaan. Lys die diensreëls per subnet voordat jy saamvat, anders gebeur daardie vergelyking nooit.

Protokol- en poortwaardes is deel van 'n selektor, nie 'n opsionele bykomstigheid nie. As die oorspronklike beleid hulle beperk het, moet die samevatting dieselfde beperking dra, anders is die verandering 'n toestemmingsverandering in 'n roeteringskostuum. As die beperking die punt van die oorspronklike beleid was, hou dit eksplisiet ná die samevatting en sê so in die rekord.

Om die resultaat per prefiks te lees

Kyk ná die verandering na wat geïnstalleer is eerder as na wat gekonfigureer is. Genereer dan 'n vloei vanaf elke prefiks in elke rigting, en kyk na die tellers wat aan die assosiasie behoort wat dit hanteer. Twee prefikse wat verkeer op een assosiasie produseer is reg; twee prefikse waar een niks produseer nie is die bevinding.

Doen dit met dieselfde toepassing wat die gebruikers gebruik. 'n Peiling wat op die gateway ontstaan, toets 'n ander pad as 'n kliënt agter dit, en die verskil is presies waar selektorfoute skuil. 'n Plat teller op 'n prefiks wat besig behoort te wees, is sterker bewyse as enige logreël, want dit meet afwesigheid.

Om die verandering omkeerbaar te maak

Hou die oorspronklike beleid in die konfigurasie totdat die nuwe een uit elke prefikskombinasie geoefen is, en let op watter assosiasie elke vloei beland het. As 'n portuur assosiasies vervang wanneer die aanbod verander, moet die terugrol die ou aanbod herstel en nie net die ou adresse nie.

Koördineer met die eienaar van die ander eindpunt voordat die venster oopgaan. 'n Samevatting wat die een kant as vanselfsprekend beskou, kan op die ander 'n onaanvaarbare groepering wees, en om dit tydens die verandering uit te vind is duur. Kom skriftelik oor die aangebode groepering ooreen en vergelyk dit dan met wat die uitruiling installeer. Hou daardie ooreenkoms in die veranderingsticket, nie in 'n gespreksdraad wat volgende week verdwyn nie.