Innkommende IPsec-peer som ikke matcher noen profil? Sjekk fire felt

Peeren din rapporterer at tunnelen er oppe, din side viser ingen sikkerhetsassosiasjon, og konfigurasjonsfilen inneholder tydelig et samsvarende tilkoblingsnavn. Alle tre påstandene kan være sanne samtidig. En innkommende forhandling matches mot den kjørende konfigurasjonen, basert på peerens adresse, identiteten den presenterer og trafikken den foreslår. En fil på disk som aldri ble lastet inn, en identitet som ikke samsvarer med forventet verdi, eller et selektorpar som er forskjøvet med ett prefiks vil hver for seg gi stillhet. Gå gjennom de fire feltgruppene i den rekkefølgen responderen følger.

Start fra pakken, ikke fra filen

Responderen mottar en IKE-forespørsel, leter etter en definisjon som kan godta denne peeren, og fortsetter deretter med autentisering og trafikkvalg. Hvis ingen innlastet definisjon matcher i første trinn, avsluttes forhandlingen før noen nyttig feil når brukeren.

Derfor er «konfigurasjonen ser riktig ut» ikke et bevis. Spørsmålet er hva tjenesten som kjører har lastet inn, og hvilken oppføring den valgte for dette forsøket. En statusliste svarer på det med én kommando, mens editor-bufferen svarer på et annet spørsmål. Sjekk listen før du endrer filen igjen.

Første feltgruppe: definisjonen som faktisk er lastet inn

Sjekk den kjørende tilstanden med verktøyet som eier daemonen: en statuskommando som lister innlastede tilkoblinger, ikke editor-bufferen. Bekreft at oppføringen du forventer finnes, er aktivert for oppstartsatferden du ønsker, og ble lastet inn etter din siste endring. En lagret fil som ikke er lastet inn på nytt er den vanligste årsaken til «jeg fikset det og ingenting endret seg».

Bekreft også hvilken fil tjenesten leser. Distribusjoner varierer, og en tilkobling skrevet i feil inkludering ignoreres stille i stedet for å avvises. Hvis statuslisten ikke viser oppføringen din i det hele tatt, mistenke inkluderingsstien før du mistenker syntaksen.

Andre feltgruppe: endepunkter er ikke identiteter

Adressen peeren kobler til fra og identiteten den autentiserer med er separate felt. Et vertsnavn, et utpreget navn, en nøkkel-ID og en adresse kan alle tjene som IKE-identitet avhengig av konfigurasjonen, og de trenger slett ikke se ut som den offentlige adressen.

Endepunktsmatch kan også innebære et NAT-syn: adressen som ses på nettet kan avvike fra adressen peeren tror den har. I libreswans tilkoblingsmodell er left og right etiketter for de to deltakerne og ikke en fast lokal og fjern rekkefølge, og derfor er kopiering av en fungerende konfigurasjon fra et annet sted med bytte av adressene ikke en pålitelig oversettelse.

Skriv ned begge siders forventede identitet og legitimasjonen som validerer den. Hvis de to linjene er uenige, vil ingen mengde adressetilpasning gi et match.

Tredje feltgruppe: trafikken som beskyttes

Selektorene beskriver de indre kilde- og destinasjonsområdene, deres adressefamilie og enhver protokoll- eller portbegrensning. Et forslag for én vertsadresse er ikke den samme forespørselen som for et helt subnett, og en responder konfigurert for subnettet kan avvise det eller snevre det inn.

Når de to endene er uenige, sammenlign den tiltenkte flyten fra begge synsvinkler i stedet for å utvide hver selektor så noe kan kobles til. Spør hver administrator hvilken flyt de mener å beskytte, og sammenlign deretter de to svarene. Avviket er vanligvis et vertsprefiks på den ene siden og et subnett på den andre. En tunnel som matcher fordi den nå beskytter alt, er en annen sikkerhetsbeslutning, og en som ingen har godkjent.

Fjerde feltgruppe: du leser én implementasjon

Libreswan, eldre Openswan og strongSwan har forskjellige administrasjonsverktøy, forskjellig konfigurasjonssyntaks og forskjellig matcherekkefølge. Et fungerende eksempel fra én sier ingenting presist om en annens profilvalgsprioritet eller feilformulering, så verifiser med dokumentasjonen for daemonen på denne verten.

Korreler ett forsøk fra ende til annen: initiativtakerens kildeadresse, tilbudte identitet og foreslåtte selektorer — mot responderens valgmelding og den innlastede oppføringen den navngir. Nulltellerne for innkapsling og avkapsling sier bare at de observerte assosiasjonene ikke har båret disse pakkene; de navngir ikke endepunktet som avviste forslaget og beviser ikke at en samsvarende oppføring fantes i det øyeblikket.

Etter en koordinert retting, bekreft den valgte profilen og assosiasjonen, og test deretter den faktisk tillatte tjenesten og svarveien dens. En profilmatch muliggjør forhandling, og forhandling er ikke den siste tilgangskontrollen.