ike-scan får ingen respons fra en fungerende IPsec-gateway

Gatewayen betjener telefoner og bærbare datamaskiner hver dag, men ike-scan rapporterer at ingen verter svarte. Den utskriften leses som bevis på at IPsec mangler på enheten. Vanligvis betyr det at enheten forkastet hvert forslag i sonden og valgte å ikke svare noe. Stillhet er også et svar, og det er det minst informative svaret verktøyet kan gi deg.

Gå gjennom tre separate spørsmål: kom pakken frem, passet noen forslag, og avviste noe annet motparten?

Trinn 1: les forslaget verktøyet sender

Hovedmodus begynner med en SA-nyttelast som lister transformasjonene initiativtakeren vil godta, og ike-scan fyller den listen fra en kompilert standard. Standardsettet er med vilje gammelt: DES og 3DES for kryptering, MD5 og SHA1 for hashing, grupper 1 og 2 for nøkkelutveksling, forhåndsdelte nøkler for autentisering. Ingen AES, ingen SHA-2, ingen gruppe 14. En gateway konfigurert for AES-256 med SHA-256 og modp2048 deler ingenting med det.

Noen implementasjoner svarer en sondering som ikke passer med et NO-PROPOSAL-CHOSEN-varsel. Andre slipper den bare, noe som er vanlig på enheter som behandler ukjente motparter som støy. Uansett skriver skanningen ingenting, og det ingenting er identisk med hvordan en filtrert UDP 500 ser ut utenfra, som ike-scan-prosjektets dokumentasjon gjør klart om standardsettet.

Trinn 2: tilby ett moderne forslag

Erstatt standardsettet med --trans. Attributtformen tar IKE-attributtnumre direkte: 1 for kryptering, 2 for hash, 3 for autentisering, 4 for gruppen og 14 for nøkkellengde når algoritmen tar en. Det som kommer ut er en linje du kan lese høyt i en endringsgjennomgang.

Posisjonsformen bærer de samme verdiene i rekkefølge og unngår parenteser, noe som betyr noe når kommandoen går gjennom et skall.

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

Ett forslag per pakke er tregt når du teller opp, så løkk over de plausible verdiene: 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 en forhåndsdelt nøkkel og 3 for RSA-signaturer. Skriv ut hver kommando før du kjører den, slik at transkripsjonen viser hva som ble tilbudt og i hvilken rekkefølge.

Trinn 3: tolk et svar

Et svar beviser nøyaktig to ting: en IKE-responder er nåbar på den adressen, og ett tilbudt forslag var akseptabelt. Det sier ingenting om den forhåndsdelte nøkkelen, L2TP-laget eller om en brukerkonto finnes. En vellykket skanning er helt forenlig med at hvert senere trinn feiler.

På en gateway du drifter, er dette den virkelig nyttige delen. Skanningen forteller deg hvilke forslag enheten fortsatt godtar, og et resultat begrenset til eldre transformasjoner er et funn om enhetspolicy, ikke en grunn til å svekke klienten.

Trinn 4: tolk stillhet

Stillhet er et svakere bevis enn det ser ut som. Hvert forslag kan ha blitt avvist, UDP 500 og 4500 kan være filtrert, kilden kan være hastighetsbegrenset etter en byge, eller tjenesten kan lytte på en annen adresse enn den du skannet. Sammenlign gatewayens IKE-logg med en klient som allerede kobler til med gyldige legitimasjoner før du konkluderer noe om boksen.

Bygeatferd hører hjemme på den listen fordi opptelling genererer mange pakker i et kort vindu. En gateway som svarer de første forsøkene og deretter blir stille, beskriver sin anti-DoS-policy snarere enn forslagssettet sitt.

Trinn 5: skriv ned hva du beviste

Skriv den aksepterte kombinasjonen ved siden av fastvareversjonen, og sammenlign den deretter med transformasjonene klientene du bryr deg om tilbyr som standard. Gapet mellom de to listene er konfigurasjonsproblemet, og skanningen gjorde det bare synlig. Hvis de eneste aksepterte forslagene er dem du ikke ville valgt, hører rettelsen hjemme i gateway-policyen eller i en klientprofil, aldri i sonden.

En sonde som aldri svarte, har likevel svart på noe: den viser hvilke forslag denne enheten er villig til å diskutere, og hvilke den heller vil slippe på gulvet.