IKEv2-interŝanĝo funkcias, poste aŭtentigo malsukcesas: kie
La tunelo ricevas respondon kaj poste haltas: la ŝlosilinterŝanĝo sukcesis kaj posta kontrolo ne. Uzu la malakceptan stadion por trovi, kiu identeco estis rifuzita.
Kliento, kiu ricevas respondon de IKEv2, pruvis, ke la pordego estas atingebla, ke ambaŭ flankoj povas interkonsenti pri propono kaj ke la unua ŝlosilinterŝanĝo finiĝis. Ĝi ne pruvis, ke iu estas aŭtentigita. La sekva interŝanĝo portas identecojn, atestilojn aŭ EAP, kaj tie la konekto kutime haltas. Legi, kiu el tiuj kontroloj malsukcesis, estas la tuta diagnozo, kaj la erarmesaĝo sola tion malofte diras.
Kontrolo 1: legu la stadion, ne la mesaĝon
Malakcepto povas veni el tri lokoj: la kliento rifuzas la identecon de la servilo, la pordego rifuzas la pruvon de la kliento, kaj ekstera aŭtentiga servo rifuzas la konton.
Ĉiu produktas alian protokollinion sur alia maŝino, kaj ĉiu havas alian riparon. Malakcepto de la servila atestilo ĉe la klienta flanko estas fido- aŭ nomproblemo ĉe la kliento; malakcepto de la klienta atestilo ĉe la pordega flanko estas fidoproblemo ĉe la pordego; EAP-malsukceso estas konto- aŭ malantaŭa problemo. La mesaĝo, kiun vi vidas, estas kutime la resumo de la kliento pri unu el tiuj, tial la protokolo de la pordego same gravas kiel tiu de la kliento.
Kontrolo 2: kiu identeco estis kontrolita
Kliento povas rifuzi la servilan atestilon aŭ la atendatan identecon antaŭ ol iu ajn uzantidentaĵo proponiĝas, kaj funkcianta servila adreso ne anstataŭas tiun kontrolon. La identigilo, kiun la kliento atendas, devas kongrui kun tio, kion la pordego prezentas, kio estas agorda fakto, ne reta.
En la terminoj de strongSwan tio estas rightid ĉe la kliento kaj la propra identeco de la pordego ĉe la alia flanko, kaj malkongruo malsukcesas antaŭ ol EAP eĉ diskutiĝas.
La pordego aparte povas rifuzi la klientan atestilon, ĝian ŝlosilpruvon aŭ ĝian kontan aŭtentigon, kaj tiuj tri ne estas interŝanĝeblaj. Restarigi uzantpasvorton ne renovigas aparatan atestilon, kaj reinstali aparatan atestilon ne riparas malĝustan servilan identecon. Ĉe atestilaj malsukcesoj kontrolu unue la horloĝon, poste la fidoĉenon, poste la atendatan identigilon; kliento, kies horloĝo malfruas kelkajn minutojn, malsukcesas ĉe valideckontrolo, kiu aspektas kiel fidomalsukceso. swanctl --list-certs ĉe ambaŭ flankoj montras, kion ĉiu flanko efektive havas.
Kontrolo 3: se EAP estas en la ludo
La kliento kaj la servilo devas interkonsenti pri subtenata metodo, kaj la malantaŭa sistemo devas akcepti la donitan identecon.
Uzantnomo eble bezonas domajnan sufikson aŭ specifan kontformon, kiun la enkonduko postulas, kaj la formo estas dokumentita, ne divenebla. Doni la dokumentitajn kampojn de la operatoro estas pli rapide ol provi variantojn, kaj ĝi evitas duan problemon: ripetaj provoj povas ekigi kontan ŝlosadon, kiu poste kaŝas la originan stadion malantaŭ nova malsukceso. Se la metodo estas EAP-MSCHAPv2 kontraŭ adresaro, la malsukceso eble apartenas al la adresaro kaj tute ne al la VPN.
Ne testu identecajn problemojn per malŝalto de identeckontroloj. Tio igas diagnozeblan malsukceson nediagnozebla kaj lasas la konekton pli malforta ol antaŭe.
Kontrolo 4: kio okazas post sukcesa ensaluto
Post kiam IKE_AUTH finiĝas, la intertraktado de CHILD_SA decidas, kiuj trafikselektiloj instaliĝos, kaj tie konekto povas sukcesi kaj tamen traduki nenion.
Nova funkcianta ensaluto ofte malkaŝas selektilan aŭ vojan problemon, kiu antaŭe estis kaŝita malantaŭ la aŭtentiga malsukceso. Se la tunelo leviĝas kaj aplikaĵo ankoraŭ ne atingas sian celon, rigardu la intertraktitajn selektilojn kaj la vojojn, ne denove la identecon. Ŝanĝi identecajn agordojn en tiu punkto celas la malĝustan stadion kaj kutime rompas funkciantan ensaluton. Konfirmu per swanctl --list-sas, kiu montras la infanojn kaj iliajn selektilojn aparte de la IKE SA.
Kontrolo 5: kion doni al la subteno
Purigita templinio kaj la preciza malakcepto valoras pli ol kompleta diagnoza eksporto, kaj la eksporto povas enhavi privatajn ŝlosilojn aŭ akreditaĵojn, kiujn vi ne devus kunhavigi.
Notu la tempon kun la horzono, la versiojn de kliento kaj pordego, la metodon, la identecan ĉenon, kiu estis proponita, ne la pasvorton, kaj la precizan stadion, kiu ĝin malakceptis. dokumentaro de strongSwan pri agordo de IKEv2 priskribas la identecajn kaj EAP-agordojn, kiuj decidas tiujn rezultojn, kaj ĝi estas la referenco legenda antaŭ ol ŝanĝi kampon. Poste ŝanĝu unu aferon kaj retestu novan konekton, ĉar kaŝmemorita seanco rakontos al vi pri la malnova agordo.