Når IKEv2 returnerer TS_UNACCEPTABLE, sammenlign de virkelige subnettene

Les TS_UNACCEPTABLE som en uenighet om dekning, ikke som en ødelagt profil. Gatewayen sier at de to partene ikke klarte å bli enige om hvilke adresser denne tunnelen kan bære. IKE SA kan allerede være oppe i det øyeblikket, og derfor kan en klient se tilkoblet ut uten noen barn-SA bak seg. Når du rammer det inn slik, blir arbeidet mekanisk. Skriv ned begge parters tiltenkte prefikser, sammenlign dem i én retning, og snevre inn til de skjærer hverandre.

Skriv ned de tiltenkte parene først

Før du rører konfigurasjonen, list opp fire verdier: initiatorens kildeområde, dets målområde og det samme paret sett fra responderens side. Noter også adressefamilien til hver av dem. Et IPv4-område og et IPv6-område er forskjellige selektortyper, og ingen av dem kan brettes inn i den andres nyttelast.

Legg til enhver protokoll- eller portbegrensning som policyen bærer. En regel som bare tillater TCP 445 til en filserver, beskriver et snevrere sett enn subnettet den ligger i. Utelater du det fra notatene, vil forhandlingsresultatet se inkonsistent ut av grunner du ikke ser.

Snu etikettene før du sammenligner dem

Lokal og fjern er relative etiketter. Klientens lokale prefiks er gatewayens fjerne område, og gatewayens lokale område er klientens fjerne. Derfor stemmer skjermbilder fra de to endene aldri overens, og å sammenligne dem bokstavelig er den vanlige måten å miste en ettermiddag.

En responder kan snevre inn et tilbud til et akseptabelt delsett i stedet for å avvise det. Det utfallet er verre enn en ren feil, fordi det virker halvveis. Be om 10.0.0.0/16 når policyen tillater 10.0.5.0/24, og du kan ende med en barn-SA som bare dekker det /24-et. Én vert svarer, alt annet faller utenfor, og ingenting i klienten sier det. Les de aksepterte selektorene i stedet for de forespurte før du konkluderer med at forhandlingen lyktes.

Road warrior-profiler som ber om en standardrute lander her konstant. En gateway bygget for delt tilgang snevrer inn et tilbud med fullt område til sine egne subnett, og klienten må godta det innsnevrede resultatet eller feile høylytt.

Les avvisningen fra ett forsøk

Samle begge loggene fra samme tilkoblingsforsøk. En lagret profil viser hva du konfigurerte, ikke hva som ble foreslått, og på strongSwan skriver swanctl --log ut den mottatte notifikasjonen sammen med selektorene den bar.

Undersøk deretter hva som faktisk ble installert. swanctl --list-sas viser barn-SA-ens selektorer, og ip xfrm policy viser de samme områdene som kjernepolicyoppføringer. En barn-SA i den listen med selektorer du ikke hadde til hensikt, er en innsnevringshendelse; ingen barn-SA pluss TS_UNACCEPTABLE i loggen er en avvisning.

Mens du er der, skill de nære naboene. INVALID_SELECTORS klager på en selektor inne i en etablert barn-SA, mens INTERNAL_ADDRESS_FAILURE betyr at responderen ikke kunne tildele en virtuell adresse, noe som er et poolproblem og ikke et dekningsproblem.

Sjekk hva som lydløst krymper settet

Tre ting krymper et selektorsett uten å si noe. Responderens policy er den første, gjennom subnettlister, grupperegler eller autorisasjon per bruker som reduserer tilbudet til et delsett. Adressefamilien er den andre: en dual-stack-klient foreslår ofte IPv6 ved siden av IPv4 og får avvisning for områder gatewayen aldri har konfigurert.

Protokoll- og portbegrensninger er den tredje. Der policyen bare tillater TCP 445, kan en barn-SA komme opp mens ICMP og UDP blir utenfor, og brukeren rapporterer en ødelagt tunnel når én protokoll var alt som noen gang var tillatt.

Derfor kan utvidelse av adresser alene ikke reparere en portbegrenset policy, og det er nettopp dette tilfellet som mest sannsynlig overlever tre runder med feilsøking uendret.

Bevis dekningen med trafikk som passer

Etter at barn-SA-en er installert, send én forespørsel som sikkert faller innenfor de aksepterte områdene. Følg med på tellerne i stedet for statusikonet: ip -s xfrm state og tellerne bak ip xfrm policy øker når en pakke matches og beskyttes. Et bytetall som blir stående på null etter ekte trafikk, betyr at kjernen aldri valgte den policyen.

Den nullen er et ruting- eller policyrekkefølgeproblem, ikke et kryptoproblem. Det ser også identisk ut med en selektoravvisning fra brukerens plass, og derfor er tellerne verdt å samle før du åpner profilen på nytt. Tellere som bare øker i én retning peker i stedet på returveien.

Avslutt med å skrive det aksepterte paret inn i saken, ved siden av området som opprinnelig ble forespurt. Hold valget så snevert som kravet, fordi å fjerne feilen ved å erstatte et privat område med alle adresser gir langt mer tilgang enn kontoen ble godkjent for.