Én /23 i stedet for to /24: hva endres i forhandlingen

To tilstøtende /24 smelter pent sammen til én /23, og den ryddige aritmetikken overbeviser folk om at endringen er kosmetisk. Det er aritmetikk om adresser, og tunnelen bryr seg om selektorer, som er et forhandlingstilbud og ikke en beskrivelse av et nettverk. Den kortere linjen kan la den samme trafikken forbli beskyttet, beskytte mer enn tiltenkt, eller ikke dekke halvparten av den, avhengig av hva de to partene er villige til å godta. Å lese det installerte resultatet er den eneste måten å vite hvilken av de tre som skjedde.

Tre fakta folk slår sammen til ett

Adressesettet sier hvilke verter som skal beskyttes. Grupperingen sier hvordan disse adressene tilbys: én selektor eller flere, i én assosiasjon eller flere. Det forhandlede resultatet sier hva de to partene faktisk installerte, og det kan være snevrere enn hvilket som helst av de to første.

Skriv dem hver for seg i endringsloggen. Én linje med konfigurasjon skjuler ofte tre forskjellige svar. En gjennomgang som ikke kan skille dem, kan heller ikke godkjenne endringen.

Hva respondenten har lov til å gjøre med aggregatet ditt

En IKEv2-respondent kan innsnevre et tilbudt selektorpar til et delsett den er villig til å godta, og den kan avslå tilbudet helt hvis ingenting akseptabelt finnes. Den kan også indikere at ekstra trafikk trenger en annen assosiasjon i stedet for å passe inn i denne.

En respondent som ikke godtar noe, returnerer i stedet en feil, som i det minste sier at tilbudet ble avslått og ikke stille innsnevret.

Det betyr at en vellykket utveksling beviser at partene ble enige om noe, ikke at de ble enige om alt du listet opp. Den første suksessmeldingen er et utgangspunkt for å lese resultatet, aldri en konklusjon. Det aksepterte delsettet kan være mindre enn én /24, noe som gjør det installerte settet helt ulikt tilbudet.

Hvor en oppsummering stille sletter en grense

To /24 kan ha ulike tjenesteregler: én kan tillate bare en administrasjonsprotokoll, den andre en generell applikasjon. En selektor som dekker begge adressene på IP-nivå bevarer ikke disse reglene, og oppsummeringen flytter grensen inn i den filtreringen som finnes bak tunnelen. List tjenestereglene per subnett før du aggregerer, ellers skjer aldri den sammenligningen.

Protokoll- og portverdier er en del av en selektor, ikke et valgfritt tillegg. Hvis den opprinnelige policyen begrenset dem, må aggregatet bære samme begrensning, ellers er endringen en tillatelsesendring i rutingskostyme. Hvis begrensningen var poenget med den opprinnelige policyen, hold den eksplisitt etter oppsummeringen og si det i loggen.

Lesing av resultatet per prefiks

Etter endringen, se på det som ble installert i stedet for det som ble konfigurert. Generer deretter en flyt fra hvert prefiks i hver retning, og sjekk tellerne som hører til assosiasjonen som håndterer den. To prefikser som gir trafikk på én assosiasjon er greit; to prefikser der én ikke gir noe, er funnet.

Gjør dette med samme applikasjon som brukerne kjører. En probe som starter på gatewayen tester en annen vei enn en klient bak den, og forskjellen er nettopp der selektorbugs gjemmer seg. En flat teller på et prefiks som burde være opptatt er sterkere bevis enn noen logglinje, fordi den måler fravær.

Å gjøre endringen reversibel

Behold den opprinnelige policyen i konfigurasjonen til den nye er prøvd fra hver prefikskombinasjon, og noter hvilken assosiasjon hver flyt havnet i. Hvis en part bytter assosiasjoner når tilbudet endres, må tilbakerullingen gjenopprette det gamle tilbudet og ikke bare de gamle adressene.

Koordiner med eieren av den andre enden før vinduet åpnes. En oppsummering som én side synes er opplagt, kan være en uakseptabel gruppering på den andre, og å finne det ut under endringen er dyrt. Bli enige om den tilbudte grupperingen skriftlig, og sammenlign den deretter med det utvekslingen installerer. Oppbevar avtalen i endringssaken, ikke i en chat som forsvinner neste uke.