ike-scan får ingen respons frå ein fungerande IPsec-gateway

Gatewayen tener telefonar og berbare datamaskinar kvar dag, men ike-scan rapporterer at ingen vertar svara. Den utskrifta vert lesen som prov på at IPsec manglar på eininga. Vanlegvis tyder det at eininga forkasta kvart forslag i sonden og valde å ikkje svara noko. Stilla er òg eit svar, og det er det minst informative svaret verktøyet kan gje deg.

Gå gjennom tre separate spørsmål: kom pakken fram, passa noko forslag, og avviste noko anna motparten?

Steg 1: les forslaget verktøyet sender

Hovudmodus byrjar med ein SA-nyttelast som listar transformasjonane initiativtakaren vil godta, og ike-scan fyller den lista frå ein kompilert standard. Standardsettet er med vilje gamalt: DES og 3DES for kryptering, MD5 og SHA1 for hashing, grupper 1 og 2 for nøkkelutveksling, førehandsdelte nøklar for autentisering. Ingen AES, ingen SHA-2, ingen gruppe 14. Ein gateway konfigurert for AES-256 med SHA-256 og modp2048 deler ingenting med det.

Nokre implementasjonar svarar ein sondering som ikkje passar med eit NO-PROPOSAL-CHOSEN-varsel. Andre slepp han berre, noko som er vanleg på einingar som behandlar ukjende motpartar som støy. Uansett skriv skanninga ingenting, og det ingenting er identisk med korleis ein filtrert UDP 500 ser ut utanfrå, som dokumentasjonen til ike-scan-prosjektet gjer klart om standardsettet.

Steg 2: tilby eitt moderne forslag

Erstatt standardsettet med --trans. Attributtforma tek IKE-attributtnummer direkte: 1 for kryptering, 2 for hash, 3 for autentisering, 4 for gruppa og 14 for nøkkellengd når algoritmen tek ein. Det som kjem ut er ei linje du kan lese høgt i ein endringsgjennomgang.

Posisjonsforma ber dei same verdiane i rekkjefølgje og unngår parentesar, noko som tel når kommandoen går gjennom eit skal.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Eitt forslag per pakke er tregt når du tel opp, så løkk over dei plausible verdiane: kryptering 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; grupper 1, 2, 5, 14, 15, 19, 20, 21; autentisering 1 for ein førehandsdel nøkkel og 3 for RSA-signaturar. Skriv ut kvar kommando før du køyrer han, slik at transkripsjonen viser kva som vart tilbode og i kva rekkjefølgje.

Steg 3: tolk eit svar

Eit svar beviser nøyaktig to ting: ein IKE-respondar er nåbar på den adressa, og eitt tilbode forslag var akseptabelt. Det seier ingenting om den førehandsdelte nøkkelen, L2TP-laget eller om ein brukarkonto finst. Ei vellukka skanning er heilt foreinleg med at kvart seinare steg feilar.

På ein gateway du driftar, er dette den verkeleg nyttige delen. Skanninga fortel deg kva forslag eininga framleis godtek, og eit resultat avgrensa til eldre transformasjonar er eit funn om einingapolitikk, ikkje ein grunn til å svekkje klienten.

Steg 4: tolk stilla

Stilla er eit svakare prov enn det ser ut som. Kvart forslag kan ha vorte avvist, UDP 500 og 4500 kan vere filtrerte, kjelda kan vere hastighetsavgrensa etter ein byge, eller tenesta kan lytte på ei anna adresse enn den du skanna. Samanlikn IKE-loggen til gatewayen med ein klient som alt koplar til med gyldige legitimasjonar før du konkluderer noko om boksen.

Bygeåtferd høyrer heime på den lista fordi oppteljing genererer mange pakkar i eit kort vindauge. Ein gateway som svarar dei første forsøka og deretter blir stille, skildrar anti-DoS-politikken sin snarare enn forslagssettet sitt.

Steg 5: skriv ned kva du beviste

Skriv den aksepterte kombinasjonen ved sida av fastvareversjonen, og samanlikn han deretter med transformasjonane klientane du bryr deg om tilbyr som standard. Gapet mellom dei to listene er konfigurasjonsproblemet, og skanninga gjorde det berre synleg. Viss dei einaste aksepterte forslaga er dei du ikkje ville valt, høyrer rettinga heime i gateway-politikken eller i ein klientprofil, aldri i sonden.

Ein sonde som aldri svara, har likevel svara på noko: han viser kva forslag denne eininga er villig til å diskutere, og kva ho heller vil sleppe på golvet.