Innkomande IPsec-peer som ikkje passar nokon profil? Sjekk fire felt

Peeren din rapporterer at tunnelen er oppe, sida di viser ingen tryggleiksassosiasjon, og konfigurasjonsfila inneheld tydeleg eit samsvarande tilkoplingsnamn. Alle tre påstandane kan vere sanne samstundes. Ei innkomande forhandling vert samanlikna med den køyrande konfigurasjonen, ut frå adressa til peeren, identiteten han presenterer og trafikken han føreslår. Ei fil på disk som aldri vart lasta inn, ein identitet som ikkje samsvarar med forventa verdi, eller eit selektorpar som er forskyve med eitt prefiks vil kvar for seg gje stillheit. Gå gjennom dei fire feltgruppene i den rekkjefølgja svararen følgjer.

Start frå pakken, ikkje frå fila

Svararen tek imot ein IKE-førespurnad, leitar etter ein definisjon som kan godta denne peeren, og held deretter fram med autentisering og trafikkval. Dersom ingen innlasta definisjon passar i første trinn, blir forhandlinga avslutta før noka nyttig feil når brukaren.

Difor er «konfigurasjonen ser rett ut» ikkje eit prov. Spørsmålet er kva tenesta som køyrer har lasta inn, og kva oppføring ho valde for dette forsøket. Ei statusliste svarar på det med éin kommando, medan editor-bufferen svarar på eit anna spørsmål. Sjekk lista før du endrar fila igjen.

Første feltgruppe: definisjonen som faktisk er lasta inn

Sjekk den køyrande tilstanden med verktøyet som eig daemonen: ein statuskommando som listar innlasta tilkoplingar, ikkje editor-bufferen. Stadfest at oppføringa du ventar finst, er slått på for oppstartsåtferda du ønskjer, og vart lasta inn etter den siste endringa di. Ei lagra fil som ikkje er lasta inn på nytt er den vanlegaste årsaka til «eg fiksa det og ingenting endra seg».

Stadfest òg kva fil tenesta les. Distribusjonar varierer, og ei tilkopling skriven i feil inkludering blir stille ignorert i staden for å bli avvist. Dersom statuslista ikkje viser oppføringa di i det heile, mistenk inkluderingsstien før du mistenk syntaksen.

Andre feltgruppe: endepunkt er ikkje identitetar

Adressa peeren koplar til frå og identiteten han autentiserer med er separate felt. Eit vertsnamn, eit utpeika namn, ein nøkkel-ID og ei adresse kan alle tena som IKE-identitet avhengig av konfigurasjonen, og dei treng slett ikkje sjå ut som den offentlege adressa.

Endepunktsmatch kan òg innebere eit NAT-syn: adressa som ein ser på nettet kan avvike frå adressa peeren trur han har. I tilkoplingsmodellen til libreswan er left og right etikettar for dei to deltakarane og ikkje ei fast lokal og fjern rekkjefølgje, og difor er kopiering av ein fungerande konfigurasjon frå ein annan stad med byte av adressene ikkje ei påliteleg omsetjing.

Skriv ned den forventa identiteten til begge sider og legitimasjonen som validerer han. Dersom dei to linjene er usamde, vil inga mengd adressetilpassing gje ein match.

Tredje feltgruppe: trafikken som vert verna

Selektorane skildrar dei indre kjelde- og målområda, adressefamilien deira og kvar protokoll- eller portavgrensing. Eit framlegg for éi vertsadresse er ikkje den same førespurnaden som for eit heilt subnett, og ein svarar konfigurert for subnettet kan avvise det eller snevre det inn.

Når dei to endane er usamde, samanlikn den tiltenkte flyten frå begge synsvinklar i staden for å utvide kvar selektor så noko kan koplast til. Spør kvar administrator kva flyt dei meiner å verne, og samanlikn deretter dei to svara. Avviket er vanlegvis eit vertsprefiks på den eine sida og eit subnett på den andre. Ein tunnel som passar fordi han no vernar alt, er eit anna tryggleiksval, og eitt som ingen har godkjent.

Fjerde feltgruppe: du les éin implementasjon

Libreswan, eldre Openswan og strongSwan har ulike administrasjonsverktøy, ulik konfigurasjonssyntaks og ulik matchrekkjefølgje. Eit fungerande døme frå éin seier ingenting presist om profilvalprioriteten eller feilformuleringa til ein annan, så verifiser med dokumentasjonen for daemonen på denne verten.

Korreler eitt forsøk frå ende til annan: kjeldeadressa til initiativtakaren, den tilbodne identiteten og dei føreslåtte selektorane — mot valmeldinga til svararen og den innlasta oppføringa ho nemner. Nullteljarane for innkapsling og avkapsling seier berre at dei observerte assosiasjonane ikkje har bore desse pakkane; dei nemner ikkje endepunktet som avviste framlegget og provar ikkje at ei samsvarande oppføring fanst i det augneblinken.

Etter ei koordinert retting, stadfest den valde profilen og assosiasjonen, og test deretter den faktisk tillatne tenesta og svarvegen hennar. Ein profilmatch gjer forhandling mogeleg, og forhandling er ikkje den siste tilgangskontrollen.