Eén /23 in plaats van twee /24's: wat er in de onderhandeling verandert

Twee aangrenzende /24's vallen netjes samen in één /23, en dat keurige rekenwerk overtuigt mensen ervan dat de wijziging cosmetisch is. Het is rekenwerk over adressen, en de tunnel geeft om selectors, die een onderhandelingsaanbod zijn en geen beschrijving van een netwerk. De kortere regel kan hetzelfde verkeer beschermd laten, meer beschermen dan bedoeld, of de helft ervan niet dekken, afhankelijk van wat beide partijen bereid zijn te accepteren. Het geïnstalleerde resultaat lezen is de enige manier om te weten welk van die drie is gebeurd.

Drie feiten die mensen tot één samensmelten

De adressenset zegt welke hosts beschermd moeten worden. De groepering zegt hoe die adressen worden aangeboden: één selector of meerdere, in één associatie of meer. Het uitonderhandelde resultaat zegt wat beide partijen werkelijk hebben geïnstalleerd, en het kan smaller zijn dan elk van de eerste twee.

Schrijf ze afzonderlijk op in het wijzigingsrecord. Eén regel configuratie verbergt vaak drie verschillende antwoorden. Een reviewer die ze niet kan scheiden, kan de wijziging ook niet goedkeuren.

Wat de responder met jouw aggregatie mag doen

Een IKEv2-responder mag een aangeboden selectorpaar versmallen tot een subset die hij bereid is te accepteren, en hij mag het aanbod ronduit weigeren als er niets acceptabels bestaat. Hij kan ook aangeven dat extra verkeer een andere associatie nodig heeft in plaats van in deze te passen.

Een responder die niets accepteert, retourneert in plaats daarvan een fout, wat tenminste zegt dat het aanbod is geweigerd en niet stilzwijgend versmald.

Dat betekent dat een geslaagde uitwisseling bewijst dat de partijen het ergens over eens zijn, niet dat ze het over alles eens zijn wat je hebt opgesomd. Het eerste succesbericht is een startpunt om het resultaat te lezen, nooit een conclusie. De geaccepteerde subset kan kleiner zijn dan één /24, waardoor de geïnstalleerde set totaal niet op het aanbod lijkt.

Waar een samenvatting stilletjes een grens uitwist

Twee /24's kunnen verschillende serviceregels hebben: de ene staat misschien alleen een beheerprotocol toe, de andere een algemene toepassing. Een selector die beide adressen op IP-niveau dekt, behoudt die regels niet, en de samenvatting verplaatst de grens naar welke filtering dan ook achter de tunnel bestaat. Noteer de serviceregels per subnet voordat je aggregeert, anders vindt die vergelijking nooit plaats.

Protocol- en poortwaarden maken deel uit van een selector, geen optionele extra. Als het oorspronkelijke beleid ze beperkte, moet de aggregatie dezelfde beperking dragen, anders is de wijziging een rechtenwijziging in een routing-kostuum. Als de beperking de kern van het oorspronkelijke beleid was, houd die dan expliciet na de samenvatting en schrijf dat op in het record.

Het resultaat per prefix lezen

Kijk na de wijziging naar wat is geïnstalleerd in plaats van naar wat is geconfigureerd. Genereer dan een flow vanaf elke prefix in elke richting, en controleer de tellers die bij de associatie horen die hem afhandelt. Twee prefixen die verkeer op één associatie produceren zijn prima; twee prefixen waarvan er één niets produceert, dat is de vondst.

Doe dit met dezelfde applicatie die de gebruikers draaien. Een probe die op de gateway begint, test een ander pad dan een client erachter, en dat verschil is precies waar selectorfouten zich verschuilen. Een vlakke teller op een prefix dat druk zou moeten zijn, is sterker bewijs dan welke logregel dan ook, omdat hij afwezigheid meet.

De wijziging omkeerbaar maken

Laat het oorspronkelijke beleid in de configuratie staan tot het nieuwe is beproefd vanaf elke prefixcombinatie, en noteer in welke associatie elke flow terechtkwam. Als een partij associaties vervangt wanneer het aanbod verandert, moet de terugdraai het oude aanbod herstellen en niet slechts de oude adressen.

Stem af met de eigenaar van het andere uiteinde voordat het venster opengaat. Een samenvatting die de ene kant vanzelfsprekend vindt, kan voor de andere een onacceptabele groepering zijn, en dat tijdens de wijziging ontdekken is duur. Spreek de aangeboden groepering schriftelijk af en vergelijk die daarna met wat de uitwisseling installeert. Bewaar die afspraak in het wijzigingsticket, niet in een chatthread die volgende week verdwenen is.