Wanneer IKEv2 TS_UNACCEPTABLE teruggeeft, vergelijk de echte subnetten

Lees TS_UNACCEPTABLE als een onenigheid over dekking, niet als een beschadigd profiel. De gateway zegt dat de twee peers het niet eens konden worden over welke adressen deze tunnel mag dragen. De IKE SA kan op dat moment al staan, waardoor een client verbonden kan lijken zonder enige child-SA erachter. Als je het zo kadert, wordt het werk mechanisch. Schrijf de bedoelde prefixen van beide kanten op, vergelijk ze in één richting en vernauw tot ze elkaar snijden.

Schrijf eerst de bedoelde paren op

Voordat je de configuratie aanraakt, noteer vier waarden: het bronbereik van de initiator, zijn bestemmingsbereik en hetzelfde paar gezien vanaf de responder. Noteer ook de adresfamilie van elk. Een IPv4-bereik en een IPv6-bereik zijn verschillende selectortypen, en geen van beide kan in de payload van de andere worden gevouwen.

Voeg elke protocol- of poortbeperking toe die het beleid draagt. Een regel die alleen TCP 445 naar een bestandsserver toestaat, beschrijft een smaller set dan het subnet waarin die staat. Laat je dat weg uit je notities, dan ziet het onderhandelingsresultaat er inconsistent uit om redenen die je niet ziet.

Draai de labels om voordat je ze vergelijkt

Lokaal en remote zijn relatieve labels. Het lokale prefix van de client is het remote bereik van de gateway, en het lokale bereik van de gateway is dat van de client. Daarom kloppen schermafbeeldingen van beide uiteinden nooit, en ze letterlijk vergelijken is de gebruikelijke manier om een middag te verliezen.

Een responder kan een aanbod vernauwen tot een aanvaardbare deelverzameling in plaats van het af te wijzen. Dat resultaat is slechter dan een schone mislukking, omdat het half werkt. Vraag 10.0.0.0/16 aan terwijl het beleid 10.0.5.0/24 toestaat, en je kunt eindigen met een child-SA die alleen dat /24 dekt. Eén host antwoordt, al het andere valt buiten, en niets in de client zegt dat. Lees de geaccepteerde selectors in plaats van de gevraagde voordat je concludeert dat de onderhandeling is geslaagd.

Road-warriorprofielen die een standaardroute vragen, landen hier voortdurend. Een gateway gebouwd voor gesplitste toegang vernauwt een aanbod met volledig bereik tot zijn eigen subnetten, en de client moet het vernauwde resultaat accepteren of luid falen.

Lees de afwijzing uit één poging

Verzamel beide logs uit dezelfde verbindingspoging. Een opgeslagen profiel toont wat je hebt geconfigureerd, niet wat is voorgesteld, en op strongSwan drukt swanctl --log de ontvangen notificatie af samen met de selectors die zij droeg.

Inspecteer daarna wat er werkelijk is geïnstalleerd. swanctl --list-sas toont de selectors van de child-SA, en ip xfrm policy toont dezelfde bereiken als kernelbeleidsregels. Een child-SA in die lijst met selectors die je niet bedoelde is een vernauwingsgebeurtenis; geen child-SA plus TS_UNACCEPTABLE in het log is een weigering.

Scheid de nabije buren terwijl je daar bent. INVALID_SELECTORS klaagt over een selector binnen een gevestigde child-SA, terwijl INTERNAL_ADDRESS_FAILURE betekent dat de responder geen virtueel adres kon toewijzen, wat een poolprobleem is en geen dekkingsprobleem.

Controleer wat de set stil verkleint

Drie dingen verkleinen een selectorset zonder iets te zeggen. Responderbeleid is het eerste, via subnetlijsten, groepsregels of autorisatie per gebruiker die het aanbod tot een deelverzameling terugbrengen. Adresfamilie is het tweede: een dual-stackclient stelt vaak IPv6 naast IPv4 voor en krijgt een afwijzing voor bereiken die de gateway nooit heeft geconfigureerd.

Protocol- en poortbeperkingen zijn het derde. Waar het beleid alleen TCP 445 toestaat, kan een child-SA omhoog komen terwijl ICMP en UDP erbuiten blijven, en de gebruiker meldt een kapotte tunnel terwijl één protocol alles was wat ooit was toegestaan.

Daarom kan het verbreden van adressen alleen een poortbeperkt beleid niet herstellen, en dat is precies het geval dat drie rondes probleemoplossing het waarschijnlijkst onveranderd overleeft.

Bewijs dekking met verkeer dat past

Nadat de child-SA is geïnstalleerd, stuur één verzoek dat zeker binnen de geaccepteerde bereiken valt. Kijk naar de tellers in plaats van het statuspictogram: ip -s xfrm state en de tellers achter ip xfrm policy lopen op wanneer een pakket wordt gematcht en beschermd. Een bytetelling die na echt verkeer op nul blijft, betekent dat de kernel dat beleid nooit heeft geselecteerd.

Die nul is een routerings- of beleidsvolgordeprobleem, geen cryptoprobleem. Het ziet er vanaf de stoel van de gebruiker ook identiek uit aan een selectorafwijzing, en daarom is het de moeite waard de tellers te verzamelen voordat je het profiel opnieuw opent. Tellers die maar in één richting stijgen, wijzen juist op de retourweg.

Sluit af door het geaccepteerde paar in de ticket te schrijven, naast het bereik dat oorspronkelijk was aangevraagd. Houd de selectie zo smal als de eis, want de fout wissen door een particulier bereik te vervangen door alle adressen geeft veel meer toegang dan voor het account was goedgekeurd.