Éin /23 i staden for to /24: kva som endrar seg i forhandlinga

To tilstøytande /24 smeltar pent saman til éin /23, og den ryddige aritmetikken overtyder folk om at endringa er kosmetisk. Det er aritmetikk om adresser, og tunnelen bryr seg om selektorar, som er eit forhandlingstilbod og ikkje ei skildring av eit nettverk. Den kortare lina kan la den same trafikken vere verna, verne meir enn tenkt, eller ikkje dekkje halvparten av han, avhengig av kva dei to partane er viljuge til å godta. Å lese det installerte resultatet er den einaste måten å vite kva av dei tre som skjedde.

Tre faktum folk slår saman til eitt

Adressemengda seier kva vertar som skal vernast. Grupperinga seier korleis desse adressene vert tilbodne: éin selektor eller fleire, i éin assosiasjon eller fleire. Det forhandla resultatet seier kva dei to partane faktisk installerte, og det kan vere trongare enn kvar av dei to første.

Skriv dei kvar for seg i endringsloggen. Éi line med konfigurasjon løyner ofte tre ulike svar. Ein gjennomgang som ikkje kan skilje dei, kan heller ikkje godkjenne endringa.

Kva respondenten har lov til å gjere med aggregatet ditt

Ein IKEv2-respondent kan snevre inn eit tilbode selektorpar til eit delsett han er viljug til å godta, og han kan avslå tilbodet heilt om ingenting akseptabelt finst. Han kan òg seie at ekstra trafikk treng ein annan assosiasjon i staden for å passe inn i denne.

Ein respondent som ikkje godtek noko, returnerer i staden ein feil, som i det minste seier at tilbodet vart avslege og ikkje stille innsnevra.

Det tyder at ei vellukka utveksling provar at partane vart samde om noko, ikkje at dei vart samde om alt du lista opp. Den første suksessmeldinga er eit utgangspunkt for å lese resultatet, aldri ein konklusjon. Det godtekne delsettet kan vere mindre enn éin /24, noko som gjer det installerte settet heilt ulikt tilbodet.

Kor eit samandrag stille slettar ei grense

To /24 kan ha ulike tenestereglar: éin kan tillate berre ein administrasjonsprotokoll, den andre ein generell applikasjon. Ein selektor som dekkjer begge adressene på IP-nivå, bevarer ikkje desse reglane, og samandraget flyttar grensa inn i den filtreringa som finst bak tunnelen. List tenestereglane per subnett før du aggregerer, elles skjer aldri den samanlikninga.

Protokoll- og portverdiar er ein del av ein selektor, ikkje eit valfritt tillegg. Viss den opphavlege policyen avgrensa dei, må aggregatet bere den same avgrensinga, elles er endringa ei løyveendring i rutekostyme. Viss avgrensinga var poenget med den opphavlege policyen, hald ho eksplisitt etter samandraget og skriv det i loggen.

Lesing av resultatet per prefiks

Etter endringa, sjå på det som vart installert i staden for det som vart konfigurert. Generer så ein flyt frå kvart prefiks i kvar retning, og sjekk teljarane som høyrer til assosiasjonen som handterer han. To prefiks som gir trafikk på éin assosiasjon er greitt; to prefiks der éin ikkje gir noko, er funnet.

Gjer dette med same applikasjonen som brukarane køyrer. Ein probe som startar på gatewayen testar ein annan veg enn ein klient bak han, og skilnaden er nettopp der selektorbugane gøymer seg. Ein flat teljar på eit prefiks som burde vere oppteke er sterkare prov enn noka loggline, fordi han måler fråvær.

Å gjere endringa reversibel

Hald den opphavlege policyen i konfigurasjonen til den nye er prøvd frå kvar prefikskombinasjon, og noter kva assosiasjon kvar flyt hamna i. Viss ein part byter assosiasjonar når tilbodet endrar seg, må tilbakerullinga gjenopprette det gamle tilbodet og ikkje berre dei gamle adressene.

Koordiner med eigaren av den andre enden før vindauget opnar. Eit samandrag som éi side synest er opplagt, kan vere ei uakseptabel gruppering på den andre, og å finne det ut under endringa er dyrt. Bli samde om den tilbodne grupperinga skriftleg, og samanlikn ho deretter med det utvekslinga installerer. Oppbevar avtalen i endringssaka, ikkje i ein chat som forsvinn neste veke.