Kiam IKEv2 redonas TS_UNACCEPTABLE, komparu la realajn subretojn
Selektila rifuzo estas malkonsento pri kovrado inter du partneroj. Inversigu la lokajn kaj forajn etikedojn, poste komparu la precizajn intervalojn, kiujn ĉiu flanko proponas.
Legu TS_UNACCEPTABLE kiel malkonsenton pri kovrado, ne kiel difektitan profilon. La kluzo diras, ke la du partneroj ne povis interkonsenti pri tio, kiujn adresojn ĉi tiu tunelo rajtas porti. La IKE SA povas jam esti aktiva en tiu momento, tial kliento povas ŝajni konektita sen iu ida SA malantaŭ ĝi. Unufoje kadritinte ĝin tiel, la laboro fariĝas mekanika. Notu la celatajn prefiksojn de ambaŭ flankoj, komparu ilin en unu direkto, kaj mallarĝigu ĝis ili sekcas.
Unue notu la celatajn parojn
Antaŭ ol tuŝi la agordon, listigu kvar valorojn: la fontintervalon de la iniciatinto, ĝian celintervalon, kaj la saman paron vidatan de la respondanto. Notu ankaŭ la adresan familion de ĉiu el ili. IPv4-intervalo kaj IPv6-intervalo estas malsamaj specoj de selektilo, kaj nek unu povas esti faldita en la utilan ŝarĝon de la alia.
Aldonu iun ajn protokolan aŭ pordan limigon, kiun la politiko portas. Regulo permesanta nur TCP 445 al dosieruja servilo priskribas pli mallarĝan aron ol la subreto, en kiu ĝi kuŝas. Se vi lasas tion ekster viaj notoj, la intertraktada rezulto ŝajnos malkonsekvenca pro kialoj, kiujn vi ne vidas.
Inversigu la etikedojn antaŭ ol kompari ilin
Loka kaj fora estas relativaj etikedoj. La loka prefikso de la kliento estas la fora intervalo de la kluzo, kaj la loka intervalo de la kluzo estas la fora de la kliento. Tial ekrankopioj de la du flankoj neniam kongruas, kaj kompari ilin laŭvorte estas la norma maniero perdi posttagmezon.
Respondanto povas mallarĝigi oferton al akceptebla subaro anstataŭ rifuzi ĝin. Tiu rezulto estas pli malbona ol pure malsukceso, ĉar ĝi duone funkcias. Petu 10.0.0.0/16 dum la politiko permesas 10.0.5.0/24, kaj vi povas fini kun ida SA kovranta nur tiun /24. Unu gastiganto respondas, ĉio alia falas ekstere, kaj nenio en la kliento diras tion. Legu la akceptitajn selektilojn prefere ol la petitajn antaŭ ol konkludi, ke la intertraktado sukcesis.
Profiloj road warrior, kiuj petas defaŭltan itineron, surteriĝas ĉi tie konstante. Kluzo konstruita por dividita aliro mallarĝigas plenintervalan oferton al siaj propraj subretoj, kaj la kliento devas akcepti la mallarĝigitan rezulton aŭ malsukcesi laŭte.
Legu la rifuzon el unu provo
Kolektu ambaŭ protokolojn el la sama konekprovo. Konservita profilo montras, kion vi agordis, ne kion oni proponis, kaj en strongSwan swanctl --log presas la ricevitan sciigon kun la selektiloj, kiujn ĝi portis.
Poste ekzamenu, kio efektive instaliĝis. swanctl --list-sas montras la selektilojn de la ida SA, kaj ip xfrm policy montras la samajn intervalojn kiel kernpolitikajn erojn. Ida SA en tiu listo kun selektiloj, kiujn vi ne celis, estas mallarĝiga evento; neniom da ida SA plus TS_UNACCEPTABLE en la protokolo estas rifuzo.
Dum vi estas tie, apartigu la proksimajn najbarojn. INVALID_SELECTORS plendas pri selektilo ene de establita ida SA, dum INTERNAL_ADDRESS_FAILURE signifas, ke la respondanto ne povis atribui virtualan adreson, kio estas naĝara problemo prefere ol kovrada problemo.
Kontrolu, kio kviete malgrandigas la aron
Tri aferoj malgrandigas selektilaron sen diri ion. La politiko de respondanto estas la unua, per subretaj listoj, grupaj reguloj aŭ peruzanta rajtigo, kiu reduktas la oferton al subaro. La adresa familio estas la dua: duobla staka kliento ofte proponas IPv6 apud IPv4 kaj ricevas rifuzon pro intervaloj, kiujn la kluzo neniam agordis.
Protokolaj kaj pordaj limigoj estas la tria. Kie la politiko permesas nur TCP 445, ida SA povas ekfunkcii dum ICMP kaj UDP restas ekstere, kaj la uzanto raportas rompitan tunelon dum unu protokolo estis la tuta permeso.
Sola larĝigo de adresoj do ne povas riparigi pordan limigitan politikon, kaj tio estas la kazo plej verŝajne travivanta tri raŭndojn de diagnozado senŝanĝe.
Pruvu kovradon per trafiko, kiu taŭgas
Post kiam la ida SA instaliĝas, sendu unu peton, kiu certe falas ene de la akceptitaj intervaloj. Rigardu la nombrilojn anstataŭ la statikono: ip -s xfrm state kaj la nombriloj malantaŭ ip xfrm policy pliiĝas, kiam paketo estas trafita kaj protektita. Bajta nombro, kiu restas nulo post reala trafiko, signifas, ke la kerno neniam elektis tiun politikon.
Tiu nulo estas itinerada aŭ politikorda problemo, ne kriptografia problemo. Ĝi ankaŭ ŝajnas identa al selektila rifuzo de la sidloko de la uzanto, tial indas kolekti la nombrilojn antaŭ ol vi remalfermos la profilon. Nombriloj, kiuj grimpas nur en unu direkto, indikas anstataŭe la revenan vojon.
Finu per tio, ke vi skribas la akceptitan paron en la tickets, apud la intervaloj origine petita. Tenu la elekton same mallarĝa kiel la postulo, ĉar forigi la eraron anstataŭigante privatan intervalon per ĉiuj adresoj donas multe pli da aliro ol la konto estis aprobita.