Vijf adresrollen in een IPsec-profiel, en welke ervan onjuist is

Vijf verschillende taken krijgen een adres in een typische verbindingsdefinitie, en ze hoeven het niet met elkaar eens te zijn. Beheerders lopen vast omdat een verstandig instinct, alle velden naar dezelfde host laten wijzen, voor minstens drie ervan onjuist is. De uitweg is eerst het symptoom benoemen en dan kijken naar het ene of de twee velden die het kunnen veroorzaken.

De vijf taken, in de volgorde waarin ze ertoe doen

Het transport-eindpunt is waar de IKE-uitwisseling wordt afgeleverd. De geauthenticeerde identiteit is de naam die elke kant bewijst, en die wordt getoetst aan beleid, niet aan een routingtabel. De beschermde subnetten zijn de selectors die bepalen welk intern verkeer bij de tunnel hoort. Dan is er de bron die wordt gebruikt wanneer de gateway zelf een gesprek begint, en ten slotte de volgende hop van de onderlaag om de peer te bereiken.

Deelnemerslabels zoals left en right zijn conventies voor twee kanten van een verbinding, geen synoniemen voor lokaal en extern. Lees de handleiding van de daadwerkelijk geïnstalleerde implementatie voordat je aanneemt dat een sleutel betekent wat een ander product ermee bedoelde.

Beslissing één: er komt niets tot stand

Wanneer er helemaal geen uitwisseling in de logboeken verschijnt, is het eindpunt de eerste verdachte: een verkeerd adres, een gefilterd pad of een interface waarop de daemon niet luistert. Ga pas naar de identiteitsvelden zodra een handdruk zichtbaar is, want identiteit wordt binnen de uitwisseling beoordeeld, niet ervoor. Een gefilterd pad en een verkeerd adres zien er vanaf de client identiek uit, dus controleer de luisterende kant voordat je iets bewerkt. Bevestig dat de daemon aan de interface is gebonden die je verwacht, want een dienst die op één adres luistert ziet er precies zo uit als een geblokkeerd pad.

Een openbaar adres dat via vertaling wordt waargenomen is niet hetzelfde als de identiteit die een peer bewijst. Een adres wijzigen om het te laten kloppen met wat een packet capture aan de verre kant laat zien is een veelvoorkomende en onjuiste correctie.

Beslissing twee: de tunnel staat en het verkeer sterft

Selectors bepalen wat de tunnel binnenkomt, en een mismatch hier levert een verbinding op die met succes onderhandelt terwijl de toepassing nog steeds faalt. De verre kant moet jouw beschermde bereik als zijn externe bereik benoemen, en daar kruipen precies omgekeerde waarden naar binnen.

Lees beide configuraties naast elkaar voordat je bewerkt. Het lokale bereik op de ene host is het externe bereik op de andere, en één verwisseld paar verklaart een tunnel die niets vervoert. Vernauw het paar voordat je de sleutels aanraakt: één subnet binnen de tunnel en één erbuiten vertellen je of de selector of de routing schuldig is.

Beslissing drie: alleen het eigen verkeer van de gateway faalt

Verkeer dat voor clients wordt doorgestuurd kan perfect werken terwijl een verzoek dat de gateway zelf begint faalt, omdat die stroom geen clientbron heeft om te erven. De instelling voor voorkeursbron bestaat precies voor dit geval, en het is geen bronvertaling: ze kiest een bronadres in plaats van er een te herschrijven.

Een toepassing die expliciet een ander adres bindt kan de voorkeur overrulen, dus bevestig de werkelijke bron van het pakket voordat je concludeert dat de instelling wordt genegeerd. Neem op op de eigen interface van de gateway in plaats van de bedoeling van de configuratie te vertrouwen.

De volgende hop is een lokale instructie

De volgende hop van de onderlaag vertelt deze host hoe de peer te bereiken, en de verre kant heeft dezelfde waarde niet nodig. Het als een gedeelde instelling behandelen, of een standaardgateway hardcoderen, breekt op het moment dat de route verandert of een tweede pad verschijnt.

Sommige implementaties bieden hier speciale waarden. Wat de handleiding voor de geïnstalleerde versie vermeldt is het enige veilige antwoord, en de lokale routingtabel is het bewijs dat het werkte. Wanneer een peer op naam bereikbaar is maar niet op adres, is die mismatch de bevinding, geen detail om omheen te werken.

Lees het profiel vanaf beide kanten

De rollen op papier omdraaien is de snelste beoordeling die er is: wissel de beschermde bereiken om, houd de eigen volgende hop van elke kant en de eigen identiteit van elke kant. Alles wat de omwisseling niet overleeft is waarschijnlijk aan de verkeerde taak toegewezen.

Test daarna één stroom per rol: bereikbaarheid tussen peers, een interne clientstroom en een verzoek dat van de gateway uitgaat. Drie tests vertellen je welke taak verkeerd is toegewezen zonder de configuratie opnieuw te openen. Voeg het resultaat toe aan de ticket naast het veld dat je hebt gewijzigd, want de volgende engineer treft hetzelfde profiel.