Når IKEv2 returnerer TS_UNACCEPTABLE, samanlikn dei verkelege subneta
Ei selektoravvising er eit usemje om dekning mellom to sider. Snu dei lokale og fjerne etikettane, og samanlikn deretter dei eksakte områda kvar side føreslår.
Les TS_UNACCEPTABLE som usemje om dekning, ikkje som ein øydelagd profil. Gatewayen seier at dei to sidene ikkje klarte å bli samde om kva adresser denne tunnelen kan bera. IKE SA kan allereie vere oppe i det augeblikket, og difor kan ein klient sjå tilkopla ut utan nokon barn-SA bak seg. Når du rammar det inn slik, vert arbeidet mekanisk. Skriv ned dei tiltenkte prefiksa til begge sider, samanlikn dei i éi retning, og snevra inn til dei skjer kvarandre.
Skriv ned dei tiltenkte para fyrst
Før du rører konfigurasjonen, list opp fire verdiar: kjeldeområdet til initiatoren, målområdet hans og det same paret sett frå sida til responsøren. Noter òg adressefamilien til kvar av dei. Eit IPv4-område og eit IPv6-område er ulike selektortyrpar, og ingen av dei kan bret tast inn i nyttelasta til den andre.
Legg til kvar protokoll- eller portavgrensing som policyen ber. Ei regel som berre tillèt TCP 445 til ein filtenar, skildrar eit snevrare sett enn subnettet ho ligg i. Utelèt du det frå notata, vil forhandlingsresultatet sjå inkonsistent ut av grunnar du ikkje ser.
Snu etikettane før du samanliknar dei
Lokal og fjern er relative etikettar. Det lokale prefikset til klienten er det fjerne området til gatewayen, og det lokale området til gatewayen er det fjerne til klienten. Difor stemmer skjermbilete frå dei to endane aldri, og å samanlikne dei bokstaveleg er den vanlege måten å miste ein ettermiddag.
Ein responsør kan snevra inn eit tilbod til eit akseptabelt delsett i staden for å avvise det. Det utfallet er verre enn ein rein feil, fordi det verkar halvvegs. Be om 10.0.0.0/16 når policyen tillèt 10.0.5.0/24, og du kan enda med ein barn-SA som berre dekkjer det /24-et. Éin vert svarar, alt anna fell utanfor, og ingenting i klienten seier det. Les dei aksepterte selektorane i staden for dei førespurde før du konkluderer med at forhandlinga lukkast.
Road warrior-profilar som ber om ei standardrute landar her konstant. Ein gateway bygd for delt tilgang snevrar inn eit tilbod med fullt område til sine eigne subnett, og klienten må godta det innsnevra resultatet eller feile høgt.
Les avvisinga frå eitt forsøk
Samle begge loggane frå same tilkoplingsforsøk. Ein lagra profil viser kva du konfigurerte, ikkje kva som vart føreslått, og på strongSwan skriv swanctl --log ut den mottekne notifikasjonen saman med selektorane han bar.
Undersøk deretter kva som faktisk vart installert. swanctl --list-sas viser selektorane til barn-SA-en, og ip xfrm policy viser dei same områda som kjernepolicyoppføringar. Ein barn-SA i den lista med selektorar du ikkje hadde til hensikt, er ei innsnevringshending; ingen barn-SA pluss TS_UNACCEPTABLE i loggen er ei avvising.
Medan du er der, skil dei nære naboane. INVALID_SELECTORS klagar på ein selektor inne i ein etablert barn-SA, medan INTERNAL_ADDRESS_FAILURE tyder at responsøren ikkje kunne tildela ei virtuell adresse, noko som er eit poolproblem og ikkje eit dekningsproblem.
Sjekk kva som lydlaust krympar settet
Tre ting krympar eit selektorsett utan å seie noko. Policyen til responsøren er den fyrste, gjennom subnettlister, gruppereglar eller autorisasjon per brukar som reduserer tilbodet til eit delsett. Adressefamilien er den andre: ein dual-stack-klient føreslår ofte IPv6 ved sida av IPv4 og får avvising for område gatewayen aldri har konfigurert.
Protokoll- og portavgrensingar er den tredje. Der policyen berre tillèt TCP 445, kan ein barn-SA koma opp medan ICMP og UDP blir utanfor, og brukaren rapporterer ein øydelagd tunnel når éin protokoll var alt som nokon gong var tillate.
Difor kan utviding av adresser åleine ikkje reparere ein portavgrensa policy, og det er nettopp dette tilfellet som mest truleg overlever tre rundar med feilsøking uendra.
Prov dekninga med trafikk som passar
Etter at barn-SA-en er installert, send éin førespurnad som sikkert fell innanfor dei aksepterte områda. Fylg med på teljarane i staden for statusikonet: ip -s xfrm state og teljarane bak ip xfrm policy aukar når ein pakke blir matcha og verna. Eit bytetal som blir ståande på null etter ekte trafikk, tyder at kjernen aldri valde den policyen.
Den nullen er eit ruting- eller policyrekkjefølgjeproblem, ikkje eit kryptoproblem. Det ser òg identisk ut med ei selektoravvising frå plassen til brukaren, og difor er teljarane verd å samle før du opnar profilen på nytt. Teljarar som berre aukar i éi retning peikar i staden på returvegen.
Avslutt med å skrive det aksepterte paret inn i saka, ved sida av området som opphavleg vart førespurt. Hald valet så snevert som kravet, fordi å fjerne feilen ved å bytte ut eit privat område med alle adresser gir langt meir tilgang enn kontoen vart godkjend for.