En /23 i stället för två /24: vad som ändras i förhandlingen

Två intilliggande /24 smälter prydligt samman till en /23, och den prydliga aritmetiken övertygar folk om att ändringen är kosmetisk. Det är aritmetik om adresser, och tunneln bryr sig om selektorer, som är ett förhandlingserbjudande och inte en beskrivning av ett nät. Den kortare raden kan lämna samma trafik skyddad, skydda mer än avsett, eller inte täcka halva, beroende på vad de två parterna är beredda att acceptera. Att läsa det installerade resultatet är det enda sättet att veta vilket av de tre som hände.

Tre fakta som folk slår ihop till ett

Adressmängden säger vilka värdar som ska skyddas. Grupperingen säger hur dessa adresser erbjuds: en selektor eller flera, i en association eller flera. Det förhandlade resultatet säger vad de två parterna faktiskt installerade, och det kan vara snävare än vilken som helst av de två första.

Skriv dem var för sig i ändringsloggen. En rad konfiguration döljer ofta tre olika svar. En granskare som inte kan skilja dem kan inte heller godkänna ändringen.

Vad svararen får göra med ditt aggregat

En IKEv2-svarare får snäva in ett erbjudet selektorpar till en delmängd som den är beredd att acceptera, och den får avvisa erbjudandet helt om ingenting acceptabelt finns. Den kan också ange att ytterligare trafik behöver en annan association i stället för att rymmas i denna.

En svarare som inte accepterar något returnerar i stället ett fel, vilket åtminstone säger att erbjudandet avvisades och inte tyst snävades in.

Det betyder att ett lyckat utbyte bevisar att parterna kom överens om något, inte att de kom överens om allt du listade. Det första framgångsmeddelandet är en startpunkt för att läsa resultatet, aldrig en slutsats. Den accepterade delmängden kan vara mindre än en enda /24, vilket gör den installerade mängden helt olik erbjudandet.

Där en sammanfattning tyst suddar en gräns

Två /24 kan ha olika tjänsteregler: den ena kanske bara tillåter ett hanteringsprotokoll, den andra en allmän applikation. En selektor som täcker båda adresserna på IP-nivå bevarar inte de reglerna, och sammanfattningen flyttar gränsen in i vilken filtrering som än finns bakom tunneln. Lista tjänstereglerna per subnät innan du aggregerar, annars sker den jämförelsen aldrig.

Protokoll- och portvärden är en del av en selektor, inte ett valfritt tillägg. Om den ursprungliga policyn begränsade dem måste aggregatet bära samma begränsning, annars är ändringen en behörighetsändring i routningskostym. Om begränsningen var poängen med den ursprungliga policyn, håll den explicit efter sammanfattningen och skriv det i loggen.

Läsa resultatet per prefix

Efter ändringen, titta på vad som installerades i stället för vad som konfigurerades. Generera sedan ett flöde från varje prefix i varje riktning, och kontrollera räknarna som hör till associationen som hanterar det. Två prefix som ger trafik på en association är okej; två prefix där ett inte ger något är fyndet.

Gör detta med samma applikation som användarna kör. En sond som startar på gatewayen testar en annan väg än en klient bakom den, och skillnaden är precis där selektorbuggar gömmer sig. En plan räknare på ett prefix som borde vara upptaget är starkare bevis än någon loggrada, eftersom den mäter frånvaro.

Att göra ändringen reversibel

Behåll den ursprungliga policyn i konfigurationen tills den nya har prövats från varje prefixkombination, och notera vilken association varje flöde hamnade i. Om en part byter associationer när erbjudandet ändras måste återställningen återställa det gamla erbjudandet och inte bara de gamla adresserna.

Samordna med ägaren av den andra änden innan fönstret öppnas. En sammanfattning som ena sidan tycker är självklar kan vara en oacceptabel gruppering på den andra, och att upptäcka det under ändringen är dyrt. Kom överens om den erbjudna grupperingen skriftligt och jämför den sedan med vad utbytet installerar. Förvara överenskommelsen i ändringsärendet, inte i en chattråd som försvinner nästa vecka.