När IKEv2 returnerar TS_UNACCEPTABLE, jämför de riktiga subnäten

Läs TS_UNACCEPTABLE som en oenighet om täckning, inte som en skadad profil. Gatewayen säger att de två parterna inte kunde enas om vilka adresser den här tunneln får bära. IKE SA kan redan vara uppe i det ögonblicket, och därför kan en klient se ansluten ut utan någon barn-SA bakom sig. När du ramar in det så blir arbetet mekaniskt. Skriv ner båda sidornas avsedda prefix, jämför dem i en riktning och snäva in tills de skär varandra.

Skriv ner de avsedda paren först

Innan du rör konfigurationen, lista fyra värden: initiativtagarens källområde, dess målområde och samma par sett från svararens sida. Notera också adressfamiljen för var och en. Ett IPv4-område och ett IPv6-område är olika typer av selektorer, och ingen av dem kan vikas in i den andras nyttolast.

Lägg till varje protokoll- eller portbegränsning som policyn bär. En regel som bara tillåter TCP 445 till en filserver beskriver en snävare mängd än subnätet den ligger i. Utelämnar du det från dina anteckningar kommer förhandlingsresultatet att se inkonsekvent ut av skäl du inte ser.

Vänd på beteckningarna innan du jämför dem

Lokalt och fjärr är relativa beteckningar. Klientens lokala prefix är gatewayens fjärrområde, och gatewayens lokala område är klientens fjärrområde. Därför stämmer skärmbilder från de två ändarna aldrig överens, och att jämföra dem bokstavligt är det vanliga sättet att förlora en eftermiddag.

En svarare kan snäva in ett erbjudande till en acceptabel delmängd i stället för att avvisa det. Det utfallet är värre än ett rent misslyckande, eftersom det fungerar halvt. Begär 10.0.0.0/16 när policyn tillåter 10.0.5.0/24, och du kan hamna med en barn-SA som bara täcker det /24. En värd svarar, allt annat faller utanför, och ingenting i klienten säger det. Läs de accepterade selektorerna i stället för de begärda innan du drar slutsatsen att förhandlingen lyckades.

Road warrior-profiler som begär en standardruta landar här ständigt. En gateway byggd för delad åtkomst snävar in ett erbjudande med fullt område till sina egna subnät, och klienten måste acceptera det insnävade resultatet eller misslyckas högljutt.

Läs avvisningen från ett enda försök

Samla båda loggarna från samma anslutningsförsök. En sparad profil visar vad du konfigurerade, inte vad som föreslogs, och på strongSwan skriver swanctl --log ut det mottagna meddelandet tillsammans med de selektorer den bar.

Undersök sedan vad som faktiskt installerades. swanctl --list-sas visar barn-SA:ns selektorer, och ip xfrm policy visar samma områden som kärnpolicyposter. En barn-SA i den listan med selektorer du inte avsåg är en insnävningshändelse; ingen barn-SA plus TS_UNACCEPTABLE i loggen är en avvisning.

Medan du är där, skilj de nära grannarna. INVALID_SELECTORS klagar på en selektor inne i en etablerad barn-SA, medan INTERNAL_ADDRESS_FAILURE betyder att svararen inte kunde tilldela en virtuell adress, vilket är ett poolproblem och inte ett täckningsproblem.

Kontrollera vad som tyst krymper mängden

Tre saker krymper en selektormängd utan att säga något. Svararens policy är den första, genom subnätlistor, gruppregler eller behörighet per användare som minskar erbjudandet till en delmängd. Adressfamiljen är den andra: en dual-stack-klient föreslår ofta IPv6 bredvid IPv4 och får en avvisning för områden som gatewayen aldrig konfigurerade.

Protokoll- och portbegränsningar är den tredje. Där policyn bara tillåter TCP 445 kan en barn-SA komma upp medan ICMP och UDP blir utanför, och användaren rapporterar en trasig tunnel när ett enda protokoll var allt som någonsin tilläts.

Därför kan enbart utökning av adresser inte reparera en portbegränsad policy, och det är just det fallet som mest sannolikt överlever tre rundor av felsökning oförändrat.

Bevisa täckningen med trafik som passar

När barn-SA:n är installerad, skicka en förfrågan som säkert faller inom de accepterade områdena. Titta på räknarna i stället för statusikonen: ip -s xfrm state och räknarna bakom ip xfrm policy ökar när ett paket matchas och skyddas. Ett bytantal som stannar på noll efter verklig trafik betyder att kärnan aldrig valde den policyn.

Den nollan är ett routing- eller policyordningsproblem, inte ett kryptoproblem. Det ser också identiskt ut med en selektoravvisning från användarens plats, och därför är räknarna värda att samla in innan du öppnar profilen igen. Räknare som bara stiger i en riktning pekar i stället på returvägen.

Avsluta med att skriva det accepterade paret i ärendet, bredvid det område som ursprungligen begärdes. Håll valet så snävt som kravet, eftersom att rensa felet genom att ersätta ett privat område med alla adresser ger långt mer åtkomst än kontot godkändes för.