Indgående IPsec-peer matcher ingen profil? Kontroller fire felter

Din peer rapporterer, at tunnelen er oppe, din side viser ingen sikkerhedsassociation, og konfigurationsfilen indeholder tydeligt et matchende forbindelsesnavn. Alle tre udsagn kan være sande samtidig. En indgående forhandling matches mod den kørende konfiguration ud fra peerens adresse, den identitet den fremviser, og den trafik den foreslår. En fil på disken, der aldrig blev indlæst, en identitet der ikke matcher den forventede værdi, eller et selektorpar der er forskudt med ét præfiks vil hver især give tavshed. Gå de fire feltgrupper igennem i den rækkefølge, responder'en følger.

Begynd ved pakken, ikke ved filen

Responder'en modtager en IKE-anmodning, leder efter en definition, der kan acceptere denne peer, og fortsætter derefter med autentificering og trafikvalg. Hvis ingen indlæst definition matcher i første trin, slutter forhandlingen, før nogen brugbar fejl når brugeren.

Derfor er “konfigurationen ser rigtig ud” ikke bevis. Spørgsmålet er, hvad den kørende tjeneste har indlæst, og hvilken post den valgte til dette forsøg. En statusliste svarer på det med én kommando, mens en editor-buffer svarer på et andet spørgsmål. Kontrollér listen, før du ændrer filen igen.

Første feltgruppe: den definition, der faktisk er indlæst

Kontrollér den kørende tilstand med det værktøj, der ejer daemonen: en statuskommando, der lister indlæste forbindelser, ikke editor-bufferen. Bekræft, at den forventede post er til stede, er aktiveret til den opstartsadfærd, du ønsker, og blev indlæst efter din seneste ændring. En gemt fil, der ikke er genindlæst, er den mest almindelige årsag til “jeg rettede det, og intet ændrede sig”.

Bekræft også, hvilken fil tjenesten læser. Distributioner varierer, og en forbindelse, der er skrevet i det forkerte include, ignoreres lydløst i stedet for at blive afvist. Hvis statuslisten slet ikke viser din post, så mistænk include-stien før du mistænker syntaksen.

Anden feltgruppe: endepunkter er ikke identiteter

Den adresse, peer'en forbinder fra, og den identitet, den autentificerer med, er separate felter. Et værtsnavn, et særligt navn, et nøgle-ID og en adresse kan alle tjene som IKE-identitet afhængigt af konfigurationen, og de behøver slet ikke ligne den offentlige adresse.

Endepunktsmatchning kan også omfatte et NAT-syn: adressen, der ses på nettet, kan afvige fra den adresse, peer'en tror, den har. I libreswans forbindelsesmodel er left og right etiketter for de to deltagere og ikke en fast lokal og fjern rækkefølge, og derfor er kopiering af en fungerende konfiguration fra et andet sted med ombytning af adresserne ikke en pålidelig oversættelse.

Skriv begge siders forventede identitet og det legitimationsobjekt, der validerer den, ned. Hvis de to linjer er uenige, vil ingen mængde adressetilpasning give et match.

Tredje feltgruppe: den trafik, der beskyttes

Selektorer beskriver de indre kilde- og destinationsintervaller, deres adressefamilie og enhver protokol- eller portbegrænsning. Et forslag til én værtsadresse er ikke den samme anmodning som til et helt subnet, og en responder, der er konfigureret til subnettet, kan afvise det eller indsnævre det.

Når de to ender er uenige, sammenlign det tilsigtede flow fra begge synsvinkler i stedet for at udvide hver selektor, så noget kan forbinde. Spørg hver administrator, hvilket flow de mener at beskytte, og sammenlign derefter de to svar. Uoverensstemmelsen er normalt et værtspræfiks på den ene side og et subnet på den anden. En tunnel, der matcher, fordi den nu beskytter alt, er en anden sikkerhedsbeslutning, og en som ingen har godkendt.

Fjerde feltgruppe: du læser én implementering

Libreswan, ældre Openswan og strongSwan har forskellige administrationsværktøjer, forskellig konfigurationssyntaks og forskellig matchningsrækkefølge. Et fungerende eksempel fra én siger intet præcist om en andens profilvalgsprioritet eller fejlformulering, så verificér med dokumentationen for daemonen på denne vært.

Korrelér ét forsøg fra ende til anden: initiativtagerens kildeadresse, tilbudte identitet og foreslåede selektorer mod responder'ens valgbesked og den indlæste post, den nævner. Nul-tællere for indkapsling og afkapsling siger kun, at de observerede associationer ikke har båret disse pakker; de navngiver ikke det endepunkt, der afviste forslaget, og beviser ikke, at der fandtes en matchende post i det øjeblik.

Efter en koordineret rettelse bekræftes den valgte profil og association, og derefter afprøves den faktisk tilladte tjeneste og dens svarvej. Et profilmatch muliggør forhandling, og forhandling er ikke den sidste adgangskontrol.